← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 414 · ftp

Dosya Aktarım Protokolü (FTP) Durumu ve Ek Yorumlar

Yazar
A. Bhushan
Kurum
Tarih
29 Kasım 1972
Durum
Network Working Group Yorum Talebi
Kanal
ftp/

Ağ Çalışma Grubu

Yorum Talebi: 414
Günceller: RFC 354, RFC 385
NIC: 12406

Yazar: A. Bhushan
Bağlı Kurum: MIT-MAC
Tarih: 29 Kasım 1972

Dosya Aktarım Protokolü (FTP) Durumu ve Ek Yorumlar

Şu anda birçok HOST çalışır durumda sunucu ve kullanıcı FTP’lerine sahiptir. Aşağıda, bilgim dahilinde FTP uygulamalarının durumu yansıtılmaktadır:

Tüm TENEX sistemlerindeki sunucular aşağı yukarı aynıdır (BBN’de Bob Clements tarafından geliştirilmiştir). MIT-AI ve MIT-ML’deki sunucular da aynıdır (MAC’ten Pitts Jarvis tarafından geliştirilmiştir). Şu anda FTP ile ilgilenen diğer kişiler arasında Arvola Chan (AC@MIT-DMCG), Ken Pogran (Multics), Greg Hicks (HICKS@UTAH), Wayne Hathaway (AMES-67), Ralph Gorin (SU-AI), Rick Werme (CMU) ve Ron Stoughton (UCSB) bulunmaktadır.

Kullanıcı-FTP, yani FTP’nin kullanıcı arayüzü, istenen ve ilginç özelliklerin eklenebileceği yerdir. Böyle bir özelliğe örnek olarak, BBN (ve diğer TENEX’ler) SNDMSG USER@HOST özelliği verilebilir; bu özellik yerel bir kullanıcının diğer ağ kullanıcılarına mesaj (veya posta) göndermesine olanak tanır. Uzak host çalışır durumda değilse, mesaj kullanıcının dizininde --UNSENT-MAIL--USERHOST olarak saklanır ve arka plan görevi bu tür dosyaları periyodik olarak kontrol ederek postayı göndermeye çalışır. MIT-AI ve MIT-ML’de dosyaların kolay aktarımına olanak tanıyan bir TRANS komutu vardır. MIT-DMCG’de ise CALICO alt sistemi altında, yerel kullanıcıların ağ üzerinden posta göndermesine, dosyaları verimli biçimde kopyalamasına ve kullanıcıları ile dizinleri yerel kullanım benzeri bir şekilde listelemesine olanak tanıyan genelleştirilmiş komutlar geliştirdik (yani, açıkça bağlanma, oturum açma ve uzak bir HOST’a komut gönderme gereği olmadan). Ayrıca TELNET, FTP ve RJS kullanıcılarının bir “başlangıç” dosyasından otomatik olarak “oturum açmasına” ve diğer komut dizilerini gerçekleştirmesine izin veriyoruz.

“Image 36” modunda PDP-10’lar arasındaki dosya aktarımının, “ASCII 8” moduna kıyasla bir büyüklük mertebesi daha hızlı (ve daha verimli) olduğu belirtilmelidir. Ayrıca, kullanıcı-FTP’de bir “Quote” veya “talk” modu sağlanmasının, kullanıcının FTP sunucusuna doğrudan komut girmesini (yani kullanıcı-FTP’de uygulanmamış komutları) mümkün kılması açısından yararlı olduğu da not edilmelidir. Kullanıcı ve sunucu FTP özelliklerinin ve arzu edilen kullanım biçimlerinin belgelenmesi ve RFC mekanizması aracılığıyla raporlanması istenmektedir.

Aşağıdaki öneriler ve eklemeler, NWG/RFC 354 ve NWG/RFC 385’te belirtilen Dosya Aktarım Protokolü ile ilgilidir. Bu RFC’ye gelen yorumlar alındıktan sonra, üç RFC’yi tek bir belgede birleştirip çok yakında ARPANET Resmî Dosya Aktarım Protokolü olarak yayımlayacağım. Bununla birlikte, FTP’nin denemelere açık, uçları belirlenmemiş bir protokol olduğu unutulmamalıdır. Gelecekte yeni komutlar, yanıt kodları, veri gösterim türleri ve dosya yapıları tanımlanabilir. İki site anlaşırsa, kendi deneysel komut, veri türü, dosya yapısı ve/veya aktarım modu kümelerini tanımlayabilirler. Protokole yapılan bu tür eklemeler iyi belgelenmeli ve açıkça belirtilmelidir ki diğer siteler de aynı olanaklardan yararlanabilsin.

1. Satır Yönelimli Etkileşim

FTP, yerel yankı ile satır satır etkileşim varsayar. Sunucunun uzak yankı sağlaması zorunlu değildir ve TELNET denetim karakterlerini yok sayabilir. Ancak bir sunucu, TELNET denetim karakterlerini aldığında hata ya da kötü bir yanıt vermemelidir.

Sunucu, karakter silme veya satır temizleme karakterleri gibi herhangi bir düzenleme yeteneğini açıkça sağlamaz. Tüm düzenlemenin yerel olduğu varsayılır. TIP kullanıcıları FTP’yi satır modunda kullanmalı ve hem <CR> hem de <LF> göndermelidir (TIP komutları @T O L ve @I L ile). Bu modda, TIP kullanıcısı geçerli giriş satırını temizleme komutu (@F) ile temizleyebilir.

Sunucu, TELNET SYNCH aldığında geçerli komut satırını temizleyerek ABOR komutu gibi kullanıcı girdisini beklemelidir. BYE veya STAT gibi diğer komutlar da kabul edilebilir bir girdi oluşturabilir.

2. Durum Bilgisinin Sonu

TELNET bağlantısı üzerinden birden fazla satır çıktı üretecek STAT gibi komutlar, durum bilgisinin sonunu açıkça belirtecek bir yönteme ihtiyaç duyar. Durum bilgisinin sonu için 200 status complete yanıtının açık bir gösterge sağlaması önerilmektedir. STAT yanıtı 1xx (burada x = rakam) ile başlayan bir satırla başlamalı, sonraki satırların ilk karakteri rakam olmamalı ve durum 200 yanıtı ile sona ermelidir. (Üç boşluk gereksiniminin, ilk karakterin rakam olmaması gibi daha az kısıtlayıcı bir gereklilik lehine kaldırıldığına dikkat ediniz.) Bu değişiklik, hem kullanıcı hem de sunucu FTP’leri için işlemleri çok daha kolay hale getirecektir.

3. BYE Komut Sözdizimi

BYE<CR><LF> biçiminin geçerli olduğuna dair bir hatırlatma. Boş bir argüman varsa, komut adından sonra bir boşluk gerekli değildir.

4. STAT ve LIST Yanıtları

STAT ve LIST komutları için aşağıdaki yanıtlar önerilmektedir (özellikle boş argüman durumu için bu konu açıkça belirtilmemişti). STAT ve LIST yanıtları sırasıyla her zaman TELNET ve Veri bağlantıları üzerinden gönderilecektir.

5. Yeni Komutlar: HELP ve NLST

Burada iki yeni komut önerilmektedir.

Birincisi, kullanıcıya sunucunun kullanımı ve uygulama durumu (haberler) hakkında yararlı ipuçları göndermesi gereken HELP komutudur. Bilgiler TELNET bağlantısı üzerinden 100 türünde bir yanıtla başlayacak ve 200 türünde bir yanıtla (tamamlama) sona erecektir. Bu komutun ve ayrıca MAIL ve BYE komutlarının, kullanıcının oturum açmasına gerek kalmadan (yani geçerli kullanıcı, parola ve hesap sağlamadan) kullanılmasına izin verilmesi önerilmektedir.

Diğer komut (Bob Clements tarafından önerilmiştir), yalnızca dosya adlarını (CRLF ile ayrılmış geçerli yol adı dizgeleri olarak) ve başka yararlı fakat kafa karıştırıcı bilgi içermeden gönderen, NLST adlı yeni bir dizin listeleme komutudur. Bu, bu komut ile saklama ve geri alma komutlarını kullanarak tüm bir dizinin otomatik olarak kopyalanmasını mümkün kılar. Bu komutun sözdizimi ve biçimi LIST komutu ile aynıdır (bazı HOST’lar için bunlar aynı komut olabilir).

6. Varsayılan Komutların Kabulü

Asgari uygulama TYPE, BYTE, MODE ve STRU komutlarını gerektirmese de, bu komutların varsayılan değerlerle, asgari uygulamaya sahip olanlar tarafından bile kabul edilmesi önerilmektedir. Bu, TYPE A ve STRU F gibi girdilere verilen ve sunucu için tamamen kabul edilebilir olan bazı “çirkin” hata yanıtlarını önleyecektir.

7. MLFL ve LIST için TYPE Gereksinimleri

MLFL ve LIST komutları kullanılırken, TYPE’ın ASCII (8 bit baytlar) olmasını sağlamak kullanıcının (veya kullanıcı-FTP’nin) sorumluluğundadır. TYPE ASCII dışında ise, sunucu bir hata yanıtı gönderebilir ve komutu reddedebilir. Bu nedenle kullanıcı (veya kullanıcı-FTP), TYPE ASCII dışında ise MLFL veya LIST komutlarını göndermeden önce sunucuya TYPE A komutunu göndermelidir.

8. MAIL ve MLFL’de Birden Fazla Kullanıcı Adı

Yararlı bir öneri, MAIL ve MLFL komutlarında birden fazla kullanıcı adına izin verilmesidir. Çoğu zaman bir kullanıcı, aynı postayı belirli bir sitedeki birden çok kullanıcıya göndermek ister. Bunu tek bir aktarım ve komutla yapabilmesi çok kullanışlı olacaktır. Sunucu sitelerinin bu seçeneği uygulaması kuvvetle tavsiye edilmektedir.

9. Standart Yol Adı Sözdizimi

Yapılan bir diğer öneri, FTP’de yol adı sözdiziminin standartlaştırılmasıdır. TENEX sisteminde alt dizinlerin yakında devreye alınacağı görülmektedir. Bunun standart yol adı sözdizimi üzerinde bir etkisi olabilir. Herhangi bir standart yol adı düzeninin gereksinimleri, yerel yol adı kurallarının rahat kullanımına olanak tanıması ve bunlarla çakışmamasıdır.

Makul bir öneri, standart yol adının > gibi özel bir karakterle (Multics’te olduğu gibi) başlaması ve bu özel karakterin yol adının öğelerini ayırmak için kullanılmasıdır. Özel karakter, bir yol adı öğesinin geçerli bir parçasıysa, '> (özel karakterden önce tek tırnak) biçimindeki birebir alıntı kuralı kullanılmalıdır.

Bu kurala göre yol adı örnekleri şunlardır:

10. Hesap Yanıt Kodları

TENEX’lerin hesap numarası gereksinimi, mevcut yanıt kodu dizileri altında FTP kullanan otomatlar için bazı sorunlara yol açmıştır. Bu nedenle, hesap gereksinimini ele almak üzere iki yeni yanıt kodu tanımlanmaktadır:

11. Ek Öneriler

Wayne Hathaway tarafından yapılan (RFC yakında yayımlanacak) aşağıdaki öneriler makul görünmektedir ve protokole dahil edilmelidir:

  1. Aşağıdaki Kayıt Sonu koşulu, Dosya Sonu içinde ima edilmek yerine son kayıtta açıkça belirtilmelidir. Bu değişiklik, sunucu uygulamasını basitleştirecek ve güvenilirliği artıracaktır (daha iyi hata denetimi).
  2. Kullanıcı-FTP uygulayıcıları, ASCII türü ve Akış modunda (kayıt sonu için varsayılan CRLF kuralı) kayıt yapılarının uygulanmasının kendileri için son derece kolay olduğunu dikkate almalıdır. Tüm kullanıcı-FTP’ler, ASCII türü ve akış modu ile kayıt yapılı dosyaların saklanmasına veya geri alınmasına izin vermelidir.
  3. Kayıt yapılı “print-file” türlerinin (ASCII türüne ek olarak) hem akış hem de metin modlarında gönderilmesi mümkündür (RFC 354 bu konuda açık değildi).
  4. TELNET synch mekanizması, ABOR’a ek olarak BYE ve STAT gibi diğer komutlara da genişletilmelidir.
  5. NOOP, CLSE ve SRVR komutlarının arzu edilirliği konusunda yorumlar davet edilmektedir. Benim görüşüme göre, boş argümanlı bir STAT komutu NOOP’un amacına (sunucunun hâlâ çalışır durumda olup olmadığını görmek) hizmet eder ve BYE komutu CLSE’nin amacına hizmet eder (USER komutu kullanıcı adını değiştirmek için kullanılmalıdır). SRVR yararlı bir komuttur.

12. Blok Modunda Hata Saptama

Bob Clements, hata saptama ve denetim konusundaki eski meseleyi yeniden gündeme getirmiştir. Bunu ele almak için, Blok modunda iki yeni tanımlayıcı kod tanımlayabiliriz: biri blok denetiminin başlangıcını, diğeri ise blok denetiminin sonunu (ve blok denetim baytlarını içererek) gösterir. Bu kodlar, hata saptama düzenini uygulamak istemeyen herhangi bir site tarafından yok sayılabilir. Hata denetimi düzeni ve bunun FTP’ye dahil edilmesinin arzu edilirliği konusundaki görüşleriniz talep edilmektedir.

Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere makine tarafından okunabilir biçime Helene Morin tarafından, Via Genie aracılığıyla, 12/99 tarihinde dönüştürülmüştür.