← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 479 · mail

NIC Journal Tarafından FTP Kullanımı

Yazar
Kurum
Tarih
8 Mart 1973
Durum
Network Working Group Yorum Talebi
Kanal
mail/

NIC Journal Tarafından FTP Kullanımı

Network Working Group — James E. White (JEW)
Request for Comments: 479
NIC: 14948
Host: SRI-ARC
Tarih: 8 Mart 1973


Network Mail Meeting’de (bkz. -- 14317) NIC, FTP Journal teslimi ve gönderiminin uygulanması için gereksinimlerini ana hatlarıyla belirtmiştir.

Bu iki hizmetin uygulanmasının, her zaman File Transfer Protocol’ün MLFL komutuna dayanması gerektiği düşüncesindeydik.

Toplantıdan önce, örneğin gönderim durumunda, kullanıcının NIC’in gerekli gördüğü parametreleri (ör., bu posta parçasının journal’a alınacağını belirten bir işaret, NIC kimliklerinin bir listesi vb.) MLFL komutunun USERNAME alanına, kendi FTP kullanıcı sürecine saydam olacak bir biçimde yerleştireceğini ve SRI-ARC’in FTP sunucu sürecinin bu “kullanıcı adını” parametreler için ayrıştırarak Journal System’i bu parametreler ve postanın metni ile birlikte argüman olarak dahili biçimde çağıracağını öngörmüştük.

Amacımız (bu düzenlemenin karşılayacağı) yazılım değişikliklerini kendi sistemimizle sınırlarken istenen hizmetleri sağlamak ve özellikle kullanıcı FTP süreçlerinin ya da File Transfer Protocol’ün kendisinin değiştirilmesini gerektirmemekti.

Ancak toplantıya katılanların ortak görüşü, gerekli tüm parametrelerin açıkça bildirilebileceği şekilde FTP’nin değiştirilmesinin, yalnızca bir kullanıcı adı gibi görünen bir alanın içine gizlenmelerini gerektirmekten daha tercih edilir olduğu yönündeydi.

Bu RFC’nin amacı, posta gönderimi ve teslimini desteklemek için tanımlanması gerektiği üzerinde uzlaşıldığına inandığımız yeni FTP komutlarını (NIC olarak bizim) listelemektir. Aslında, konular üzerinde bir süre düşündükten sonra bazı düzenlemeler yaptık; dolayısıyla bu metin, toplantıda gelişen düşünce çizgileri doğrultusunda File Transfer Protocol’e dahil edilmesini görmek istediklerimizin bir açıklaması ve NIC’in bunları nasıl kullanacağına ilişkin kısa bir betimlemedir.

Komutların bazıları, şu anda yalnızca NIC’in FTP sunucu sürecine gönderildiklerinde (başka herhangi birine değil) anlamlıdır; diğerleri ise yalnızca NIC’in FTP kullanıcı süreci tarafından (başka herhangi biri tarafından değil) gönderildiklerinde anlamlıdır. Bunun nedeni, şu anda yalnızca NIC’in posta yönlendirme ve kayıt (yani Journal System) hizmetini sunmayı planlamasıdır. Ancak, gelecekte diğer host’lar da benzer bir hizmeti uygulamak isteyebilir; bu durumda bu özel komutlar daha geniş bir kullanım alanına sahip olacaktır.

Kavramsal olarak, bu komutların tümü yeni bir MAIL komutunun alt komutlarıdır; ancak şimdilik amaç, FTP diyaloğu içindeki konumlarını ya da sözdizimlerini tanımlamak değil, yalnızca kavramsal olarak betimlemektir. Sözdizimi ve kullanım ayrıntıları, 16-MAR-73’te Boston’da toplanacak olan FTP Interest Group’a bırakılmıştır (bkz. -- 14333).

Yeni alt komutlar aşağıda açıklanmaktadır. Köşeli parantez içindeki alanlar isteğe bağlıdır; eğik çizgi iki ya da daha fazla alternatiften birini belirtir.


Yeni FTP Alt Komutları

(1) TITLE başlık

Burada başlık, postanın içeriğini insan okuyucu için tanımlayan bir karakter dizisidir.

(2) USER-READABLE-AUTHOR yazar

Burada yazar, postanın yazarını insan okuyucuya tanımlar. Bu bir takma ad ya da insan göndericinin postasını imzalamayı seçtiği başka herhangi bir tanımlayıcı olabilir.

(3) PROCESS-READABLE-AUTHOR soyad, ad baş harfi (ident)

Burada yazarın adı (ve biliniyorsa ident’i), sunucunun (gerekirse) ayrıştırabileceğini umabileceği bir biçimde sunucuya sağlanır.

Bu alt komut, yazarı NIC’in Ident dosyalarında bulmak için bir temel sağladığından, NIC için önemlidir.

(4) FOR-ACKNOWLEDGMENT-AUTHOR kullanıcıadı hostadı

Burada kullanıcıadı ve hostadı, teslimin (yönlendirilmiş postanın) onaylanmasında yararlı olacak biçimde göndericiyi tanımlar.

Onay, NIC’ten hostadı üzerindeki kullanıcıadına gönderilen bir posta parçası olacaktır.

Burada NIC’in benzersiz rolüne kavramsal olarak dikkat etmek önemlidir. Normalde, sunucu tarafından postanın kabul edilmesi teslimin onaylanması anlamına gelir. Ancak Journal gönderimi durumunda NIC yalnızca bir yönlendirme aracısı olarak hareket eder; dolayısıyla göndericinin SRI-ARC’e posta teslim etmesi gerçekte teslim değildir—yalnızca gönderimdir. Nihai teslim, NIC’in postanın bir kopyasını her bir alıcısına iletmesiyle gerçekleşir; dolayısıyla bu özel onay türüne ihtiyaç vardır.

Bu alt komut ile önceki iki komutun, göndericinin adının farklı gösterimlerini oluşturduğuna dikkat ediniz.

(5) ACKNOWLEDGMENT-DETAILS

DEFAULT /
  (COMPLETION / FAILURE / PERIODIC aralık
   GIVEUP süre
   TERSE / VERBOSE)

İlk parametrenin değeri (DEFAULT’u şimdilik göz ardı ederek), göndericiye hangi koşullar altında onay gönderileceğini belirler:

İkinci parametrenin değeri, teslim denemelerinin hangi süreden sonra durdurulacağını belirler.

Üçüncü parametrenin değeri, henüz ayrıntıları belirtilmemiş bir anlamda, onayın ne kadar ayrıntılı olacağını belirler.

Ayrıntılı bir onay, teslim başarısızlığı durumunda, mesaj metninin bir kopyasını ya da atıf yoluyla gönderilen postalar için (aşağıdaki madde 10’a bakınız) buna bir işaretçi içerebilir.

DEFAULT belirtilmişse (bu durumda FOR-ACKNOWLEDGMENT-AUTHOR belirtilmemelidir ve DEFAULT ona da uygulanır), NIC, bir PROCESS-READABLE-AUTHOR alt komutu mevcutsa ve göndericinin NIC Ident’i bundan çıkarılabiliyorsa, Ident dosyalarından bir varsayılan değerler kümesi elde edecektir; aksi halde NIC, (henüz belirtilmemiş) bir sistem varsayılanları kümesini uygulayacaktır.

NIC’in Ident dosyaları, kendisi tarafından bilinen her kullanıcı için, kullanıcının genellikle istediği onay türünü (yani varsayılanını) ve bu tür onayların hedefini tanımlayan kullanıcıadı ile hostadını içerecek şekilde değiştirilecektir. Bu son iki bilgi, kullanıcı Network üzerinden teslim talep etmişse (NIC’te Online ya da basılı kopya yerine), postanın kullanıcıya tesliminde de kullanılacaktır.

(6) ADDRESSEES-ARE ad1, ad2, ...

Bu alt komut, postanın alıcı(lar)ını tanımlar. Genel olarak, adi sunucunun sisteminde alıcının yerel olarak bilindiği ad olacaktır.

NIC’in sunucu FTP süreci, adi’nin aşağıdakilerden herhangi biri olmasına izin verecektir:

Artık birden fazla alıcı olasılığının Protokol tarafından açıkça kabul edildiğine, ancak useri’nin (sunucuya göre) anlamının sunucuya bağımlı bırakıldığına dikkat ediniz.

(7) MAIL-CLASS

BULK / POSTCARD
SPECIAL-DELIVERY / FIRST-CLASS

İlk parametre, postanın boyutuna ilişkin bir ifade sunar ve sunucu bunu, postanın alıcı için nasıl ve nerede depolanacağına karar vermek üzere kullanmayı seçebilir.

İkinci parametre, postanın önemine ilişkin bir ifade sunar ve sunucu SPECIAL-DELIVERY posta için teslimi hızlandırmayı (ör., kullanıcı oturum açmışsa onu kesintiye uğratmayı) seçebilir.

(8) RECORD [tanımlayıcı] [çeşitli]

Bu, sunucuya postayı kaydetmesi için verilen komuttur. Tanımlayıcı, göndericiye, eğer varsa önceden atanmış bir tanımlayıcıyı belirtme seçeneği tanır; bu alan mevcut değilse, sunucu bir tane atar.

Çeşitli, sunucunun gerektirebileceği ya da izin verebileceği, sunucuya bağımlı parametreleri içerir.

Bu komut NIC’e verildiğinde, postanın Journal’a alınması için bir komut olarak kabul edilecektir ve tanımlayıcı şu olabilir:

NIC, çeşitli alanının yorumlar, anahtar sözcükler vb. bilgileri içermesine izin verebilir.

(9) PRESERVED-AT hostadı AS tanımlayıcı

Bu bir komut değil, FTP sunucusunun, örneğin TITLE komutunda yer alan bilgileri ilettiği gibi, muhtemelen kullanıcıya ileteceği bir olgu bildirimidir.

Bunun anlamı, bu posta parçasının bir kopyasının hostadı üzerinde korunduğu ve tanımlayıcı ile uzun vadeli olarak erişilebilir olduğudur. Tanımlayıcı genel olarak bir yol adı olabilir.

NIC, Journal makalelerini Net üzerinden teslim ettiğinde bu alt komutu içerecektir; bu durumda tanımlayıcı bir NIC numarası olacak ve hostadı elbette SRI-ARC ya da NIC olacaktır.

(10) TEXT metin / FILE yoladı hostadı

Bu iki alt komuttan biri, postanın fiilen iletilmesi için kullanılır: ilki postanın metnini iletir, ikincisi ise ona bir işaretçi iletir (postanın metninin belirtilen host’tan alınması seçeneğini FTP sunucusuna (ya da onun kullanıcısına) bırakır).

NIC, NLS içinde “Submit File” ile hazırlanan postayı FILE komutunu kullanarak, “Submit Message” ile hazırlanan postayı ise TEXT komutunu kullanarak iletecektir. Posta SRI-ARC sistemine FTP sunucu süreci aracılığıyla girdiğinde, NIC teslimde gönderimde kullanılan komutun aynısını kullanacaktır.


Bu RFC, çevrimiçi RFC arşivlerine giriş için Hannes Faestermann tarafından makine tarafından okunabilir biçime dönüştürülmüştür, 12/97.