Dosya Aktarım Protokolü Hakkında Yorumlar

Network Working Group — Mark Krilanovich (UCSB)
Request for Comments: 624 — George Gregg (UCSB)
NIC #: 22054 — Wayne Hathaway (AMES-67)
References: RFC 542 — Jim White (SRI-ARC)
Obsoletes: RFC 607
Date: Şubat 1974

Bu belge, henüz taslak aşamasındayken yanlışlıkla yayımlanan RFC 607’nin yerine geçmektedir. RFC 607’nin göz ardı edilmesi ve bu belgenin yazarların görüşlerinin doğru ifadesi olarak kabul edilmesi memnuniyetle karşılanacaktır.

RFC 542’de tanımlanan Dosya Aktarım Protokolü’nün ciddi sakıncalar oluşturan çeşitli yönleri vardır. Bunların bazıları oldukça temel niteliktedir ve önemli tasarım değişikliklerini ima eder; bunlar daha sonraki bir RFC’de ele alınacaktır. Diğerleri ise çok az çabayla giderilebilir ve bunun mümkün olan en kısa sürede yapılması gerekir.

Aşağıda, kolayca çözülebilecek bu sorunların bir listesi ve önerilen çözümleri yer almaktadır:

Kolayca Çözülebilen Sorunlar ve Önerilen Çözümler

1. Bir sunucu, veri bağlantılarının kurulması açısından "pasif" durumda ayarlandıktan sonra, kullanıcının onu yeniden "aktif" hale getirmesi için uygun bir yol yoktur. "REIN" komutu bunu gerçekleştirir, ancak istenen aktif/pasif durumdan daha fazlasını etkiler.
   ÇÖZÜM: Sunucunun veri soketi üzerinde LISTEN yerine CONNECT göndermesi anlamına gelen, komut fiili "ACTV" olan yeni bir komut tanımlansın. Sunucu zaten "aktif" durumdaysa, bu komut etkisiz bir işlem olur. "ACTV", "PASV" ile aynı yanıt kodlarına sahip olacaktır.

2. Tüm komut fiillerinin aynı uzunlukta olması, bir FTP sunucusu ya da kullanıcısının tasarımını daha basit hale getirirdi. Değişken uzunluklu fiillerin ele alınması elbette mümkündür; ancak sabit uzunluklu dizge işleme, genel olarak yazılması daha kolay ve çalıştırılması daha hızlıdır ve bu uygulamada değişken uzunluklu dizgelere izin verilerek herhangi bir kazanç elde edileceği de görünmemektedir.
   ÇÖZÜM: Üç harfli tek fiil olan "BYE" yerine "QUIT" gibi dört harfli bir fiil kullanılsın ve gelecekteki komut fiillerinin dört harf uzunluğunda olması zorunlu kılınsın.

3. Bir dosya aktarım komutunu izleyen el sıkışma öğelerinin sırası belirtilmemiştir. Örneğin bir STOR komutu gönderildikten sonra, bir kullanıcı sürecinin ilk olarak hangisini bekleyeceğini bilmesinin bir yolu yoktur: "250 FILE TRANSFER STARTED" yanıtı mı, yoksa veri bağlantısının kurulması mı.
   ÇÖZÜM: Sunucunun, veri bağlantısını kurmaya çalışmadan önce bir "250" yanıtı göndermesi belirtilecektir. Kullanıcının oturum açıp açmadığını, dosyanın var olup olmadığını ya da kullanıcının dosyaya erişimine izin verilip verilmeyeceğini denetlemek isteniyorsa, bu kontroller herhangi bir yanıt gönderilmeden önce yapılmalıdır. "250" yanıtının metni, gerçek veri aktarımı başlamadan önce geldiği için muhtemelen "250 OPENING DATA CONNECTION" olarak daha uygun olacaktır. Sunucu, veri bağlantısının açılamaması durumunda bir hata yanıtı göndermek isterse, bu yanıt "252 TRANSFER COMPLETE" yanıtı yerine gönderilecektir.

4. Bazı ana makineler, gerek duyulmadığı için uygulanmamış bir komut alındığında (örneğin "ACCT" veya "ALLO") bir hata yanıtı göndermektedir. Yanıtın metni komutun yok sayıldığını belirtse bile, bir kullanıcı sürecinin gerçek bir "hata" olmadığını bilmesi açıkça imkânsızdır.
   ÇÖZÜM: Belirli bir komutu, o sistemde gerekli olmadığı için desteklemeyen herhangi bir sunucunun, bu komut için başarı yanıtını döndürmesi zorunlu kılınsın.

5. Bir TELNET komut satırının, TELNET yanıt satırının, kullanıcı adının, parolanın, hesabın veya yol adının azami uzunluğu belirtilmemiştir. Bir FTP sunucusu uygulayan her sistemin kendi parametreleri için farklı üst sınırlara sahip olması muhtemeldir; ancak birçok FTP sunucusuyla iletişim kurmak zorunda olan bir FTP kullanıcısı yazarı için belirsiz uzunlukta bir arabellek oluşturmak, en azından bazı sistemlerde, elverişsizdir. Benzer zorluklar bir FTP sunucusu yazarı için de geçerlidir.
   ÇÖZÜM: TELNET komut satırları, TELNET yanıtları, kullanıcı adları, parolalar, hesap numaraları ve yol adları için bir azami uzunluk belirtilecektir. Bu, hizmet veren sitelerin kendi üst sınırları hakkında bir anket yapıldıktan sonra gerçekleştirilecektir. Ağ postası FTP’ye dâhil edilecekse, TELNET bağlantısı üzerinden gönderilen posta metni de aynı satır uzunluğu üst sınırına tabi olacaktır.

6. Devam satırlarının rastgele bir metinle başlamasına izin verme düşüncesi, birkaç sunucu FTP uygulayıcısı için küçük bir sorunu çözerken, tüm FTP kullanıcı uygulayıcıları için büyük bir sorun oluşturmaktadır. Çok satırlı bir yanıtı çözümlemek için gereken mantık gereksiz yere karmaşıktır ve çok satırlı yanıtların iç içe geçmesine izin verilmesi nedeniyle bu karmaşıklık bir büyüklük mertebesi daha artmaktadır.
   ÇÖZÜM: İlk satırdan sonraki tüm çok satırlı yanıt satırlarında kullanılmak üzere "009" gibi benzersiz (sayısal) bir yanıt kodu atanacaktır. Bu amaçla kullanılan yanıt kodu "0" ile başlamalıdır (örneğin üç boşluk olamaz); böylece yanıt kodu gruplamalarıyla ilgili hâlihazırda var olan kurallar sayesinde bir kullanıcı süreci için fazlalık olarak görünecektir.

7. (6) için yukarıdaki çözüm kabul edilmezse, izin verilen azami iç içe geçme düzeyinin belirtilmemiş olması, FTP kullanıcı uygulayıcıları için bir güçlük çıkarmaktadır. Donanımsal yığıtlara sahip bir makinede bu güçlük nispeten kolayca çözülebilirken, diğer makineler için durum böyle değildir.
   ÇÖZÜM: Ya iç içe yanıtlar yasaklansın (tercih edilen), ya da çok satırlı yanıtların azami iç içe geçme düzeyi belirtilecektir.

8. Çeşitli yanıt kodlarının anlamlarına ilişkin düzyazı açıklamalar, birçok durumda belirsiz veya muğlaktır. Örneğin "020" kodu yalnızca "FTP duyurusu" olarak açıklanmaktadır. Bir sunucunun ICP’den hemen sonra girdi kabul edemediği durumlarda gönderilebilecek bir yanıt olarak verilmektedir, ancak kesin anlamı açık değildir. Ayrıca "331" kodunun "HESAP GİRİN (oturum açma dizisinin bir parçası olarak gerekliyse)" anlamına geldiği söylenmektedir, ancak çoğu komut için olası bir başarı yanıtı olarak listelenmiştir. Açıklama, bunun yalnızca oturum açma dizisinde geçerli olduğunu gösterirken, komut-yanıt eşleştirme tablosu aynı zamanda "Bunu bir hesap olmadan yapamam" anlamına da geldiğini ima etmektedir.
   ÇÖZÜM: Yanıt kodlarını ortaya koyanlar tarafından, bunların daha eksiksiz tanımlanması için genişletilmiş bir çaba gösterilmelidir.

Protokolle ilgili başlıca bir şikâyet, bir FTP kullanıcı süreci yazarının, gönderilen son komutun başarılı olup olmadığını belirlemek için yalnızca çok sayıda özel durumu ele almak zorunda kalmasıdır. Protokolün aşağıdaki alanların tümünde iyi tanımlandığı kabul edilmektedir; ancak "iyi tanımlı" olma özelliğinin gerekli olmakla birlikte yeterli olmadığını fark etmek önemlidir. Pek çok nedenden dolayı, tüm gereksinimleri karşılayan en basit mekanizmayı kullanmak son derece arzu edilir. Aşağıda, bir FTP kullanıcı sürecinin akış şemasını gereksiz yere karmaşıklaştıran bu sakıncaların bir listesi yer almaktadır:

Başarı/Başarısızlık Belirlemesini Etkileyen Sorunlar

9. Farklı komutların farklı başarı yanıt kodları vardır. Örneğin başarılı bir "USER" komutu "230" döndürürken, başarılı bir "BYTE" komutu "200" döndürür. İlk hanenin bu bilgiyi taşıyacağı yönündeki ifade edilen kavram geçerli değildir; çünkü "100", "STAT" için başarı anlamına gelirken, "200" "SOCK" için başarı anlamına gelmektedir.
   ÇÖZÜM: Herhangi bir komutun başarılı olması durumunda, "2" gibi benzersiz bir rakamla başlayan bir yanıt kodu döndürmesi; başarılı olmaması durumunda ise bu rakamdan farklı bir şeyle başlaması belirtilecektir. Örneğin bu, STAT için başarı yanıtının muhtemelen "200" olarak değiştirilmesini de kapsar.

10. Bazı komutların birden fazla olası başarı yanıt kodu vardır; örneğin "USER" ve "REIN". Bir FTP kullanıcısının, her biri "komut kabul edildi, devam et" anlamına gelen yanıt kodlarının bir listesini her komut için tutmak zorunda bırakılması arzu edilmez. Yine, ilk hane ile ilgili ifade edilen kavram başarısız olur; çünkü "230" ve "330" gerçekte başarılı bir "USER" komutuna verilen iki onaydır.
    ÇÖZÜM: Yukarıdaki (9) için verilen çözümle aynıdır. Sadece "evet" ya da "hayır"dan daha özgül bilgi iletme isteği — örneğin bazı sunucuların tüm oturum açma parametrelerine ihtiyaç duymaması durumu — şu şekilde çözülebilir: "230" "PAROLA KABUL EDİLDİ, ARTIK OTURUM AÇTINIZ" anlamına gelirken, "237" "PAROLA KABUL EDİLDİ, ŞİMDİ HESAP GEREKLİ" anlamına gelebilir. Yukarıdaki (4) için verilen çözüm göz önüne alındığında, bir kullanıcı süreci "ARTIK OTURUM AÇTINIZ" ile "ŞİMDİ HESAP GEREKLİ" arasındaki farkla çok daha az ilgilenir hale gelir. Önemli nokta, "komut kabul edildi" fikrinin baştaki "2" ile iletilmesidir; daha ince anlam farklılıkları ise istenirse kullanıcı süreci tarafından çıkarılabilir.

11. Çeşitli bağlantı karşılama yanıt kodlarının anlamları bir ölçüde tutarsızdır. "300 bağlantı karşılaması, girdi bekleniyor", ICP’ye olumlu bir onay olarak düşünülüyorsa, 200 serisi bir yanıt olmalıdır; ya da yalnızca bilgilendirici olması amaçlanıyorsa, 000 serisi bir yanıt olmalıdır. İlki söz konusuysa, "020 beklenen gecikme" açıkça buna karşılık gelen olumsuz onaydır ve 400 serisi bir yanıt olmalıdır. Bununla birlikte, beklenen bir gecikmenin bildirilmesinin, gecikmenin süresi bilinmeden bir kullanıcı süreci için önemli olması pek olası değildir.
    ÇÖZÜM: "300 bağlantı karşılaması" 000 serisi bir yanıt olarak değiştirilsin; tercihen "011". Alternatif olarak, "300 bağlantı karşılaması" 200 serisi bir yanıt olarak, örneğin "211" olarak; "020 beklenen gecikme" ise 400 serisi bir yanıt olarak, örneğin "411" olarak değiştirilsin.

Yukarıda belirtilen protokol zayıflıklarına ek olarak, aşağıdakinin bir dizgi hatası olduğu düşünülmektedir:

12. "332 LOGIN PLEASE" yanıt kodu, komut-yanıt eşleştirme tablosunun hiçbir yerinde listelenmemiştir. Bunun, kullanıcının oturum açmış olmasını gerektiren tüm komutlar için daha fazla bilgi gerektiğini belirten bir (başarı) yanıt olması gerektiği anlaşılmaktadır. Ayrıca "332" kodunun bu amaçla kullanılması gerektiği özellikle vurgulanmalıdır; zira günümüzde birçok sunucu "LOGIN PLEASE" anlamında "451" ve "504" gibi başka kodlar kullanmaktadır.