RFC 757

ARPAnet Mesaj Sistemleri İçin İsimlendirme, Adresleme ve Teslim Sorununa Önerilen Bir Çözüm

Debra P. Deutsch
10 Eylül 1979

Bolt Beranek and Newman
50 Moulton Street
Cambridge, Massachusetts 02138
(617) 491-1850

Önsöz

Birçok RFC'nin aksine, bu belge yakında uygulanacak bir protokolün teknik tanımı değildir. Bunun yerine bu belge, içinde yer alan kavramlar ve öneriler hakkında gerçek bir yorum çağrısıdır ve içeriğinin ve ortaya çıkaracağı tartışmaların, bilgisayar tabanlı mesaj oluşturma ve teslim sistemlerinin bir sonraki neslinin tasarımına katkı sağlaması umuduyla yazılmıştır.

Bu belgenin biçimine ve içeriğine birçok kişi katkıda bulunmuştur. Özellikle genel ve teknik tavsiyeleri ile teşviki için Jerry Burchfiel'e, TIP Login veritabanı ve netmail veritabanı tasarımı konusundaki bilgeliği için Bob Thomas'a, şeytanın avukatlığını üstlendiği için Ted Myer'a ve mükemmel editoryal desteği için Charlotte Mooers'a teşekkür etmek isterim.

Debbie Deutsch

1. Giriş

Mevcut ARPAnet mesaj işleme şeması, oldukça gayriresmî ve merkezi olmayan başlangıçlardan evrimleşmiştir. İlk geliştiriciler, ilk sistemlerini uygulamak için önceden var olan araçlardan — TECO, FTP — yararlandılar. Daha sonra, zaten kullanımda olan kuralları kodlamak amacıyla protokoller geliştirildi. Bu kurallar şaşırtıcı derecede geniş çeşitlilikte ve miktarda hizmeti destekleyebilmiş olsa da, bazı eksiklikler barındırmaktadır.

Zorluklardan biri isimlendirme/adresleme problemidir; bu problem hem alıcıyı tanımlama hem de mesaj için doğru teslim noktasını belirtme gereksinimiyle ilgilidir. Mevcut paradigma, alıcının adı ile alıcının adresi (yani ağ üzerindeki teslim noktası) arasında keskin bir ayrım bulunmaması nedeniyle yetersizdir.

İsimlendirme/adresleme şeması kullanıcıların mesajlarını insan isimlerini kullanarak adreslemesine izin vermez; bunun yerine onları insan tanımlamasından çok makine tarafından ayrıştırılmaya uygun olacak şekilde tasarlanmış tanımlamalar kullanmaya zorlar.

Sınırlamaların bir başka kaynağı ise teslim sistemidir; bu sistem aslında File Transfer Protocol'ün basit bir uzantısıdır. Teslim sistemi işleyiş bakımından oldukça sınırlıdır ve yalnızca hedef ana bilgisayardaki tek bir kullanıcıya tek bir mesajın aktarılmasını içeren basit işlemleri ele alır. Mesajları paket halinde gönderebilme ve yabancı ana bilgisayarda mesajların çoğaltılarak dağıtılması (fan-out) yeteneği sistemin verimliliğini ve kullanışlılığını artıracaktır.

Teslim sisteminin ek bir dezavantajı da kısmen adresleme şemasından kaynaklanır. Adres değişikliği veya hatalı adres genellikle teslim sisteminin mesajı yanlış işlemesine neden olur. Bazı ana bilgisayarlar bir tür mail forwarding database (MFDB) desteklese de, bu çözüm en iyi durumda bile tüm ağ için güvenilir hizmet sağlama açısından yetersiz ve düzensizdir. Aynı kullanıcı adı farklı ana bilgisayarlarda farklı kişilere ait olabileceğinden, mesajlar yanlış adreslendiğinde ortaya çıkabilecek belirsizlikler en iyi MFDB'lerin bile her zaman görevini yerine getirebilmesini engeller.

Bu öneri, alıcının kimliği ile adresinin iki ayrı unsur olarak ele alındığı bir sistemi öngörmektedir. Bir ağ veritabanı, tüm alıcılar için doğru adres bilgilerini sağlayan bir dizin hizmetini destekler. Ayrıca bu şema, istenirse posta tesliminin yalnızca ağın yetkili kullanıcılarıyla sınırlandırılmasına da olanak tanır.

2. İsimler ve Adresler

Günümüz ARPAnet isimlendirme ve adresleme şeması (RFC 733[3]'te belirtildiği gibi) bir kullanıcının¹ kimliği ile adresi arasında ayrım yapmaz. Her ikisi de aynı şekilde ifade edilir: USERNAME@HOST. Bu ifade her zaman o kullanıcı için benzersiz bir tanımlayıcı sağlamalı olsa da, pratikte yetersiz olduğu görülmüştür. Kullanıcılar, kurum değişikliği veya basitçe farklı bir ana bilgisayar kullanmaya başlamaları nedeniyle posta kutularının konumunu değiştirdiklerinde, adları da değişmiş olur. Eğer eski ana bilgisayar bir MFDB kullanıyorsa sorun çok büyük değildir. Posta yalnızca yeni adrese yönlendirilir ve biraz gecikmeyle teslim edilir. MFDB'ye güvenemeyen daha az şanslı kullanıcılar ise tüm yazışma yaptıkları kişilere adres/ad değişikliğini bildirmek zorundadır. Eski adrese gönderilen tüm posta teslim edilemez hale gelir. (İsimlendirme, adresleme ve yönlendirme arasındaki farkların mükemmel bir tartışması John Shoch'un bir makalesinde bulunabilir [1].)

Mesajların adres alanlarında "gerçek" isimlerin kullanılma isteği de mevcut sistem tarafından engellenmektedir. Mesaj başlıklarında² insanlarla uyumlu bilgi ile makine tarafından yorumlanabilir bilgi arasında ayrım yapmaya yönelik karmaşık bir sistem geliştirilmiştir. En son gelişmeler, birçok kullanıcının gerçek insan adının görünmesini tercih edeceğini göstermektedir; makine tarafından yorumlanabilir bilgiler yazarın çalışma ve düşünme alanına fazla müdahale etmemelidir.

Burada önerilen çözüm, alıcının adlandırılma veya tanımlanma biçimi ile konumunun belirtilme biçimi arasında tam bir ayrım yapılmasını gerektirir. ARPAnet düzenlenmiş bir ortam olduğundan, ağ postasının her yetkili alıcısına benzersiz (ve mutlaka insan tarafından okunabilir olmak zorunda olmayan) bir kimlik (ID) atanabilir. Bu kimlik, kullanıcının ağdaki tüm yaşamı boyunca, adres veya kurum değişiklikleri olsa bile aynı kalacaktır.

Bir ağ veritabanı (TIP login desteği için önerilen veritabanından türetilebilecek bir yapı) her bir ID'yi, o ID'ye ait postanın teslim edilebileceği bir veya daha fazla adresle ilişkilendirir. Bir ID ile birden fazla adres ilişkilendirilmişse, bu teslim noktaları arasında sıralı bir tercih olduğunu gösterir. Teslim sistemi önce ilk adrese teslim etmeye çalışır; başarısız olursa ikinciyi dener ve bu şekilde devam eder³. Çoğu ID'nin muhtemelen yalnızca bir adresi olacaktır. Ayrıca her ID ile ilişkilendirilen bazı bilgiler de bulunur: isim, posta adresi, kurum bilgisi, telefon numarası vb.

Yazanın muhatabını belirtmek için garip bir karakter dizisi yazmak zorunda kalması yerine, yalnızca alıcının benzersiz kimliğinin belirlenmesine yetecek kadar bilgi sağlaması yeterli olacaktır. Bu bilgi alıcının adı veya veritabanında bulunan başka herhangi bir bilgi olabilir.

Bu verilere erişim aynı zamanda yazarı alıcının konumunu bilme zorunluluğundan da kurtarır. Benzersiz ID bilindiğinde, teslim için doğru konum yalnızca bir sorgulama uzaklığındadır.

2.1 Dağıtılmış Veritabanı Yaklaşımı

Ağ veritabanının yalnızca tek bir örneği olsaydı büyük bir yoğunluk problemi oluşacağı açıktır. Tüm mesaj trafiği bu tek veritabanını sorgulamak zorunda kalırdı. Bu durum hem güvenilirlik hem de hız açısından son derece istenmeyen bir durumdur. Aynı şekilde her ana bilgisayarın tüm ağ veritabanının eksiksiz yerel bir kopyasını tutmasını zorunlu kılmak da ana bilgisayarlar için gereksiz ve istenmeyen bir yük olacaktır.

Daha iyi bir yaklaşım, yerel teslim sistemine belirli bir gelişmişlik kazandırmak ve dağıtılmış bir ağ veritabanının içeriğine dayanan yerel mini veritabanları kullanmaktır. (Bu veritabanı yedekli ve/veya bölümlenmiş olabilir, ancak muhtemelen yerel ana bilgisayarda bulunmaz.) Bir yerel ana bilgisayar ağ veritabanına bir ID hakkında sorgu gönderdiğinde (veya daha maliyetli bir işlem olarak isim vb. yeterli tanımlayıcı bilgi verildiğinde bir ID talep ettiğinde) veritabanından o ID hakkında sahip olduğu tüm bilgileri döndürmesi istenebilir. Bu noktada yerel ana bilgisayar bu bilgilerin tamamını veya bir kısmını kendi tuttuğu yerel veritabanına kaydedebilir. Bir isim veya adres arandığında her zaman önce bu veritabanına başvurur; yerel bir kayıt bulunamazsa ağ veritabanına başvurur. Yerel mesaj işleme programlarının istenen gelişmişlik düzeyine bağlı olarak, örneğin takma adlar gibi ek bilgiler de bu veritabanına eklenebilir.

Bu veritabanı bir ana bilgisayar kümesi tarafından paylaşılabilir (BBN veya ISI'de olduğu gibi) ya da yalnızca tek bir ana bilgisayar tarafından kullanılabilir. Az miktarda mesaj trafiği üreten ana bilgisayarlar tamamen ağ veritabanına güvenebilir.

Yerel veritabanlarının yapısı ve bakımı tamamen yerel ana bilgisayarlara bırakılmıştır. Adresleri saklayabilirler veya saklamayabilirler. Bunları zaman zaman temizlemek veya büyümelerine izin vermek tercih edilebilir. Yerel veritabanları, bireysel kullanıcıların veya grupların sahip olduğu daha küçük ve daha özel veritabanlarına bağlanabilir. Bu bireysel veritabanları, kullanıcıların kişiler hakkında özel notlar tutabileceği adres defterlerinin karşılığıdır: ilgi alanları, en son ne zaman görüldüğü, tanıdıklarının isimleri vb. Bu veritabanlarının varlığı ve kapsamı bu şema tarafından zorunlu tutulmaz, ancak buna olanak tanır.

Aynı bireysel veritabanları, kullanıcı tarafından sağlanan girdiden alıcının ID'sini belirlemek için mesaj oluşturma programları tarafından da kullanılabilir. Örneğin bir kullanıcı Nick adlı birine mesaj göndermek isteyebilir. Mesaj oluşturma programı "Nick" adını bir ID ile ilişkilendirebilir ve bu ID'yi teslim sistemine ileterek adres veya resmi ID konusunu tamamen kullanıcının dünyasından kaldırabilir.

2.2 Teslim

Teslim işlemi üç bölümden oluşur:

Mesajın gönderilmesi gereken adresin belirlenmesi
Mesajın gönderilmesi
Yabancı ana bilgisayar tarafından işlenmesi

İlk adım genellikle alıcının ID'si verildiğinde, mesaj teslimi için doğru adres(ler)i yerel veya ağ veritabanında aramayı içerir. Mesaj teslim için gönderildiğinde ID henüz bilinmiyorsa, bu ID'yi belirlemek için gerekli olan işlemler (örneğin yerel veya ağ veritabanına yapılan bir çağrı) da bu adımın bir parçası olarak gerçekleştirilir.

İkinci adım bugün gerçekleşen işlemlerden çok farklı değildir. Yerel ana bilgisayar yabancı ana bilgisayarla bir bağlantı kurar. Ardından bir veya daha fazla kişiye bir veya daha fazla mesaj gönderebilir. Seçenekler şunlardır:

Toplu posta: Birden fazla alıcı aynı mesajı alır.
Paketlenmiş posta: Birden fazla mesaj aynı alıcıya gönderilir.
Yukarıdakilerin birleşimi
Tek alıcıya tek mesaj.

Yabancı ana bilgisayar her ID için posta kabul edebilmelidir.

Yabancı ana bilgisayarın belirli bir ID için postayı reddetmesi genellikle göndericinin yerel veritabanı ile ağ veritabanı arasında bir tutarsızlık olduğunu gösterir. Bu durumda yerel ana bilgisayar yerel veritabanını ağ veritabanından günceller ve "yeni" ana bilgisayarda teslimi yeniden dener. (Bu işlem posta yönlendirmedir.) Ağ veritabanından alınan bir ana bilgisayarın yanlış olduğu anlaşılırsa, ağ veritabanında bir sorun vardır ve ilgili yetkililere bildirilir. Böylece adres değişiklikleri yalnızca eski bilgiler referans alındığında ağ veritabanından dışarı doğru yayılır. Bu da yerel veritabanı güncelleme probleminin büyüklüğünü azaltır.

Yabancı ana bilgisayar ID(leri) tanıdıktan sonra mesaj(lar) yabancı ana bilgisayara aktarılabilir. Aktarım başarıyla tamamlandığında yerel ana bilgisayarın görevi bitmiş olur.

Üçüncü adım, yabancı ana bilgisayarın mesaj(lar)ı işlemesini gerektirir. Bu, bir posta odasında gerçekleşebilecek işlemlere benzer. Yabancı ana bilgisayar aldığı paketlenmiş veya toplu postayı sıralamak zorunda kalabilir. Ayrıca ID sahibinin tercihine bağlı olarak iç veya dış fan-out işlevleri veya başka özel işlevler gerçekleştirebilir.

Posta odalarında gerçekleştirilebilecek olası işlevlerin uygulanması ve tasarımı bu teslim şeması tarafından ne zorunlu tutulur ne de sınırlandırılır. Bunların sayısı burada küçük bir kısmını bile açıklamaya izin vermeyecek kadar fazla olduğundan yalnızca birkaç örnek verilecektir.

Fan-out işlevleri, mesajların birden fazla dosyaya yerleştirilmesini, bir veya daha fazla kullanıcıya kopya gönderilmesini veya mesajların tekrar ağ üzerinde yayınlanmasını içerebilir. (Son durumda yabancı ana bilgisayar bir ID listesini değerlendirebilir; bu, ITS mail repeater'ın belirli posta kutularına adreslenmiş mesajları yayınlama biçimine oldukça benzer.) Özel işlevler otomatik çıktı üretimi veya otomatik yanıt üretimi, çeşitli daemon'lar tarafından işlenme veya ana bilgisayarın kullanıcı topluluğu ve yönetimi tarafından yararlı görülen diğer herhangi bir hizmeti içerebilir. Fan-out işlevlerinin uygulanması yerel ana bilgisayarın sorumluluğundadır; kullanıcı topluluğunun yerel "posta odasından" isteyebileceği diğer ek işlevler de aynı şekilde yerel ana bilgisayarın takdirindedir. Hangi hizmetler mevcut olursa olsun, posta odası her ID için postayı doğru konuma dağıtır.

2.2.1 Ek Teslim Seçenekleri

Posta odalarının ID yerine bir kullanıcı adını kabul etmesine izin vermek istenebilir. Kullanıcı adı kullanımı, ID kullanımına kıyasla daha az güvenilir bir adresleme yöntemidir.

Bir kullanıcı adı, ağ veritabanından bir ID ve ana bilgisayar elde etmek için yeterince açık olmayabilir.

Notlar

Örneğin RFC 733'te adres alanlarının anlamlarıyla ilgili tartışmaya bakınız; burada To: alanının "mesajın birincil alıcılarının kimliğini içerdiği" belirtilmektedir.
RFC 733'teki "Syntax of General Addressee Items" bölümüne bakınız.
Birden fazla adres aynı zamanda birden fazla teslimin istendiğini göstermek için de kullanılabilir.

Bir alıcının kullanıcı adı zaman zaman değişebileceğinden, gönderici tarafından sağlanan kullanıcı adının yanlış olması veya ana bilgisayarın bunu tanımaması mümkündür.

Bir alıcının ID'si zamanla değişmediği için, kullanıcı adı değişikliklerinin neden olduğu hatalar ID kullanıldığında ortaya çıkamaz. Benzerlikler veya belirsizlikler teslim gerçekleşmeden önce tespit edilebilir ve göndericiden hedeflediği alıcı hakkında ek tanımlayıcı bilgiler istenebilir.
Daha da kötü bir durumda, doğru bir kullanıcı adı bile yanlış bir ana bilgisayarla eşleştirildiğinde veya bir mail forwarding database tarafından işlendiğinde yanlış teslimata yol açabilir.

Benzersiz ID'ler belirsiz olmadığından, böyle bir durumun oluşma olasılığı benzersiz ID kullanımıyla ortadan kaldırılır.

4
Adresleme hatalarının özellikle sinsi bir kaynağı, kullanıcı adlarının oluşturulmasında (insan) isimleri ve baş harflerin tutarsız kullanımıdır. Gönderici, baş harfler ile soyadının bir kombinasyonunu kullanarak veya kullanmayarak alıcısının kullanıcı adını kolayca yanlış tahmin edebilir. (Örneğin BBNA'daki Jim Miller'a mesaj göndermek isteyen bir kullanıcı "Miller@BBNA" adresini kullanırsa mesajı aynı sitedeki Duncan Miller'a başarıyla teslim edilecektir.)

5
Yazar, bir mail forwarding database'in doğru şekilde bir JWalker'a adreslenmiş mesajları başka bir ana bilgisayardaki farklı bir JWalker'a yönlendirdiğini gözlemlemiştir.

2.2.2 Hatalar

Ağ veritabanının hatalı olduğu durum daha önce tartışılmıştır. Böyle bir durumda girdiyi "muhtemelen hatalı" olarak işaretlemek ve hem ağ veritabanını hem de ID sahibini bilgilendirmek mantıklı olabilir. Bu durumda ID sahibine posta teslimi gerçekleşmez, ancak bu çok da kötü değildir; çünkü bir ana bilgisayar bir kullanıcı adını tanımadığında bugün de olan şey budur.

Ek olarak dikkate alınması gereken bir başka hata durumu da ağ veritabanının ağdan kaybolmasıdır; iyi tasarlanmış dağıtılmış bir ağ veritabanı bu olasılığı neredeyse tamamen ortadan kaldıracak kadar dayanıklı olsa da yine de göz önünde bulundurulmalıdır.

Böyle bir arıza meydana gelirse, yerel veritabanları trafiğin büyük bölümünü karşılayabilmelidir. Kaybedilecek olan şeyler, ağ veritabanına yeni ID’ler ekleyebilme yeteneği, bir ID için ana bilgisayarları değiştirebilme yeteneği, yerel veritabanlarını güncelleme yeteneği ve ağ veritabanını sorgulama yeteneğidir. Özünde, bugün bulunduğumuz duruma geri dönülmüş olacaktır.

İyi yönetilen bir ağ veritabanının sık sık yedeklenmesi gerekir. Donanım arızalarının yıkıcı bir zinciri ağ veritabanının bir veya daha fazla ana bilgisayarını ağdan çıkarırsa, veritabanı başka bir yere taşınabilir. Böyle bir değişiklik, postanın üretildiği tüm ana bilgisayarlara bildirim yapılmasını gerektirir. Veritabanını sorgulayan yazılımlar, böyle bir taşınmayı kolaylıkla karşılayabilecek şekilde tasarlanmalıdır.

6
Böyle bir bildirimin muhtemelen basılı posta veya telefon yoluyla yapılması gerekir.

Bu notta TIP Login problemi ve çözümünün bir parçası olarak önerilmiş bir veritabanına çeşitli atıflar yapılmıştır. Bob Thomas, Paul Santos ve Jack Haverty tarafından yazılan bir dizi çalışma belgesi [5], TIP Login’e yönelik bir yaklaşımı açıklamaktadır. Kısaca, yöntem; "login-host" adı verilen yeni bir varlığın bir kullanıcıya belirli bir TIP’e erişim verilip verilmeyeceğine ve kullanıcının veritabanının kendisinde çeşitli değişiklikler yapmasına izin verilip verilmeyeceğine karar verebilmesi için gerekli bilgileri içeren dağıtılmış bir TIP Login veritabanı oluşturmak ve sürdürmektir.

TIP login veritabanı, TIP login’i desteklemek için gerekli olanın ötesinde bilgiler içeren bir "ağ kullanıcı veritabanı"ndan türetilir. Bu kapsamlı veritabanı, TIP Login dışında başka uygulamaları da doğrudan veya ondan türetilmiş veritabanları aracılığıyla desteklemek üzere tasarlanmıştır.

TIP Login veritabanında her kullanıcının oturum açma dizgesi, kullanıcının erişim yetkisine sahip olduğu TIP’lerin listesi, kullanıcının benzersiz ID’si, parolası ve diğer "izinleri" (hangi TIP’lere erişilebileceğine ek olarak) yer alır. Bu izinler, kullanıcının veritabanında kayıt oluşturabileceğini, silebileceğini veya değiştirebileceğini, diğer kullanıcıların rollerini üstlenebileceğini ve bunu ne ölçüde yapabileceğini belirtebilir. Steve Warshall tarafından geliştirilen izin kavramı bir NSW notunda [2] ele alınmıştır.

TIP Login’i desteklemek üzere tasarlanmış aynı kapsamlı veritabanından bir netmail veritabanı türetmek tamamen makul görünmektedir. Benzersiz ID kavramı bu veritabanı tarafından desteklenmektedir. Bir netmail veritabanı için gerekli bilgilerin büyük bir bölümü zaten içinde bulunmaktadır ve onu değiştirmek için gerekli bakım araçları bu amaç için oldukça uygun görünmektedir. İzin kavramı netmail gereksinimlerine de iyi şekilde uyarlanabilir. Ağ postasına özgü izinler, örneğin belirli bir kullanıcıyla ilişkili teslimat ana bilgisayar listesini değiştirme yeteneğini içerebilir.

Kapsamlı ağ veritabanının ve ondan türetilmiş veritabanlarının bakımını sağlayan mekanizmalar, bize netmail veritabanını çok düşük maliyetle sağlar. Bu öneri bu durumdan yararlanmaktadır.

4. RFC 753 ile ilişki

RFC 753 [4], bir ağlar arası mesaj teslim sistemi tanımlar. Çok kısa olarak yaklaşım, her ağ üzerinde bir veya daha fazla "mesaj işleme modülü" (MPM) konumlandırmaktır. Bu MPM’ler mesajları ağ sınırları üzerinden geçirir ve aynı zamanda yerel ağdaki kullanıcılara teslimat yapabilme yeteneğine sahiptir. Belge ayrıca, zarf ve mektup modeline dayanan önerilen bir mesaj biçimini ayrıntılı olarak açıklamaktadır. Teslim sistemi tarafından okunan harici bir "zarf", (okunmadan kalan) mesajın doğru biçimde yönlendirilmesini ve uygun alıcıya teslim edilmesini sağlar. Bir MPM çifti arasında iletilen mesaj grupları bir "posta torbası" içinde birlikte gönderilir.

Bu öneri RFC 753’ten şu açıdan farklıdır: esas olarak tek bir ağ içinde veya TCP gibi ortak bir host-host protokolü kullanan ağların bir birleşimi içinde çalışmak üzere tasarlanmıştır. RFC 753 ağlar arası iletişimin sorunlarını (farklı mesaj biçimleri, karmaşık yönlendirme ve doğru alıcının doğru biçimde tanımlanması) ele alırken, bu not öncelikle tek bir protokol içinde neler yapılabileceğine odaklanır. Bu ikisi birbiriyle uyumsuz değildir. Genel bir ağlar arası protokol farklı ağlardaki farklı host-host protokolleriyle uyumlu olabilecek genel yöntemler sağlamak zorundayken, bu tür bir öneri ARPAnet/PRnet/SATNET vb. gibi belirli bir catenet’in (birbirine bağlanmış ağların) yeteneklerinden, kaynaklarından ve politikalarından yararlanabilir.

4.1 Uyumluluk

RFC 753’te tanımlanan teslim sistemi burada ana hatları verilen sistemle uyumludur. Bunu, MPM tarafından gerçekleştirilen üç temel teslim seçeneğinin her biri için inceleyelim. (Aşağıdaki tartışmada "yerel ağlar", TCP gibi ortak bir host-host protokolü kullanan ağların birleşimini ifade eder. "Yabancı ağ" ise X.25 gibi farklı bir host-host protokolü kullanan bir ağı ifade eder. Bkz. Şekil 4-1.)

4.1.1 Giden mesaj

4.1.1.1 RFC 753

Gönderenin süreci bir mesajı yerel ağın MPM’ine teslim eder. Mesaj yerel ağdaki bir adrese veya yabancı bir ağdaki bir adrese gönderiliyor olabilir. İlk durumda MPM yerel teslim işlevini yerine getirir (bkz. "Gelen mesaj"). İkinci durumda MPM mesajı son kullanıcıya "daha yakın" olan başka bir MPM’e iletir.

      +---------+  +----------+
      |         |  |          |
      | RCC-NET |  | WIDEBAND |
      |         |  |   NET    |                .......
      +---------+  |          |                .     .
              * *  +----------+                . MPM .
+---------+   * *   *  *   .......                |
|         |   +---------+  .     .           +---------+
| BBN-NET |***|         |__. MPM .  .....    |         |
|         |   | ARPANET |  .......  .   .xxxx| TELENET |
+---------+***|         |***********. G .    |         |
              +---------+***        .....    +---------+
              * *    *  *   **                            .......
       +--------+  +-------+ ***.....    +-------------+  .     .
       |        |  |       |    .   .    |             |--. MPM .
       | SATNET |  | PRNET |    . G .oooo| DIAL-UP NET |  .......
       |        |  |       |    .....    |             |
       +--------+  +-------+             +-------------+

   "Yerel Ağlar", TCP tabanlı        |    "Yabancı Ağlar", diğer
 (IP kullanılarak doğrudan adresleme)|     host-host protokolleri

*** = TCP   xxx = X.25   ooo = diğer iletişim protokolü
                        G = ağ geçidi

              Şekil 4-1: İnternet Ortamı

4.1.1.2 Bu öneri

Gönderenin süreci, alıcının benzersiz ID’sine bakarak teslimat için uygun ana bilgisayarı belirler. Mesaj yerel ağ içinse, teslimat bu önerinin önceki bölümlerinde anlatıldığı şekilde gerçekleştirilir. Alıcı yerel değilse, mesaj yabancı teslim için bir MPM’e iletilebilir. (RFC 753 uygulamasını varsaymayan internet teslimine ilişkin bir tartışma bu notun ilerleyen bölümlerinde yer almaktadır.)

MPM’in çalıştığı ortam, yerel ağların yabancı ağlardaki alıcılar hakkında herhangi bir bilgiye sahip olduğunu varsaymaz. Bu nedenle iki olasılık ortaya çıkar:

Alıcının, yerel ağlar tarafından bilinen bir ID’si vardır.

Bu durumda yerel ağlar RFC 753 "adresini" sağlar. Bu işlem yerel ağların MPM’inde veya kullanıcının gönderme ya da posta oluşturma sürecinde gerçekleşebilir.
Alıcı yerel ağlar tarafından bilinmemektedir.

Bu durumda gönderen "posta kutusu" bilgisini kendisi sağlamalıdır; ya açık biçimde ya da yerel ana bilgisayarının veritabanından yardım alarak.

Dolayısıyla, bu notta açıklanan giden posta mekanizması RFC 753 ile uyumludur ve yerel ağlara ait teslimlerin MPM üzerindeki yükünü azaltma avantajını sağlar.

4.1.2 İletim halindeki mesajlar

İki MPM arasındaki trafik bu öneriden etkilenmez.

4.1.3 Gelen posta

Alıcıya yerel olan ağlardaki MPM, netmail veritabanına erişebilecek ve "posta kutularını" "adreslere" dönüştürebilecektir. Alıcının benzersiz ID’sini belirleyebilir (bilinmiyorsa) ve o alıcıya teslim sürecini başlatabilir. Bu noktada RFC 753 ile bu öneri birbirini oldukça iyi tamamlar.

5. Bir ağlar arası mesaj ortamının sonuçları

Yukarıda açıklanan düzen, her kayıtlı posta alıcısına benzersiz bir tanımlayıcı atanabileceği varsayımına dayanır. Bu benzersizliğin oldukça az düzenlenmiş bir ağlar arası ortamda garanti edilip edilemeyeceği ise tartışmalıdır. Teknik olarak mümkündür. Zorluklar daha çok politiktir; çünkü yabancı ağların yöneticilerinin ve kullanıcı topluluklarının iş birliğini sağlamak gerekir. Yine de iş birliğinin sağlandığını varsayalım ve bir internet ortamında neler olabileceğine bakalım.

5.1 Doğum yerleri

Her yerel ağ kümesinin, erişim kolaylığı için kendi veritabanı olacaktır. Ancak her ID’nin her veritabanına kaydedilmesi pratik görünmemektedir. Bu gereksiz olur ve ağ veritabanlarında erişim ile depolama sorunlarına yol açar. Burada "doğum yeri" ya da ID kökeni kavramı yararlı olabilir.

Bir ID kullanıcının şu anda nerede olduğunu belirtmez, ancak onu kimin verdiğine dair bilgi sağlayabilir. Herhangi bir ID için adresi belirleyen basit bir sistem, ID’yi veren ağın verdiği her ID için bir işaretçi tutmasıyla sürdürülebilir. Çift yönlü bir dolaylı yönlendirme, ID yerel ağlarda verilmemiş olsa bile istenen adresi sağlayabilir. Yerel ağlardan gönderilen ve veritabanı tarafından bilinmeyen bir ID içeren bir mesaj, ID’nin doğum yerinin belirlenmesiyle işlenebilir. Doğum yeri veritabanına yapılacak bir sorgu, ID’nin kayıtlı olduğu bir veya daha fazla ağın listesini döndürecektir. Bunlardan herhangi birine yapılacak sorgu gerekli bilgiyi sağlayacaktır. Bunu desteklemek için gereken tek şey, doğum yeri kaydının (yeterince küçük!) tutulması ve belirli bir ağda kayıt işleminin gerçekleşmesinin otomatik olarak o ağın doğum yerine bu kaydı bildirmesini sağlamasıdır. (Benzer şekilde, kayıt silme işlemi de doğum yerine benzer bir bildirim yapılmasına neden olacaktır.)

5.1.1 ID çözümleme

ID yerel ağ tarafından bilinmediğinde ID çözümlemesinin nasıl ele alınacağı konusunda, başarı elde edilene kadar yabancı ağları sorgulamaktan daha basit bir çözüm görünmemektedir.

5.1.2 İnternet ortamındaki ana bilgisayarlar

Basit ana bilgisayar adları yerine internet ana bilgisayar adlarının kullanılması herhangi bir zorluk oluşturmayacaktır.

5.1.3 Yetim kayıtlar

Bir doğum yeri ortadan kalkarsa (genellikle ağı dağıtıldığı için), ikinci bir doğum yerinin ilk doğum yerinin kayıtlarını "evlat edinmesi" gerekir. Bu değişikliğin bildirimi, yeni bir doğum yerinin eklenmesi durumunda uygulanacak yönteme benzer şekilde internet ortamı boyunca yayılabilir.

6. Sonuçlar

ARPAnet mesaj sistemleri son derece başarılı olmuş olsa da sunulan hizmetlerin kalitesi ve miktarı açısından geliştirilebilecek çok alan bulunmaktadır. Mevcut protokoller yeni mesaj sistemlerinin gelişimini sınırlamaktadır. Bu makale, daha fazla hizmet ve daha yüksek güvenilirlik sağlamanın yanı sıra insan odaklı mühendislikle daha iyi tasarlanmış yeni nesil mesaj sistemlerinin oluşturulmasını destekleyecek temel altyapıyı sağlamanın bir yolunu ele almıştır.

Eleştirmenler bu önerinin fazla radikal olduğunu, mevcut uygulamalardan çok büyük bir sapma içerdiğini ileri sürebilirler. Sonuçta bugünün mesaj hizmeti tasarım açısından son derece basittir ve bu nedenle görece az sayıda hata durumuna sahiptir. Kullanılan protokoller, ARPAnet üzerinde uygulanan ilk dosya aktarımı ve mesaj biçimi protokollerinden görece az değişiklikle türemiştir. Bu da onların iyi anlaşılmış olmasını sağlar; insanlar hem eksikliklerini hem de kullanım biçimlerini bilir. Ayrıca bazı kişiler ağ veritabanı gerekliliği konusunda rahat hissetmeyecek, böyle bir düzenin güvenilirliğine güvenmeyebilir ve olası maliyetini sorgulayabilir.

Öte yandan, günümüz uygulamaları içinde kalarak mesaj hizmetlerini daha da geliştirmek için yapılabilecek çok az şey olduğu inkâr edilemez. Metnin yanı sıra faks, ses ve diğer ortamları iletebilecek yeni mesaj sistemleri, mesaj biçimlerini yeniden düşünmemizi ve ASCII metnin özelliklerine dayanan teslim protokollerini terk etmemizi gerektirir. Ağlar arası mesaj tesliminin ortaya çıkışı, mesajları yerel olarak nasıl ele aldığımızı yeniden değerlendirmemize neden olur. Son olarak USERNAME@HOST adlandırma düzeninin yetersiz olduğu kanıtlanmıştır; alıcıların kimliklerinin konumlarından ayrılması ise yerine geçebilecek umut verici bir olasılık gibi görünmektedir.

ARPAnet yakında TIP Login’i desteklemek için dağıtılmış bir veritabanına sahip olacaktır. Aynı zamanda bir netmail veritabanı oluşturmak ve sürdürmek için yalnızca küçük ve kademeli maliyetler gerekecektir. TIP Login’in en azından bir mesaj teslim sisteminin gerektirdiği güvenilirlik düzeyini gerektirdiği ileri sürülebilir. TIP Login veritabanı başarılı olursa, bir netmail veritabanı da çalışabilir.

Yakın gelecekte çoklu ortam mesajlarını, ağlar arası mesaj trafiğini ve benzerlerini mümkün kılmak için yeni bir mesaj biçimi ve teslim protokolleri kümesini uygulamaya koyacağımız açıktır. Yeni mesaj oluşturma ve teslim sistemleri bu özellikleri karşılamak ve açacakları gelişim yollarından yararlanmak üzere geliştirilecektir. Mesajların nasıl adreslendiğini ve teslim edildiğini yeniden değerlendirmek ve yeniden tasarlamak için uygun bir zaman olacaksa, bu zaman tam da şimdi, tamamen yeni bir mesaj oluşturma ve teslim programları uygulama döngüsüne girmek üzere olduğumuz zamandır.

Conclusions

References

REFERENCES

[1] John F. Shoch.
Inter-Network Naming, Addressing, and Routing.
Proceedings, COMPCON içinde. IEEE Computer Society, Sonbahar, 1979.

[2] Stephen Warshall.
On Names and Permissions.
Mass. Computer Associates. 1979.

[3] David H. Crocker, John J. Vittal, Kenneth T. Pogran, D. Austin Henderson, Jr.
STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES.
RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc, Massachussets Institute of Technology, Bolt Beranek and Newman Inc., Kasım, 1977.

[4] Jonathan B. Postel.
INTERNET MESSAGE PROTOCOL.
RFC 753, Information Sciences Institute, Mart, 1979.

[5] Robert H. Thomas, Paul J. Santos, and John F. Haverty.
TIP Login Notes.
Bolt Beranek and Newman. 1979.

İçindekiler

Giriş
İsimler ve Adresler
TIP Login veritabanı ile ilişki
RFC 753 ile ilişki

4.1 Uyumluluk
4.1.1 Giden mesaj
4.1.1.1 RFC 753
4.1.1.2 Bu öneri
4.1.2 İletim halindeki mesajlar
4.1.3 Gelen posta
Bir ağlar arası mesaj ortamının sonuçları

5.1 Doğum yerleri
    5.1.1 ID çözümleme
    5.1.2 İnternet ortamındaki ana bilgisayarlar
    5.1.3 Yetim kayıtlar
Sonuçlar

Şekil Listesi

Şekil 4-1: İnternet Ortamı