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

Ağ Postası Toplantı Özeti

Yazar
Kurum
Tarih
23 Şubat 1973
Durum
Network Working Group Yorum Talebi
Kanal
mail/

Ağ Postası Toplantı Özeti

NWG/RFC #469
NIC 14798
Michael D. Kudlick (MDK), SRI-ARC
8-MAR-73

Giriş

Bu RFC’nin amacı, NIC’in bakış açısından, 23 Şubat 1973 Cuma günü SRI-ARC’ta düzenlenen Ağ Postası Toplantısı’nda varılan temel sonuçları kısaca özetlemektir.

Toplantıda ele alınan konuların kapsamlı özeti için Abhay Bhushan tarafından hazırlanan RFC #475’e (NIC 14919) bakınız.

Mevcut RFC ile RFC #475 arasında önemli bir görüş ayrılığı yoktur.

RFC #453 (NIC 14317) toplantıya ilişkin arka plan bilgilerini içermektedir.

RFC #479 (NIC 14948), NIC’in Ağ Postası amaçları için Dosya Aktarım Protokolü’nde nelerin yer almasını istediğini ve ayrıca NIC’in bu bilgileri nasıl kullanacağını kısaca açıklamaktadır.

Mevcut RFC aşağıdaki şekilde düzenlenmiştir:

Sonuçlar

Ek FTP posta gereksinimleri kararlaştırılmıştır. Bunlar, aşağıdaki alt komutlara sahip yeni bir posta komutu olarak uygulanacaktır:

TO

Bu alanın, standart bir sözdizimi olan user@host biçiminde, birden fazla alıcı içermesine açıkça izin verilmektedir.

FROM

Bu alan, teslim edilemeyen postalar için bildirim amacıyla bir dönüş adresi sağlar ve ayrıca alıcının bilgisi için göndericinin açık bir biçimde tanımlanmasını sağlar.

AUTHOR

Bu alan, postanın yazarını belirtir. Birden fazla yazar olabilir.

TITLE

Postanın "başlığı" (yani konu), nokta ve satır başı (carriage return) ile sonlandırılacaktır.

ACKNOWLEDGEMENT success / failure (time out) / normal

Çoğu durumda muhtemelen NIC olan ara ana bilgisayar tarafından, göndericiye posta gönderme girişiminin sonucunu bildirmek için kullanılır. (Not: "normal" tanımlanmamıştır.)

RECORDED jnumber / null

Not: "jnumber", biliniyorsa kullanılacak olan önceden atanmış erişim numarasıdır (NIC numarası).

RECORDED alt komutu, postanın kayda alınması seçeneğini sağlar. Bu alt komutla verilen bilgiler NIC tarafından tanınacaktır. Seçenekler şunlardır:

Bu alan, alıcıyı postanın kayda alındığı konusunda bilgilendirmek için de kullanılacaktır.

(Geriye dönük olarak, alıcıyı bu durumdan haberdar etmek için ayrı bir komutun tercih edilebilir olabileceği düşünülmektedir, ancak 23-Şub-73 toplantısında bu konuda bir karar alınmamıştır.)

TYPE long / urgent / ordinary

Bu, alıcı sitenin postayı depolama konusunda uygun gördüğü herhangi bir işlemi yapmasına olanak tanır.

TEXT / FILE / CITATION

TEXT

Bu alan, posta iletisinin metni içindir.

FILE

Bu alanın amacı bana net değildir. Göndericinin alıcının okumasını istediği dosyaya makine tarafından okunabilir bir işaretçi mi içerir?

CITATION

Bu alan, göndericinin alıcının okumasını istediği dosyaya kişi tarafından okunabilir bir işaretçidir. Citation komutu kullanıldığında, citation dışında başka bir posta gönderilmez.

Tartışma

Giriş

Çözümdeki kilit unsurlar şunlardır:

  1. FTP’ye dayalıdır.
  2. NLS’nin doğrudan kullanılmasını gerektirmeden NIC’i kullanır.
  3. Kullanıcı kimliklerinin kullanımında birörnekliği sağlayan bir mekanizma vardır.
  4. Postanın daha sonra başvurulabilmesi için kayda alınmasına yönelik bir mekanizma vardır.

Bu konular aşağıdaki tartışmada ele alınmaktadır.

Yeni FTP Posta Alt Komutları

TO

Alıcı Biçimi

Adresin standart biçimi şudur: user@host.

"User", bir kişinin soyadı olabileceği gibi, alıcının seçtiği ve ağın geri kalanına bildirdiği başka bir kimlik de olabilir.

Hedef ana bilgisayar, hedef alıcının kimliğini tanımazsa, göndericinin ana bilgisayarına bir "teslim edilemedi" posta iletisi geri gönderir. Bireyin, bulunduğu yerle ilgili bilgileri NIC’e güncel tutması kendi sorumluluğundadır; aksi takdirde postasını zamanında alamayabilir.

NIC’in Rolü

NIC’in, A noktasından B noktasına gönderilen ve NIC’te kayda alınmayacak olan postalar için hiçbir rolü olmak zorunda değildir.

NIC’te kayda alınacak postalar için RECORDED alt komutu kullanılacaktır.

Ayrıca, gönderici alıcıların standart adresini bilmiyorsa, bu bilgiyi edinmek için NIC’i kullanabilir.

Kimlikler ve Adresler

NIC, her birey için user@host standart adresini içerecek şekilde kimlik dosyalarını değiştirecektir.

Siteler, NIC Kimliği’nden veya bir kullanıcının soyadından standart adrese çeviri yapması için NIC’ten istekte bulunabilir. Bu çeviriyi yapmak üzere NIC’te istek üzerine çalışan bir sorgu olanağı sağlanacaktır. Çeviri hizmeti grup kimlikleri için de kullanılabilir olacaktır.

Bu hizmet, kabul ettiği protokol açısından FTP benzeri olacaktır, ancak FTP’nin kendisi içinde yer almayacaktır. Kimlik çeviri isteklerini farklı bir sunucu süreci ele alacaktır.

NIC, teslimat yolunda ara bir nokta olarak kullanıldığında, çeviri NIC’te de yapılacaktır.

NIC, postanın NIC günlüğü öğesi olarak kayda alınması ve postanın nihai hedeflerine iletilmesi için bir ara nokta olabilir. Bu süreçte NIC, NIC kimliklerinden standart adreslere çeviri yapacaktır.

NIC kimlik dosyalarında, kayda alınmış (NIC Günlüğü) postaların basılı kopya veya çevrimiçi teslimatını belirtmeye yönelik bir olanak zaten mevcuttur.

Bu olanak, "ağ" özniteliğini içerecek şekilde genişletilecektir; bu, "postayı bu kişinin ana bilgisayarına teslim et" anlamına gelir.

Ağ özniteliği, tüm postaların göndericide tutulması ve yalnızca bir bildirim iletisinin gerçekten postalanmasıyla sınırlandırılabilir.

Bildirim, "to", "from", "title", "gönderim tarihi" ve "postanın konumu" bilgilerini veren bir citation biçiminde olacaktır.

TIP Kullanıcıları

TIP kullanıcılarının hem posta gönderebilmesi hem de alabilmesi için, bazı ana bilgisayarların bu kullanıcılar için "ev" site olması gerekeceği önerilmiştir (ancak kullanıcı başına birden fazla "ev" site olmayacaktır).

Yani, bir TIP kullanıcısının posta göndermesine ve almasına izin veren bir hesabın bu tür bir ana bilgisayarda kurulması gerekecektir.

Şimdilik, herhangi bir TIP kullanıcısı posta gereksinimleri için SRI-ARC sistemini kullanabilir.

TIP’lerin, postayı yazdırmak için sürekli kullanılabilir bir basılı çıktı aygıtıyla donatılması şeklindeki alternatif bir çözüm, yukarıdaki yaklaşım lehine terk edilmiştir.

FROM

FTP’deki FROM komutu, göndericiyi standart adres biçiminde tanımlar.

Bu, teslim edilemeyen postalarla ilgili bildirimlerin kaynak kişiye geri gönderilmesine olanak tanır.

Varsayılan durumda, göndericinin ana bilgisayarı, posta alıcının ana bilgisayarına teslim edilene kadar postayı saklamak zorundadır.

"Teslim edildi", alıcının ana bilgisayarının postayı kabul ettiği anlamına gelir. Alıcının postayı okuduğu anlamına gelmez.

Alternatif olarak, gönderici bir ara ana bilgisayarın postayı saklamasını belirleyebilir. Bu durumda, ara ana bilgisayar postanın tüm hedef alıcılara teslim edilene kadar saklanmasından sorumludur.

ACKNOWLEDGEMENT komutu, postanın teslim edildiğini belirten isteğe bağlı, olumlu bir bildirimin posta kaynağına (FROM alıcısına) verilmesine olanak tanır.

AUTHOR

AUTHOR birden fazla kişi olabilir. Kayda alınmış belgeler için, yazarlar yazar dizininde ayrı ayrı görünür; bu, yazar biliniyor ancak postanın başlığı ve konumu bilinmiyorken postayı aramayı kolaylaştırır.

TITLE

TITLE alanı, özellikle kayda alınmış postalar için yararlıdır; çünkü başlıktaki anahtar sözcükler üzerinden dizinler nispeten kolay üretilebilir ve posta aramayı kolaylaştırır.

Bu nedenle, başlık içeriğin özlü bir göstergesi olmalıdır.

ACKNOWLEDGEMENT

Teslim edilememe durumuna ilişkin bildirim göndericiye verilmelidir.

Göndericinin isteği üzerine, postanın alıcının site adına başarıyla teslim edildiğine dair isteğe bağlı, olumlu bir bildirim verilecektir (ABD CERTIFIED postasına benzer şekilde).

Alıcının postayı gerçekten gördüğüne dair herhangi bir bildirim verilmeyecektir (ABD REGISTERED postasının olmamasına benzer).

RECORDED

Kayda alınmış posta kavramı, postanın kalıcı bir kaydının merkezi olarak tutulmasını ve gelecekte postaya başvurulmasını ve yeniden okunmasını sağlar.

Örneğin, NIC Günlüğü sisteminde, Günlüğe girilen tüm öğelerin bir kaydı tutulur. Bu kayıttan, başvurular ve yeniden okumalar için yazar, başlık-sözcük ve NIC numarası dizinleri üretilir.

Kayda alınmış Günlük öğelerinin geri getirilmesinin anahtarı, bir erişim numarasının (NIC numarası) kullanılmasıdır. Bu, esasen yinelenen dosya adlarının kullanılma olasılığını ortadan kaldırır.

Posta toplantısında tartışılan kayda alınmış postanın temel yönü, bir erişim numarasının atanmasıdır.

Erişim numaralarının, önceden atama yapılmaksızın ve yerel olarak numara ataması olmaksızın, gerektikçe NIC’ten alınmasına karar verilmiştir.

Bu konu gelecekte yeniden gözden geçirilebilir. Posta sürecinde NIC’in bir darboğaz haline gelmesini önlemek için yerel atama tercih edilebilir.

Numaralar site adı, tarih ve saat gibi bazı bilgileri içerdiği takdirde, yerel numara atamasının belirsiz olmayacağına dikkat çekilmiştir.

Bir başka sorun da şudur: kayda alınmış belge nerededir?

Başlangıçta belge NIC’te olmalıdır, ancak nihai olarak, kayda alınmış tüm belgelerin dizinlenmesi ve kataloglanması için merkezi bir mekanizma olduğu sürece, Ağ üzerindeki herhangi bir yerde olabilir.

Bu durumda, kayda alınmış belgeye giden yol adı dosya adı ve site adını içerecektir.

TYPE

TYPE alt komutu, büyük posta dosyalarının sorunları ve bu dosyaların işlenmesi ve depolanmasının maliyetini kimin karşılayacağı sorusu üzerine yapılan bir tartışmanın sonucudur.

Alınan temel kararlar şunlardır:

Gelen postanın nerede saklanacağı konusunda alıcı ana bilgisayarın bilinçli bir karar verebilmesini sağlayacak bilgiler TYPE komutu aracılığıyla iletilir.

Alıcı ana bilgisayar, aşağıdaki hizmetlerden birini veya her ikisini sağlama konusunda yerel bir seçeneğe sahip olacaktır:

TEXT / FILE / CITATION

TEXT

Bu alan, posta iletisinin metni içindir.

FILE

Bu alanın amacı bana net değildir. Göndericinin alıcının okumasını istediği dosyaya makine tarafından okunabilir bir işaretçi mi içerir?

CITATION

Citation, göndericinin alıcının okumasını istediği dosyaya kişi tarafından okunabilir bir işaretçidir.

Ağ üzerinden tüm iletilerin veya dosyaların gönderilmesine bir alternatif, CITATION mekanizmasını kullanmaktır. Bununla, gönderici kısa bir ileti (citation) gönderir ve özünde "lütfen Y sitesindeki X dosyasını okuyun" der.

Bu alternatif özellikle şu durumlar için yararlı olacaktır:

Ancak, bu alternatifin kullanımını zorunlu kılacak herhangi bir yöntem tartışılmamıştır. Alıcıların kendileri için tatmin edici bir düzen geliştirmesi gerekecektir.

Diğer Genel Tartışmalar

Bob Kahn aşağıdaki soruyu gündeme getirmiştir (parafraz ediyorum):

Bir posta sisteminin tasarımı, bu alternatiflerin dışlanması nicel olarak savunulamadıkça, alternatif veri kaynaklarını ve alternatif çalışma kiplerini içerecek şekilde yapılandırılamaz mı?

Bu sorunun belirli yönleri şunlardır:

  1. Posta sistemine farklı veri kaynaklarının kabul edilmesinin istenirliği ve zorluğu nedir?

Tartışma Soruları

İzin verilen veri kaynaklarını yasaklananlardan ayıran "sınırlar" nelerdir?

Ertelenmiş posta ile gerçek zamanlı posta arasındaki nicel ayrım nedir?

Ortaya koyacağımız tasarım, aşağıdaki gibi şeylere izin verecek mi:

  1. Uyguladığımız ilkel öğeler her ne olursa olsun, Tenex "linking" gibi şeyleri dışlamayacak şekilde tasarlanamaz mı?

    Bu, iki yönlü veri iletişim yollarını gerektirir.

    Veri akışı için bir "sink"in nasıl belirtileceği ve dikkatinin nasıl çekileceği tanımlanmalıdır.

    Örneğin, süreçler arası iletişim ve Tenex türü "linking" için.

Genel Tepki

Bu tartışmaya verilen genel tepki, bakış açısı kazandırıcı nitelikteydi:

"Noktadan noktaya iletişim" olarak değerlendirilebilecek şeyler bütününde, posta kutusu türü iletişim en genel tür değildir.

AKB, çeşitli iletişim problemi türlerini sıralamıştır:

Tasarım Hususları

Posta kutusu türü bir sistem için yapılacak bir tasarımın, örneğin bilgisayar telekonferansı gibi bir sistemin sorunlarını kapsaması gerekmeyecektir; çünkü böyle bir sistem, posta kutusu sisteminin öznitelikleri olmayan (gerçek zamanlılık, video, çok büyük hacimde veri aktarımı gibi) özniteliklere sahiptir.

Katılımcılar

Ağ Postası Toplantısı — 23/2/73, SRI-ARC

Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere Joseph Marshall tarafından 9/97 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.