NWG/RFC 385 Abhay K. Bhushan
NIC 11357 MIT-MAC
Günceller: RFC 354 18 Ağustos 1972
RFC 354

DOSYA AKTARIM PROTOKOLÜ (RFC 354) HAKKINDA YORUMLAR

Aşağıdaki yorumlar, Dosya Aktarım Protokolü NWG/RFC 354 ile ilgilidir. Yorumlar, hata düzeltmelerini, ek tartışmaları, vurgu noktalarını ve protokole eklemeleri içerir. Yeterli deneyim edindikten sonra bu yorumları ana protokol belgesine dâhil edeceğim.

1. Düzeltmeler

Lütfen aşağıdaki düzeltmelere dikkat ediniz:

(i) Sayfa 2, satır 15: user-FTP yerine server-FTP yazılmalıdır.
(ii) Sayfa 3, satır 12: III.A yerine III.C yazılmalıdır.
(iii) Sayfa 15, son paragraf, satır 1: user s yerine user is yazılmalıdır.
(iv) Sayfa 28, satır 21: CRCRLF yerine CRLF yazılmalıdır.
(v) Sayfa 27, satır 10: 451,451 yerine 451 yazılmalıdır.
(vi) Sayfa 26, satır 15’te kip kodunun S|B|T|H olduğunu not ediniz.

2. Gerekli Asgari Gerçekleştirimler

RFC 354’ün dili, ana bilgisayarların varsayılan parametreleri gerçekleştirmesinin önerildiğini belirtmektedir. Önerilir kelimesinin anlamı zorunlu olarak alınmalıdır. Buna göre FTP sunucuları için gerekli asgari gerçekleştirimler şunlardır:

Type — ASCII (8 bit baytlar)
Mode — Stream
Structure — File
Commands — RETR, STOR, USER (ve PASS), SOCK ve BYE

3. Yazdırma Dosyası Türleri ve ASA Dikey Biçim Denetimi

Print File-ASCII ve EBCDIC Print File türleri hatalı biçimde tanımlanmıştır (RFC 354, sayfa 10 ve 11). Yazdırma dosyalarındaki asıl sorun, ASA (Fortran) dikey biçim denetimidir. İki yazdırma dosyası türü yerine, aşağıda açıklandığı gibi aslında üç tür olmalıdır:

BCDIC

Gönderici, EBCDIC karakter kodunu ve 8 bitlik aktarım bayt boyutunu kullanarak veriyi aktarır. Dikey biçim denetimi için CRLF kuralı kullanılır. Bu tür, içsel karakter gösterimi olarak EBCDIC kullanan sistemler arasında EBCDIC dosyalarının verimli aktarımı için kullanılacaktır.

ASA Dikey Biçim Denetimli ASCII

Bu, RFC 354’te tanımlanan Print File-ASCII’dir. Sunucu, hâlâ bu standardı kullanan yazıcılarda basım için veriyi ASA (Fortran) dikey biçim denetim yordamlarına uygun olarak dönüştürmelidir. Veri, 8 bitlik baytlar olarak aktarılacaktır.

ASA Dikey Biçim Denetimli EBCDIC

Bu, RFC 354’te tanımlanan EBCDIC Print File’dır. Sunucu, EBCDIC karakter kodunu kullanarak veriyi ASA (Fortran) dikey biçim denetimi standartlarına uygun biçimde dönüştürmelidir. Veri, 8 bitlik baytlar halinde aktarılacaktır.

Yeni türler aşağıdaki sembollerle gösterilecektir:

E — EBCDIC
P — Print File-ASCII
F — Biçimlendirilmiş (ASA standardı) EBCDIC yazdırma dosyası

ASA dikey biçim denetimine ilişkin bir tartışma NWG/RFC 189, Ek C’de ve Communications of the ACM, Cilt 7, Sayı 10, s. 606, Ekim 1964’te yer almaktadır.

ASA dikey biçim denetimi standartlarına göre, biçimlendirilmiş bir kaydın ilk karakteri yazdırılmaz; bunun yerine aşağıdaki şekilde dikey aralığı belirler:

Karakter	Yazdırmadan önce dikey aralık
Boşluk	Bir satır
0	İki satır
1	Sonraki sayfanın ilk satırına
+	İlerleme yok

Yukarıdaki dörde ek olarak, ASA standardına bir IBM uzantısını temsil eden daha fazla karakter vardır (RFC 189, Ek C’de tanımlanmıştır).

4. Stream ve Text Kipleri

Stream ve text kiplerinin karşılaştırılması yerindedir.

Stream Kipinin Avantajları

Alıcının gelen baytları taraması gerekmez.
Tüm veri türleriyle kullanılabilir.

Stream Kipinin Dezavantajları

Bağlantının kapatılmasıyla EOF güvenilir değildir.
ASCII CRLF ile EOR güvenilir değildir; çünkü CRLF gerçekten geçerli veri olabilir ve bir EOR olmayabilir. Yalnızca gönderici ve alıcı bu etki konusunda önceden anlaşmışlarsa EOR olarak kabul edilir.

5. Block Kipinde Dolgu Bitleri

Block kipinde protokol, bilgi içermeyen en soldaki bitlerin sıfır olması gerektiğini belirtir. Bazı sitelerin bir bloğun başında boş baytlar göndermekte zorlandığı görülmektedir. Bu baytların sıfır olması aslında gerekli olmadığından, bu bitler artık önemsiz (don’t care) bitler olarak tanımlanmıştır.

6. Çoklu Block Kipi Koşulları

Block kipinin kullanımında, farklı tanımlayıcı kodlar gerektiren iki veya daha fazla koşulun (şüpheli hatalar ve kayıt sonu ya da dosya sonu) aynı anda var olması mümkündür. Böyle bir olasılık, bayt sayısı sıfır olan ayrı bir EOR veya EOF bloğu gönderilerek ele alınabilir (bu, protokol tarafından izin verilmektedir). Ayrıca bir EOF’un örtük bir EOR olduğu da not edilmelidir.

7. Veri Soketi Dinleme Gereksinimi

Kullanıcı-FTP’nin, dosya aktarımı gerektiren bir komut göndermeden önce veri soketinde dinleme yapması gerektiği tekrar vurgulanmalıdır. Özellikle, kullanıcı-FTP, dinleme işlemini yapmadan önce 255 yanıtını (sunucu veri soketi) beklememelidir. Güvenlik denetimi daha sonra yapılabilir; çünkü bağlantı, 255 yanıtıyla belirtilen soketten farklı bir sokete yapılmışsa veri bağlantısı kapatılabilir.

Protokol, bağlantı kurulmadan önce 255 yanıtının gönderileceğini öne sürse de, 255 yanıtının kullanıcı sitesindeki başlatıcı RFC’den önce ulaşacağını garanti etmez. Yukarıdaki argüman, veri bağlantısında, kapatılma nedenini belirten bir yanıt alınmadan önce bir kapatma (NCP-CLS) alınması durumu için de geçerlidir (RFC 354, sayfa 24, paragraf 3’teki ifadeye bakınız).

8. Veri Bağlantısının Kapatılması

Protokol, Block ve Text kiplerinde veri bağlantısının kapatılmasını ya da açık bırakılmasını kısıtlamasa da, veri bağlantısı kapatılacaksa bunun dosya aktarımından hemen sonra yapılması gerektiği vurgulanmalıdır; yeni bir aktarım komutu alındıktan hemen sonra değil. Bunun nedeni, sunucu ve kullanıcının sırasıyla bir listen ya da bir init yapmadan önce veri bağlantısının açık olup olmadığını sınamak zorunda kalabilmesidir.

9. TYPE ve BYTE Komutları

Type’ın Byte’ı geçersiz kıldığı ve TYPE komutunun BYTE komutundan önce gönderilmesi gerektiği tekrar vurgulanmalıdır.

10. Büyük/Küçük Harf Duyarsızlığı

Komut sözdiziminde hem büyük hem de küçük harfli alfabetik karakterlerin aynı şekilde ele alınacağı not edilmelidir. Bu durum, tür, kip ve yapı için kullanılan semboller için de geçerlidir. Örneğin, A ve a her ikisi de ASCII türünü belirtir.

11. LIST Komutu

LIST komutunda veri aktarımının, ASCII türünde veri bağlantısı üzerinden yapıldığı not edilmelidir.

12. Yeni Yanıt Kodu

Aşağıdaki yanıt kodu eklenmelidir:

454 FTP: Veri soketinize bağlanılamıyor.

Bu, veri aktarımı gerektiren komutların herhangi biri için (RETR, STOR, APPE ve LIST dâhil) bir başarısızlık yanıtıdır.

13. Posta Dosyası Komutu (MLFL)

Posta dosyalarını göndermek için append komutunu kullanmak yerine, yeni bir MLFL (mail file için) komutu tanımlanmıştır. Posta dosyası komutunun sözdizimi şöyledir:

MLFL <user>CRLF

burada:

<user> ::= <empty> | <NIC ident> | <sys ident>

Kullanıcı alanı boş ya da boşluklardan (bir veya daha fazla) oluşuyorsa, posta, site postası için belirlenmiş bir yazıcıya ya da başka bir yere yönlendirilir. NIC ident, Network Participant NIC Directory’de tanımlanan standart kimliği ifade eder. Hizmet veren bir ana bilgisayar, NIC ident’i sys ident’e eşleyen bir tablo tutabilir. Bu, tekdüze ve kullanışlı bir kullanım sağlar. Sys ident, kullanıcının hizmet veren ana bilgisayardaki normal kimliğidir.

Bu komutun amacı, kullanıcı sitesindeki bir kullanıcının veriyi (bir dosya biçiminde) sunucu sitesindeki başka bir kullanıcıya posta ile gönderebilmesini sağlamaktır. Postalanacak dosyaların, ASCII türünde veri bağlantısı üzerinden iletildiği not edilmelidir. Bu dosyalar, hizmet veren ana bilgisayarın posta geleneklerine uygun olarak sunucu tarafından hedef kullanıcının postasına eklenmelidir. Posta, belirli bir kullanan ana bilgisayardan ve USER komutuyla belirtilen kullanıcıdan gönderilmiş olarak işaretlenebilir.

MLFL komutu için yanıt kodları, aşağıda gösterildiği gibi APPE komutundakilerle aynıdır:

Komut	Başarı	Başarısız
MLFL	250	451, 454, 500–506
Sec. Reply	252	452, 453

14. TELNET Üzerinden MAIL Komutu

Ağ postası için MLFL komutu, FTP komut repertuarına yararlı ve temel bir ek olmakla birlikte, TIP kullanıcılarının üçüncü ana bilgisayarları kullanmadan postayı rahatça göndermesine olanak tanımaz. TIP kullanıcılarının, MLFL komutunun sağladığı veri bağlantısı yerine TELNET bağlantısı üzerinden posta göndermesi daha kullanışlı olacaktır.

Bu nedenle, postayı TELNET bağlantısı üzerinden göndermek için aşağıdaki MAIL komutu tanımlanmıştır:

MAIL <user>CRLF

’ın sözdizimi, MLFL komutundakiyle aynıdır. MAIL komutu alındıktan sonra sunucu, izleyen satırları kullanıcının gönderdiği postanın metni olarak ele almalıdır. Posta metni, yalnızca tek bir noktadan oluşan bir satırla sonlandırılmalıdır; yani yeni bir satırda .CRLF karakter dizisi ile.

Aşağıdaki yeni yanıt kodları tanımlanmıştır:

350 Postayı giriniz, yalnızca '.' içeren bir satırla sonlandırınız
256 Posta tamamlandı.

Yanıt kodları şöyledir:

Komut	Başarı	Başarısız
MAIL	350	450, 451, 500–506
Sec. Reply	256

15. Hesap Komutu (ACCT)

TENEX gibi, kullanıcı ve parola dışında ayrı bir hesap belirtimi gerektiren sistemlerde muhasebeleştirmeyi kolaylaştırmak için account (ACCT) adlı ek bir erişim denetimi komutu tanımlanmıştır.

ACCT komutu, PASS komutundan farklıdır; çünkü USER komutuyla zorunlu olarak ilişkili değildir ve herhangi bir zamanda gelebilir. Örneğin, bir kullanıcı farklı dosyaları farklı hesaplar kullanarak aktarabilir. ACCT komutu, PASS komutuyla aynı yanıt kodlarına sahiptir (başarı için 230 ve başarısızlık için 430–432, 500–506).

Bazı sunucular, kullanıcının oturum açmış sayılmasından önce bir hesap komutunun gönderilmesini isteyebilir. Bu tür durumlarda PASS komutuna verilen başarı yanıtı 330 Enter account olabilir.

16. Parola Maskeleme

Parola bilgisi oldukça hassas olduğundan, genel olarak bunun maskelenmesi ya da ekrana yazdırılmasının bastırılması arzu edilir. Sunucunun bunu sağlamak için gerçekten hatasız ve etkili bir yolu olmadığı görülmektedir. Bu nedenle, hassas parola bilgisini gizleme sorumluluğu kullanıcı-FTP sürecine aittir.

17. Deneysel Komutlar

FTP, kolay genişletilebilirlik için tasarlanmış açık uçlu bir protokoldür. Bu tür komutları uygulamak isteyen siteler tarafından deneysel komutlar tanımlanabilir. Bu deneysel komutlar alfabetik X karakteri ile başlamalıdır. Bu komutlarla standart yanıt kodları kullanılabilir. Yeni yanıt kodlarının atanması gerekirse, bunlar 900 ile 999 arasında seçilmelidir. Deneysel komut kullanışlı ve genel ilgiye sahip olursa, FTP komut repertuarına dâhil edilecektir.

Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere BBN Corp. tarafından Alex McKenzie’nin (1/97) yönlendirmesi altında makine tarafından okunabilir biçime dönüştürülmüştür.