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

NCP/TCP POSTA HİZMETİ GEÇİŞ STRATEJİSİ ÜZERİNE YORUMLAR

Yazar
Kurum
Tarih
Ekim 1980
Durum
Network Working Group Yorum Talebi
Kanal
mail/

NCP/TCP POSTA HİZMETİ GEÇİŞ STRATEJİSİ ÜZERİNE YORUMLAR

V. Cerf
DARPA
Ekim 1980

GİRİŞ

Bu not, posta hizmeti geçiş planını [20] gözden geçirmekte ve genişletmektedir.

Planın temel amacı, ARPANET'ten Internet Protocol tabanlı çalışmaya geçiş süresi boyunca en yaygın kullanılan ağ hizmetinin (posta) düzenli biçimde desteklenmesini sağlamaktır.

Geçişin hedefi, sonunda internet ortamında ARPANET ortamında mevcut olan hizmete eşdeğer veya ondan daha iyi bir hizmet sunmaktır. Hem internet hem de eski ARPANET tabanlı protokollerin kullanımda olduğu ara dönemde geçişin amacı, kullanıcı üzerindeki etkileri en aza indirmek ve mümkün olduğu ölçüde geçiş sorunlarıyla başa çıkmak için gerekli yazılım geliştirme veya değişiklik miktarını en aza indirmektir.

Okuyucunun hem ARPANET hem de internet protokol hiyerarşileri hakkında bilgi sahibi olduğu varsayılmaktadır [1–17]. İnternet hiyerarşisi birçok farklı paket ağına (örneğin paket uydu, paket radyo, Ethernet, LCS Ring ağı, X.25 genel ağları, ...) bağlanacak şekilde tasarlanmıştır; buna karşılık ARPANET hiyerarşisi ARPANET IMP'leri ile sınırlıdır (NCP'nin üzerindeki katmanlar için bu daha az geçerlidir, ancak NCP'nin kendisi ARPANET hizmetlerine sıkı biçimde bağlıdır).

Geçiş planının amacı, ARPANET ana bilgisayarlarının daha zengin internet dünyasına geçişi sırasında, tamamen ARPANET ortamı ile daha genel internet ortamı arasındaki sınır boyunca ARPANET elektronik posta hizmetlerinin desteklenmesini sağlayacak yöntemleri belirlemektir.

ELEKTRONİK MESAJ HİZMETLERİ

DARPA, otomatik elektronik mesaj işleme sistemleri üzerine yeni bir araştırma aşamasına başlamaktadır. Nihai olarak elektronik mesajların metin, faks, sıkıştırılmış sayısallaştırılmış ses, grafikler ve benzeri çoklu ortamları içermesi amaçlanmaktadır. Bu yeni araştırmada başarı sağlanması, bilgisayar tabanlı hizmetlere yönelik çok kipli kullanıcı arayüzlerinin geliştirilmesinde önemli ilerlemeler gerektirecektir (ses girişi/çıkışı, grafikler, tablet/ışık kalemi, faks girişi/çıkışı, video/bit eşlemli ekranlar, ...).

Aynı zamanda, çoklu ortam çalışmalarının sonuçlarının herhangi bir tek ağa hapsedilmesini önlemek amacıyla internet protokollerine dayalı bir ortama doğru ilerleme sağlanmalıdır. Bu nedenle DARPA, önümüzdeki birkaç yıl içinde mevcut metin tabanlı ARPANET elektronik mesaj sisteminden internet tabanlı, çoklu ortam destekli bir elektronik mesaj sistemine doğru birkaç geçiş gerçekleştirmeyi planlamaktadır.

Bu makale yalnızca NCP tabanlı metin postasından TCP tabanlı çoklu ortam postasına geçişin ilk aşamasını ele almaktadır. Yeni çoklu ortam posta sistemine [7,19] geçiş ileride yer almaktadır, ancak temel kavramlarla ilgili bir miktar deneyim elde edilene kadar ayrıntılı planlama gerektirmez. Bu ilk adım yalnızca TCP tabanlı metin postasına geçişi sağlamaktadır.

ARPANET tabanlı elektronik postadan internet elektronik postasına geçiş için temel kurallar şunlardır:

  1. ARPANET posta kutusu adları doğru şekilde çalışmaya devam etmelidir.
  2. Yanıt oluşturmak ve benzeri işlemler için mesaj başlıklarını ayrıştıran posta düzenleyicilerinde değişiklik gerekmemelidir.
  3. Posta oluşturma programlarının başlık ayrıştırma ve denetim mekanizmalarında değişiklik yapmadan ARPANET dışı posta kutusu tanımlayıcılarının kabul edilmesi.
  4. NCP ve TCP ortamları arasında kullanıcı müdahalesi olmadan mesajların otomatik yönlendirilmesi.
  5. Geçiş süresi boyunca eski tarz posta mekanizmalarının çalışmaya devam etmesi.

ELEKTRONİK MESAJ MEKANİZMALARI

Herhangi bir ilerleme sağlanabilmesi için, giriş olarak bir elektronik metin mesajını kabul eden ve bunun hedefe (veya bir ara yönlendiriciye) ulaştırılmasını sağlayan "mailer" işlevinde oldukça gelişmiş değişikliklerin varsayılması gerekmiştir.

Ayrıca ARPANET üzerinde, NCP (TCP) tabanlı mesaj göndericilerden mesajları kabul edip bunları TCP (NCP) tabanlı mesaj alıcılarına iletmekten sorumlu özel ve iyi bilinen posta yönlendirme ana bilgisayarlarının bulunduğunu varsayıyoruz.

ARPANET'te elektronik mesajlar File Transfer Protocol'ün özel yordamları aracılığıyla taşınır: MAIL ve MLFL. İlk yöntem elektronik mesajları FTP Telnet komut kanalı üzerinden gönderirken, ikincisi bunu gerçek dosya aktarımı yoluyla gerçekleştirir. Her iki durumda da alıcı FTP sunucusunun hedef posta kutusu ile aynı makinede bulunduğu genellikle varsayılır.

Bu nedenle gönderme yordamı alıcıya hedef posta kutusu tanımlayıcısını bildirir, ancak hedef ana bilgisayar (veya ağ) tanımlayıcısını bildirmez. Örneğin USC-ISIF'teki Postel tarafından USC-ISIA'daki Adams'a gönderilen mesajlar ISIA'ya "Adams" göstergesi ile ulaşır ancak "ISIA" bilgisi bulunmaz. Bu durum, NCP tabanlı bir göndericiden TCP tabanlı bir alıcıya geçerken veya tersi durumda olduğu gibi, mesajların daha ileri işleme için bir ara ana bilgisayarda bekletilmesi gerektiğinde bazı sorunlar ortaya çıkarır. Benzer durumlar, mesajların ara noktalarda yeniden biçimlendirilmesini gerektiren uyumlu fakat farklı mesaj sistemleriyle çalışırken de ortaya çıkar.

Aşağıdaki paragraflarda, sistemler arasında mesajların adlandırılması, adreslenmesi ve yönlendirilmesi [18] ile ilgili bir mekanizma önerilmektedir.

Kaynakta, kullanıcının mesaj metnini ("To:" ve "CC:" alanları dahil) geleneksel biçimde hazırladığı varsayılmaktadır [12]. Posta kutusu tanımlayıcıları aşağıdaki biçimi göstermeye devam edecektir:

User@Host

ancak "host" aslında ayrıştırılması gerekmeyen bileşik bir ad olabilir; örneğin:

veya bir kuruluşun adı bile olabilir; örneğin:

Tek kısıtlama, posta kutusu tanımlayıcısındaki "user" veya "host" dizgilerinin içinde "@" karakterinin bulunmamasıdır.

Mesaj oluşturma sırasında, posta kutusu tanımlayıcısının "user" veya "host" bölümleri doğruluk (ya da en azından geçerlilik) açısından doğrulanabilir. "user" dizgisi şu anda izin verildiği gibi parantez içinde bilgiler içerebilir:

RAK(Richard A. Karp)@SU-AI

Oluşturma işleminden sonra mesajlar ya hemen gönderilir ya da daha sonra mailer demonları tarafından gönderilmek üzere "unsent mail" dosyaları olarak bırakılır. Gerçek gönderme süreci, mesajın nereye ve nasıl gönderileceğini belirlemek için "host" dizgisini kullanır.

YENİ POSTA MEKANİZMALARI

Bu noktada geçiş planını desteklemek için ilk kritik yeni gereksinimle karşılaşırız. Mailer içinde veya mailer'ı destekleyen ana bilgisayarda ya da örneğin internet ad sunucusu aracılığıyla mailer tarafından erişilebilen yeni bir tabloya ihtiyaç vardır. Bu tablo "host" dizgisini bir internet hedef adresine (yani 32 bit: 8 bit ağ, 24 bit ana bilgisayar) eşlemeli ve ayrıca hedefin NCP mi yoksa TCP yetenekli mi olduğunu göstermelidir.

Kaynak ve hedef ana bilgisayarların uyumlu bir ana bilgisayar düzeyi protokolü bulunmadığında (örneğin kaynak yalnızca NCP, hedef yalnızca TCP ise) mesaj, bir protokol aracılığıyla kabul edip diğeri aracılığıyla iletebilen bir "forwarder"a gönderilmelidir.

Bu durum yönlendirme yapan ana bilgisayar için bir soruna yol açar çünkü temel FTP posta mekanizması posta kutusu tanımlayıcısının yalnızca "user" bölümünü ("user@host") gönderir; çünkü "host"un hedef olduğu varsayılır. Yönlendirme durumunda ise "host" yönlendirici değildir. "host"un bir yönlendiricinin internet adresine çevrileceği şekilde akıllıca bir düzenleme yapılsa bile iki sorun ortaya çıkar. Birincisi, yönlendirici mesajı nereye ileteceğini belirlemek için "host" bilgisine ihtiyaç duyabilir; ikincisi ise kaynağın bulunduğu ağa bağlı olarak "host" farklı yönlendirici adreslerine çevrilmek zorunda kalabilir. Bu ikinci gözlem, aynı "host" dizgisinin birçok farklı eşlemesini gerektiren bir durum ortaya çıkarır ve bu da farklı posta kaynakları için farklı tablolar gerektirir. Bu durum yönlendirici adres tablolarının bakımını ve dağıtımını oldukça karmaşık hale getirir. Ayrıca "host"u tek bir yönlendiriciye eşleyen tek girişli bir tablo güvenilirliği sınırlayacaktır çünkü belirli bir "host" için yalnızca tek bir yönlendirici hizmet verebilir.

NCP/TCP geçişi için, bazı iyi bilinen ana bilgisayarların NCP/TCP yönlendiricileri olduğunu ilan etmek yeterli olabilir. Her mailer uyumsuz bir hedef keşfettiğinde mesajı erişilebilir olan herhangi bir yönlendiriciye gönderebilir. Bunun yanında mailer yönlendirme yapan ana bilgisayara tam posta kutusu tanımlayıcı bilgisini "user@host" biçiminde sağlamalıdır.

Mevcut mailer'larda posta kutusu tanımlayıcısının yalnızca "user" kısmı gönderildiğinden, tüm mailer'ların bir yönlendiriciye gönderim yaparken "user@host" gönderecek şekilde değiştirilmesi gerekir. Mailer'ların ayrıca "host"u internet adreslerine eşlemek ve NCP veya TCP yetenek bilgilerini yorumlamak için yeni bir tablo arama yöntemini de öğrenmeleri gerekir.

Bu tartışmanın amacı açısından, geçiş süresince birlikte çalışabilir hale getirilmesi gereken üç farklı elektronik posta hizmeti uygulama durumu varsayılmaktadır:

  1. Değiştirilmemiş ESKİ NCP (RFC733) posta
  2. Yeni internet tablolarına sahip NCP posta
  3. Yeni internet tablolarına sahip TCP posta

İkinci durum, ana bilgisayarın yeni bir host-dizgisi-adres tablosunu (NCP/TCP yetenek bitleri dahil) ve yeni mailer–mail server programlarını benimsediğini, ancak eski NCP ana bilgisayar düzeyi protokolünü kullanmaya devam ettiğini ve yalnızca bir yönlendiriciye gönderim yaparken "user@host" gönderecek şekilde değiştirdiğini varsayar. Bu tür ana bilgisayarlarda yalnızca NCP yeteneği gösteren tablo girişleri doğrudan kaynak-hedef posta teslimine yol açar. Hedef yalnızca TCP yetenekliyse kaynak ana bilgisayar başka bir tablodan bir yönlendirici adresi seçer ve mesajı daha ileri işlem için ona gönderir.

Üçüncü durumda kaynak ana bilgisayar tamamen TCP'ye geçmiştir, host-dizgilerini internet adreslerine çevirmek için yeni internet adres tablolarını kullanır ve yeni mailer–mail server'ı kullanır. Yalnızca NCP uyumlu hedeflere NCP/TCP yönlendiricileri aracılığıyla ulaşılır.

Günümüzde posta kutusu girişlerindeki ana bilgisayar adlarının geçerliliğini doğrulamak için ARPANET dizgi-adres tablolarını kullanan posta oluşturma programları (örneğin SNDMSG, MSG, Hermes, MH, ...) bu "eski" tablolar internet ana bilgisayar adlarını da içerecek şekilde güncellendiği sürece kullanılmaya devam edebilir.

Aslında eski tabloların genişletilmesi en zor geçiş durumunu ele almak için gereklidir: ESKİ NCP'den yeni TCP postasına geçiş. Üç tür ana bilgisayar 3'e 3'lük bir posta aktarım durumu matrisi ortaya çıkarır. Bir durum dışında tüm durumlarda posta ya doğrudan ya da açıkça bir yönlendirici aracılığıyla işlenir. Ek açıklama gerektiren tek durum ESKİ NCP'den YENİ TCP'ye geçiştir ve bu durumda "örtük yönlendirici" kullanılır.

ÖRTÜK YÖNLENDİRME VE AÇIK YÖNLENDİRME

Kaynak ana bilgisayar yeni internet tablolarını benimsemişse hedef ana bilgisayarın uyumlu bir posta kabul protokolüne sahip olup olmadığını anlayabilir. Uyumsuzluk, bir ara yönlendirici seçilerek açık biçimde çözülür.

Ancak kaynak ana bilgisayar hâlâ saf NCP tablolarını kullanıyorsa belirli bir hedef ana bilgisayarın yalnızca TCP yetenekli olduğunu anlayamaz. Bu durum için hizmet sağlamak amacıyla geleneksel NCP ana bilgisayar tablosunun internet ana bilgisayar adlarını içerecek şekilde genişletilmesi, ancak bunların örtük posta yönlendiricilerinin adreslerine (yani takma adlara) eşlenmesi önerilmektedir.

NCP ana bilgisayarın hiçbir değişiklik yapmadığı (ana bilgisayar tablosunun genişletilmesi dışında) bir durumu varsaydığımızdan, kaynak ana bilgisayarın "user@host" bilgisini FTP aracılığıyla ara yönlendiriciye gönderemeyeceğini de varsayıyoruz.

Bu durumda ara yönlendirici yalnızca "user" olarak tanımlanan bir mesajı nereye ileteceğini belirleme sorunuyla karşı karşıya kalır. Bu durumda internet üzerindeki yalnızca TCP tabanlı posta kutularının örtük yönlendiricilere kaydedildiğini varsayıyoruz; böylece geleneksel NCP kaynaklarından gelen postalar başarıyla hedefe iletilebilir.

Ters yönde ise kaynak açık yönlendirme kullanabilir çünkü tüm TCP ana bilgisayarlarının yeni internet tablolarını kullandığı varsayılmaktadır.

Örtük yönlendiricide kayıtlı adların kullanılması iki sorunu ortaya çıkarır:

  1. Belirsiz posta kutusu adlarıyla nasıl başa çıkabiliriz? (örneğin USERX@BBN ve USERX@ISI yalnızca "USERX" dizgisi ara yönlendiriciye sunulursa aynı görünür)
  2. Örtük yönlendiricilerdeki kayıtların değişikliklerini nasıl toplayabilir, güncelleyebilir ve dağıtabiliriz?

Birinci durumda sorundan kaçınmak için her yerde belirsizliğe yer bırakmayan posta kutusu adlarının kullanılmasını şart koşmayı öneriyoruz. Bu bazı internet posta kullanıcılarının posta kutusu adlarını değiştirmesini gerektirebilir, ancak bunun nadir olacağını düşünüyoruz.

İkinci sorun, tüm ağ posta kullanıcılarından düzenli olarak bilgi toplanarak ve bu veriler otomatik olarak erişilebilen bir veritabanında kataloglanarak çözülebilir (örneğin mailer programları tarafından).

Olası bir mekanizma, veriyi internet ana bilgisayar ad sunucusuna benzer bir internet posta kutusu ad sunucusu aracılığıyla erişilebilir hale getirmektir [6]. Bu veriler, meşru ARPANET kullanıcılarının ARPANET TIP'lerine daha geniş erişim sağlayabilmesi amacıyla geliştirilmekte olan TIP LOGIN veritabanının doğal bir parçası olarak da toplanabilir.

Her durumda internet posta kullanıcılarının posta kutusu bilgilerini tek bir toplama noktasına sağlamaları gerekir; bu nokta da bilgileri ARPANET üzerindeki tüm örtük yönlendiricilere dağıtır. Böyle yönlendiricilerin yalnızca ARPANET üzerinde gerekli olduğuna dikkat edilmelidir çünkü diğer tüm sistemler TCP tabanı ile başlamaktadır. Ancak kayıt yaptırması gerekenler internet posta kutusu kullanıcılarıdır; çünkü aksi halde NCP üzerinden erişilemeyenler onlardır.

YÖNLENDİRİCİ ÖZELLİKLERİ

Tanımları gereği NCP/TCP yönlendiricileri hem NCP hem de TCP yetenekli olmalıdır. Bu nedenle tüm NCP/TCP yönlendiricileri ARPANET ana bilgisayarları olmalıdır.

Örtük yönlendiriciler geleneksel NCP/FTP postasını [11] kabul etmeli ve doğru hedef ana bilgisayar ile ilişkilendirilebilecek geçerli internet kullanıcı posta kutusu adlarını içeren tablolarla donatılmış olmalıdır. Örtük yönlendiricilerin kendi üzerlerinde posta kutusu bulunan kullanıcılar için normal postayı da kabul edebilmesi amacıyla, yönlendirici gelen postanın yerel bir kullanıcıya ait olup olmadığını önce kontrol etmelidir.

Açık posta yönlendiricileri hem geleneksel NCP-FTP posta komutlarını (yerel kullanıcı postası için) hem de NCP tabanlı ve TCP tabanlı posta sunucu komutlarını kabul edebilmelidir (bu komutların argümanları tam hedef posta kutusu dizgilerini "user@host" içerir).

Olası anormal davranışları önlemek için NCP tabanlı ve TCP tabanlı posta sunucuları hizmeti socket/port 57 (sekizlik 71) üzerinden sunacaktır. İletişim kalıplarının özeti şöyledir:

(a) TCP, iyi bilinen port 57 üzerinden posta gönderir/alır.

(b) Örtük yönlendirici geleneksel NCP/FTP postasını iyi bilinen socket 3 üzerinden alır ve TCP postasını port 57'ye gönderir.

(c) Açık yönlendirici NCP postasını iyi bilinen socket 57 üzerinden alır, ancak NCP postasını NCP/FTP aracılığıyla socket 3 üzerinden gönderir. TCP postası port 57 üzerinden gönderilir/alınır.

KULLANICI ANA BİLGİSAYAR ÖZELLİKLERİ

NCP ana bilgisayarlarının en azından ana bilgisayar adı tablolarını internet ana bilgisayarları için takma adları içerecek şekilde güncellemesi gerekir (yani NCP örtük yönlendirici ana bilgisayar adreslerine eşleme yapılmalıdır).

Bir sonraki en yararlı adım, açık yönlendiricilerden yararlanmak amacıyla NCP ana bilgisayarlarını internet adres tablolarını ve NCP/TCP yetenek bitlerini içerecek şekilde güncellemektir. Bu, posta sunucusunun uygulanmasını ve postayı açık yönlendiricilere göndermek için mailer programlarının değiştirilmesini gerektirir. Ayrıca açık yönlendirici adres tablolarının eklenmesini de gerektirir.

Son olarak, bir ana makine internet ad tablolarını ve açık yönlendirici adres tablolarını da içerecek şekilde tam TCP posta hizmetlerini uygulayabilir.

SARKAN ORTAÇLAR

  1. Yönlendiricilerin kullanımıyla ilgili sorunların makul biçimde raporlanmasını güvence altına almak için hata mesajı işleme mekanizmasının ayrıntılı biçimde ele alınması gerekir.
  2. Yönlendirme yapan ana makinelerin belirlenmesi.
  3. Örtük yönlendiriciler için internet posta kutusu adlarının toplanması.
  4. İnternet ad tablosu ve NCP/TCP yetenek bilgisi için biçim ve dağıtım.
  5. NCP, TCP veya RFC733 ile uyumlu olmayan posta sistemleriyle başa çıkma (ör., Telemail, On-Tyme, Phonenet, TWX, TELEX, ...).

PLANLAR

Bu geçişi teşvik etmek amacıyla aşağıdaki takvim önerilmektedir:

  1. 1 Ocak 1981 — çeşitli hizmet ana makinelerinde (ör., TOPS-20) örtük ve açık NCP/TCP yönlendiricileri kullanılabilir hale getirilecek.
  2. 1 Ocak 1982 — örtük NCP/TCP yönlendirici hizmeti kaldırılacak; açık yönlendirme hizmeti devam edecek.
  3. 1 Ocak 1983 — açık NCP/TCP yönlendirme hizmeti sonlandırılacak, TCP'ye geçiş tamamlanacak.

TEŞEKKÜRLER

Birçok kişi bu katkıyı gözden geçirmiş ve yorumlarda bulunmuştur. Özellikle J. Pickens, J. Postel, J. Haverty, D. Farber ve D. Adams tarafından yapılan yorumlar için içten teşekkür edilir.

KAYNAKLAR

  1. DoD Standard Internet Protocol, IEN 128, RFC 760, NTIS ADA 079730, Oca 1980.
  2. DoD Standard Transmission Control Protocol, IEN 129, RFC 761, NTIS ADA 082609, Oca 1980.
  3. Postel, J., Telnet Protocol Specification, IEN 148, RFC 764, Haz 1980.
  4. Postel, J., File Transfer Protocol, IEN 149, RFC 765, Haz 1980.
  5. Postel, J., User Datagram Protocol, RFC 768, Ağu 1980.
  6. Postel, J., Internet Name Server, IEN 116, Ağu 1979.
  7. Postel, J., Internet Message Protocol, IEN 113, RFC 759, Ağu 1980.
  8. Postel, Sunshine, Cohen, The ARPA Internet Protocol, hazırlık aşamasında.
  9. NCP: ARPANET Protocol Handbook, NIC 7104, Oca 1978.
  10. Telnet: ARPANET Protocol Handbook, NIC 7104, Oca 1978.
  11. FTP: ARPANET Protocol Handbook, NIC 7104, Oca 1978.
  12. D. Crocker, J. Vittal, K. Pogran, A. Henderson, Standard for the Format of ARPA Network Text Messages, RFC 733, Kas 1977.
  13. Crocker, ve diğerleri, Function-Oriented Protocols for the ARPA Computer Network, SJCC, May 1972.
  14. Carr, Crocker, Cerf, Host-Host Communication Protocol in the ARPA Network, SJCC, May 1970.
  15. Cerf, V., The Catenet Model for Internetworking, IEN 48, DARPA/IPTO, Tem 1978.
  16. BBN 1822: Specifications for the Interconnection of a Host and an IMP, BBN Rapor No. 1822.
  17. Heart, ve diğerleri, The Interface Message Processor for the ARPA Computer Network, SJCC, May 1970.
  18. Shoch, J., Inter-Network Naming, Addressing, and Routing, COMPCOM, Sonbahar 1978.
  19. Postel, J., A Structured Format for Transmission of Multi-Media Documents, RFC 767, Ağu 1980.
  20. Cerf, V. ve J. Postel, Mail Transition Plan, RFC 771, Eyl 1980.
  21. Sluizer, S. ve J. Postel, Mail Transfer Protocol, RFC 772, Eyl 1980.