Genel Bakış
Konu: Ağ iletişimi ve kaynak erişimini standartlaştırmak için önerilen kullanıcı düzeyinde kurallar.
Problem: Ağ kullanımı genişledikçe, kullanıcılar şunlar için net kurallara ihtiyaç duydular:
- Uzak kullanıcılara nasıl hitap edileceği
- Mesajların nasıl biçimlendirileceği
- Ağ genelinde kaynakların nasıl adlandırılacağı
- Hataların ve onayların nasıl ele alınacağı
Öneri: Tüm ARPANET host'larında tek tip olacak ağ değişimi için kullanıcı kuralları oluşturma.
İçindekiler
- Giriş
- Kullanıcı Etkileşim Modeli
- Ağ Adresleme Kuralları
- Mesaj Format Standartları
- Kaynak Adlandırma
- Hata İşleme
- Önerilen Standartlar
- Önem
Giriş
Mevcut Durum
Ağ iletişimi kurmaya çalışan kullanıcılar kafa karışıklığı yaşadılar:
- Standart posta kutusu formatı yok: Her host'un farklı adresleme sistemi var
- Standart mesaj yapısı yok: Farklı sitelerde farklı protokoller
- Standart dosya adlandırma yok: Kaynakları bulmak zor
- Hata kuralları yok: Hatalar farklı yanıtlar üretiyor
Tek Tip Kurallar için Vizyon
RFC 8, şunları sağlayacak kullanıcı düzeyinde kurallar oluşturmayı önermektedir:
- Tüm ağ host'larında iletişimi mümkün kılma
- Tutarlı kullanıcı deneyimi sağlama
- Yeni ağ kullanıcıları için öğrenme eğrisini azaltma
- Üst düzey protokoller için temel oluşturma
Kullanıcı Etkileşim Modeli
Temel Kullanıcı İşlemleri
İşlem 1: Mesaj Gönderme
Mevcut Süreç (standart dışı):
Kullanıcı A (UCLA) Kullanıcı B'ye (SRI) mesaj göndermek istiyor
1. Mesajı yerel olarak oluştur
2. Kullanıcı B'nin host konumunu belirle (telefon veya not)
3. Uzaktan göndermek için host'a özgü komutları kullan
4. Mesajın ulaşmasını umut et; teslim onayı yok
5. Farklı host'larda farklı sözdizimi
Önerilen Standart Süreç:
SEND address: SRI:UserB
Recipient: Steve Crocker
Subject: Toplantı Notları
[mesaj metni]
END
Sistem otomatik olarak:
1. Mesajı standart başlıklarla biçimlendirir
2. Doğru hedefe yönlendirir
3. Teslim edildiğinde onay sağlar
4. Gönderilen mesajların kaydını tutar
İşlem 2: Posta Okuma
Mevcut Durum:
SRI'da: MAIL
UCLA'da: MESSAGES
UCSB'de: EMAIL RETRIEVE
Utah'ta: CHECK-INBOX
(Hepsi tamamen farklı!)
Önerilen Standart:
READ MAIL
Gönderen, tarih, konu dahil standart formatla mesajları görüntüle
İşlem 3: Uzak Dosyalara Erişim
Mevcut Durum:
Uzak host'lardaki dosyalara nasıl erişileceği belirsiz
Farklı siteler farklı yaklaşımlar kullanıyor
Standart dosya transfer mekanizması yok
Önerilen Standart:
OPEN-REMOTE-FILE host:pathname [mod]
Ağ Adresleme Kuralları
Kullanıcı Adres Formatı
Önerilen Standart Format
[host]:[kullanıcı][@kimlik_bilgileri]
Bileşenler:
| Bileşen | Format | Örnek |
|---|---|---|
| host | Host adı | UCLA, SRI, UCSB, Utah |
| kullanıcı | Yerel kullanıcı kimliği | crocker, duvall, kahn |
| kimlik_bilgileri | İsteğe bağlı kimlik doğrulama | [isteğe bağlı] |
Adres Örnekleri
UCLA:crocker (UCLA'daki Crocker)
SRI:duvall (SRI'daki Duvall)
UCSB:allen@projects (UCSB'deki Allen, proje bağlamı)
Utah:beard (Utah'taki Beard)
Host Adı Kuralları
Standartlaştırılmış Host Adları (sayısal adreslerin yerine):
| Sayısal | Önerilen | Site |
|---|---|---|
| 140 | UCLA | University of California, Los Angeles |
| 65 | SRI | Stanford Research Institute |
| 139 | UCSB | University of California, Santa Barbara |
| 10 | Utah | University of Utah |
| 9 | BBN | Bolt, Beranek and Newman |
Avantajlar:
- Sayısal adreslere karşı akılda kalıcı isimler
- Yazması ve hatırlaması daha kolay
- Gelecekteki DNS benzeri sistem için temel
- Kullanıcı dostu adlandırma
Mesaj Format Standartları
Standart Mesaj Yapısı
Başlık Formatı
TO: alıcı-adresi
FROM: gönderen-adresi
DATE: tarih-zaman_damgası
SUBJECT: mesaj-konusu
PRIORITY: normal|yüksek|düşük
ACKNOWLEDGE: evet|hayır
---
[mesaj gövdesi]
Örnek Uyumlu Mesaj
TO: SRI:duvall
FROM: UCLA:crocker
DATE: 1969-08-24 14:30:00
SUBJECT: RFC 8 Tartışması
ACKNOWLEDGE: evet
---
Bill,
Ağ için standart bir mesaj formatı öneriyorum.
Lütfen RFC 8'i incele ve görüş bildir.
Saygılarımla,
Steve
Mesaj Gövdesi Kuralları
Gereksinimler:
- Metin Kodlaması: RFC 20'ye göre ASCII
- Satır Uzunluğu: Maksimum 80 karakter
- Satır Sonlandırma: CRLF (ASCII standardına göre)
- İmza Bloğu: Sonunda önerilir
- Özel Karakterler: Yalnızca standart ASCII kullan
Çok Parçalı Mesajlar
Daha büyük iletişimler için:
---MESAJ BÖLÜM 1 BAŞLANGIÇ---
[mesaj içeriği]
---MESAJ BÖLÜM 1 BİTİŞ---
---MESAJ BÖLÜM 2 BAŞLANGIÇ---
[devam eden içerik]
---MESAJ BÖLÜM 2 BİTİŞ---
---MESAJ BÖLÜM SON BAŞLANGIÇ---
[özet bilgisi]
---
Kaynak Adlandırma
Dosya Yolu Kuralları
Ağ Standardı Dosya Yolu
host:dosyasistemi:/yol/dosya/adı
Örnekler:
SRI:/arpanet/docs/rfc8.txt
UCLA:/home/crocker/projects/network.txt
UCSB:/storage/experiments/data.csv
Kaynak Türleri
| Kaynak | Adlandırma | Örnek |
|---|---|---|
| Dosya | host:dosyayolu | UCLA:/data/file.txt |
| Dizin | host:dizinyolu/ | UCLA:/data/ |
| Kullanıcı | host:kullanıcıadı | UCLA:crocker |
| Hizmet | host:hizmet | UCLA:mail |
Tutarlılık İlkeleri
- Başlangıç eğik çizgi: Dosya sisteminin kökünü gösterir
- Bitiş eğik çizgi: Dizini gösterir
- Özel karakter yok: Alfanumerik, tire, alt çizgi kullan
- Büyük/küçük harf duyarlılığı: Küçük harf olarak tanımla (taşınabilirlik için)
Hata İşleme
Standart Hata Yanıtları
Mesaj Teslim Hataları
ERROR: DELIVERY_FAILED
Reason: Böyle bir kullanıcı yok
Target: SRI:unknown_user
Timestamp: 1969-08-24 14:30:45
Action: Alıcı adını kontrol et; doğru adresle tekrar dene
Dosya Erişim Hataları
ERROR: FILE_NOT_FOUND
Path: UCLA:/nonexistent/file.txt
Timestamp: 1969-08-24 14:31:00
Action: Yolu kontrol et; LISTDIR komutuyla dizini listele
Ağ Hataları
ERROR: HOST_UNREACHABLE
Host: Utah
Reason: Bağlantı zaman aşımı
Timestamp: 1969-08-24 14:32:15
Status: Otomatik yeniden deneme planlandı
Onay Standardı
İstendiğinde (ACKNOWLEDGE: evet):
ACKNOWLEDGMENT: RECEIVED
Message: From UCLA:crocker
Date Sent: 1969-08-24 14:30:00
Date Received: 1969-08-24 14:30:15
Recipient: SRI:duvall
Status: Teslim edildi ve okundu
Önerilen Standartlar
Standart 1: Ağ Adres Formatı
Resmi Tanım:
- Host tanımlama: alfanumerik, 6-8 karakter
- Kullanıcı tanımlama: alfanumerik, 8 karaktere kadar
- Ayırıcı: iki nokta (:)
- Tam format: host:kullanıcı
Benimseme: Tüm yeni mesajlar için anında
Standart 2: Mesaj Başlığı Formatı
Zorunlu Alanlar:
- TO: (alıcı adresi)
- FROM: (gönderen adresi)
- DATE: (zaman damgası)
- SUBJECT: (mesaj konusu)
İsteğe Bağlı Alanlar:
- CC: (kopya alıcıları)
- PRIORITY: (normal, yüksek, düşük)
- ACKNOWLEDGE: (evet veya hayır)
- REPLY-TO: (alternatif yanıt adresi)
Benimseme: Faz 1 (anında)
Standart 3: Karakter Kodlaması
- ASCII kullan (RFC 20'ye göre)
- CRLF satır sonlandırma (RFC 20'ye göre)
- Kodlama spesifikasyonu olmadan ASCII dışı karakter yok
Benimseme: Anında
Standart 4: Hata Yanıt Formatı
Tüm hatalar içermelidir:
- ERROR: [hata kodu]
- Hatanın detayları
- Zaman damgası
- Önerilen eylem
- Otomatik yeniden deneme durumu (uygunsa)
Benimseme: Faz 2 (30 gün içinde)
Uygulama Yol Haritası
Faz 1: Anında (Bu Hafta)
- RFC 8'i tüm NWG üyelerine dağıt
- Adres format kurallarını tanımla
- Mesaj başlığı formatını tanımla
- Formatları desteklemek için host yazılım güncellemeleri
Faz 2: Kısa Vadeli (Gelecek Ay)
- Tüm host'lar RFC 8 standartlarını uygulasın
- Tüm siteler arasında mesaj teslimini test et
- Hata yanıt standartlarını belirle
- Siteye özgü varyasyonları belgele
Faz 3: Orta Vadeli (Gelecek Çeyrek)
- Dosya Transfer Protokolü ile entegre et (RFC taslak hazırlanıyor)
- Uzaktan Oturum Açma hizmetleriyle entegre et
- Ağ kullanıcı kılavuzu oluştur
- Ağ Koordinasyon Merkezi prosedürlerini belirle
Faz 4: Uzun Vadeli (Yıl Sonu)
- Kuralların etkinliğini değerlendir
- RFC 8'e geliştirmeler öner
- Ağ büyüdükçe genişlemeyi değerlendir
- Gerekirse daha büyük adresleme alanı planla
Önem
RFC 8, ağ iletişiminde kullanıcı düzeyinde kuralların erken standardizasyonunu temsil eder.
Tarihsel Etki
Öneri, sonraki tüm ağ protokolleri için ilkeleri belirledi:
- Adresleme: E-posta adresleri ve alan adları için temel
- Mesaj Formatı: E-posta standartları ve protokolleri için temel
- Hata İşleme: Standart yanıt kalıpları
- Kaynak Adlandırma: URL'ler ve URI'lere dönüşen kavramlar
- Kullanıcı Deneyimi: Ağları sadece teknisyenler değil, insanlar tarafından kullanılabilir hale getirdi
Modern Paralellikler
RFC 8 kuralları şunları etkiledi:
- E-posta adresleri: kullanıcı@host formatı
- HTTP: Mesaj başlığı formatı
- URI'ler/URL'ler: Kaynak adlandırma kuralları
- Hata kodları: HTTP durum kodları ve hata mesajları
- API'ler: REST kuralları ve standartları
Devrimci Kavram
Görünüşte basit olsa da, RFC 8'in temel içgörüsü devrimciydi: kullanıcı düzeyinde standardizasyon ağları daha kullanışlı hale getirir.
Sonuç
RFC 8, kullanıcı düzeyinde ağ etkileşimi için tek tip kurallar oluşturmayı önermektedir. Önerilen spesifik formatlar evrimleşebilse de, temel ilke geçerli kalır: kullanıcıya görünür protokollerin standardizasyonu ağ büyümesini ve kullanılabilirliği mümkün kılar.
Bu RFC, başarılı ağların sadece teknik protokoller değil, aynı zamanda kullanıcı düzeyinde kurallar ve kültürel standartlar gerektirdiğini gösterir.
University of California, Santa Barbara (UCSB)
Network Working Group
Ağustos 1969