Ana Bilgisayar Adları Çevrimiçi

Network Working Group
Request for Comments: 606
L. Peter Deutsch
PARC-MAXC
Aralık 1973

Artık nihayet resmi bir ana bilgisayar adları listesine sahip olduğumuza göre, ağ üzerindeki her sitenin kendi işletim sistemi veya kullanıcı programları için farklı ve genellikle güncel olmayan bir ana bilgisayar listesi tutmak zorunda kaldığı bu saçma duruma bir son vermenin zamanı gelmiş görünüyor.

Örneğin, erişimim olan TENEX sitelerinin her birinde (SRI-ARC, BBN-TENEX, USC-ISI ve PARC-MAXC) ana bilgisayar adları ile ana bilgisayar adresleri arasında biraz farklı bir eşleme vardır: hiçbiri tam değildir ve her birinin resmi listeden bir şekilde farklı olduğuna inanıyorum.

Resmi listenin tutulmasından NIC sorumlu olduğuna göre, adları ve ana bilgisayar adreslerini (ve birazdan önereceğim bazı diğer bilgileri) kolayca makine tarafından okunabilir bir biçimde listeleyen, herkes tarafından erişilebilir bir çevrimiçi dosyayı da onların sürdürmesi uygun görünmektedir.

Bu, bana göre, bu bilgilerin yalnızca NLS yapılandırılmış bir dosya biçiminde sağlanmasını devre dışı bırakır; çünkü ağ üzerinden bu tür dosyalara erişim imkânı yoktur ve ayrıca birçok site, böyle bir imkân olsa bile, kendini bu yapıya uyarlamak istemeyecektir.

Aklımdaki dosya, insanlardan ziyade programların ihtiyaç duyduğu bilgilere esas olarak ayrılmış olacaktır; çünkü programlar bilgilerini sıkıştırılmış ve kolay ayrıştırılabilir biçimde isterken, insanlar daha ayrıntılı anlatımı ve gezinme ya da sorgulama için daha gelişmiş olanakları tercih eder. Bu nedenle, böyle bir dosyada aşağıdaki bilgilerin yer almasını öneriyorum:

• Elbette, her ana bilgisayar için resmi ad ve ana bilgisayar adresi. Bu, her girdinin birincil içeriği olacaktır.
• Ana bilgisayar tarafından desteklenen çeşitli protokollerin seçenekleri hakkında bazı bilgiler; buna (FTP için) tercih edilen bayt boyutu ve (TELNET için) tercih edilen dupleks modu dahildir. İlkinin dosya aktarımının verimliliği üzerinde çok büyük bir etkisi olabilir. Yeni TELNET seçeneklerin pazarlığını desteklediğinden, listenin tam veya kesin olması gerekmez.
• Ana bilgisayarın ağla ilişkili işlevi (kullanıcı, sunucu, TIP vb.). Bu, NCP’lerin ana bilgisayarı yoklayıp yoklamamaya karar vermesine yardımcı olabilir ya da istatistiksel amaçlar için yararlı bilgiler sağlayabilir (örneğin, NCP’min TIP’lerle olan trafik ile diğer ana bilgisayarlarla olan trafik hakkında istatistik toplamasını istiyorum).

Dosya tek bir program tarafından merkezi olarak üretilecek, ancak çok çeşitli programlar tarafından geniş biçimde kullanılacak olduğundan, biçiminin, oluşturma kolaylığı pahasına, sorgulama kolaylığı için düzenlenmesi gerektiği sonucu çıkar. Bunu başarmanın makul bir yolunun, mantıksal yapısı bir özellik listesi olan bir ASCII metin dosyası olarak saklamak olduğunu düşünüyorum.

Başka bir deyişle, her girdideki iki temel olgunun (ad ve adres) dışında, bilgiler, özniteliğin biçim, konum vb. ile tanınmasına dayanmak yerine <öznitelik, değer> çiftleri biçiminde ifade edilecektir.

Bu dosyanın tam olarak nasıl biçimlendirildiğinin çok büyük bir önemi olduğuna inanmıyorum; bu yüzden kimsenin itiraz edecek kadar umursamamasını umarak bir öneride bulunacağım. (Bu, ağın tarihinde daha önce hiç işe yaramadı, ama yine de denemeye değer.) Aşağıda dosya için önerilen sözdizimi verilmiştir.

<host-name-file> ::= <entry> | <host-name-file> <entry>

<entry> ::= <data-part> <end-of-line>

Note that this produces a blank line after the <data-part>.

<data-part> ::= <basic-part> | <data-part> <attribute-item>

<basic-part> ::= <host-name> , <host-address> <end-of-line>

<attribute-item> ::= <attribute-name> = <attribute-value> <end-of-line>

Bu, aşağıdaki terimleri tanımsız bırakır:

<end-of-line>: Günümüzde ağ topluluğunda hangi satır sonu göstergesinin tercih edildiğini bilmiyorum. Kişisel olarak satırbaşı karakterini takiben satır besleme karakterini tercih ediyorum. TENEX, tamamen standart dışı ve bu uygulama için uygunsuz olan tek bir sekizlik 37 karakterini kullanma eğilimindedir.

<host-name>: NJN ve JAKE tarafından yazılan son RFC 597’de (NIC 20826) belirtildiği şekliyle resmi bir ana bilgisayar adı. Anladığım kadarıyla bu adlar harfler, rakamlar, tireler ve parantezlerle (ağ adı dâhil) sınırlıdır.

<host-address>: Kendi ağına göreli bir ondalık ana bilgisayar adresi (varsayımım bu yönde). Çoklu ağ adreslemesi hakkında genel bir tartışma yapılmamıştır — gerçi yayımlanmamış bir İnternetlerarası Protokol deneyi yürütülüyor gibi görünmektedir — ve başka bir kural daha tercih edilebilir olabilir.

<attribute-name>: Yalnızca harfler, rakamlar ve tireler içeren rastgele bir ad. BEST-FTP-BYTE-SIZE (?) gibi bazı adlar üzerinde anlaşmamız gerekecek, ancak bunları NIC’in seçmesine razıyım.

<attribute-value>: <end-of-line> içermeyen, yorumu genel olarak özniteliğe bağlı olan rastgele bir dizge. Örneğin, değeri sitenin geleneksel olarak çalıştırdığı sunucuların bir listesi olan SERVERS adlı bir öznitelik olabilir.

Aşağıda, yararlı olacağını düşündüğüm bazı belirli öznitelikler yer almaktadır:

• NICKNAMES — değeri, ana bilgisayar için kabul edilebilir takma adların bir listesidir. Adres-çevirimi sağlayan herhangi bir sistemin, bu adları resmi ana bilgisayar adına alternatif olarak kabul etmesi teşvik edilir (elbette zorunlu değildir).

• FTP-BYTE-SIZES — değeri, FTP sunucusu tarafından desteklenen bayt boyutlarının bir listesidir. İlk bayt boyutu, en az hesaplama yüküne yol açan boyuttur (örneğin PDP-10’lar için 36, 360’lar için 32).

• ECHOING — değeri, ana bilgisayarın terminalin yankı yapmasını bekleyip beklemediğine (Remote) ya da kendi yankılamasını yapmayı bekleyip beklemediğine (Local) bağlı olarak L veya R’dir.

Hiçbir özniteliğin aslında zorunlu olmadığına ve belirli bir öznitelik altındaki değerlerin eksiksiz olmak zorunda olmadığına dikkat edin. Başka bir deyişle, bu listenin, seçenek pazarlığını, kulaktan kulağa aktarılan bilgileri veya bir ana bilgisayarın bir diğerinin özelliklerini keşfetmesini sağlayan herhangi başka bir yolu ikame etmesi değil, yalnızca basit ve tekdüze bir şekilde erişilebilen alternatif bir bilgi kaynağı sağlaması amaçlanmaktadır.

Bu tür önerilerle ilişkili, eskiden beri bilinen bir tuzağın farkındayım: bu öneri, belirli bir soruna yönelik belirli bir çözümü temsil eder ve bu nedenle, daha genel sorunlar için daha genel çözümlerle uyumlu olmayabilir ya da onlar için makul bir temel oluşturmayabilir. Ancak, (1) bu özel sorun, bir yıldan uzun süredir beni ve konuştuğum diğer kişileri rahatsız etmektedir ve bu kadar uzun süre çözümsüz kalmış olması gerçekten saçmadır; (2) kimse daha genel bir sorunu çözmekle özellikle ilgileniyor gibi görünmemektedir.

Datacomputer hariç: LÜTFEN, Datacomputer aracılığıyla aynı işlevi yerine getirmenin kolay bir yolu varsa, birisi bunu belirten bir RFC yazsın.