RFC 17'ye Düzeltmeler ve RFC 17 Hakkında Bazı Resmi Yorumlar

Genel Bakış

Konu: RFC 17'ye düzeltmeler ve açıklamalar, artı RFC 17'nin yorumlarına resmi yanıtlar.

Amaç: Geri bildirim sürecinin işlediğini göstermek; yazarların eleştiriye yanıt vermesi; sorunların ele alınması.

Bağlam: RFC 17'nin sorunları artık kamuya açık olduğundan, güncellemeler ve açıklamalar sağlamak için fırsat yaratma.

---

İçindekiler

1. Önsöz
2. RFC 17'ye Düzeltmeler
3. RFC 17 Sorunlarına Resmi Yanıt
4. Bekleyen Açıklamalar
5. Takip RFC'leri
6. Güncellenmiş Zaman Çizelgesi
7. Önem

---

Önsöz

Ne Oldu

1. RFC 17, RFC 1 hakkında önemli sorular ortaya attı
2. RFC 1'in yazarları sorunları inceledi
3. Sonuç: Bazı sorunlar hemen ele alınabilir; diğerleri NWG tartışması gerektirir

Bu RFC'nin Amacı

Resmi oylama beklemek yerine, şunları yapan geçici yanıtlar sağlamak:

• Bazı sorunları doğrudan ele almak
• Diğerlerinin amaçlanan anlamını netleştirmek
• Topluluk tartışması gerektiren sorunları kabul etmek
• Çözümler için zaman çizelgesi önermek

---

RFC 17'ye Düzeltmeler

Düzeltme 1: Bağlantı Numarası Yorumlama

RFC 17 Dedi: "RFC 1, bağlantı numaralarının global olarak benzersiz olup olmadığını belirtmiyor"

Açıklama: RFC 1, yerel benzersizlik amaçlamaktadır

Nedeni: Her HOST çifti ayrı bağlantı alanı tutar

Host A ve Host B arasında:
- 0-65535 arasında bağlantı numaraları mevcut
- Her çift bağımsız
Yani A→B'deki "Bağlantı 1024", B→A'daki "Bağlantı 1024"den farklıdır

Bu Nasıl Çalışır:

Host A'dan Host B'ye: "Bağlantı 1024" kurar
Host B'den Host A'ya: "Bağlantı 1024" kurar
Bunlar iki farklı bağlantıdır (farklı yönler)
Her ikisi de aynı anda açık olabilir
Başlıklardaki tanımlayıcılar onları ayırır

RFC 1 Daha Net Olmalıydı: Güncellenmiş sürümde düzeltilecek

Düzeltme 2: Mesaj Boyutu Birimleri

RFC 17 Dedi: "RFC 1, bit vs. bayt konusunda belirsiz"

Açıklama: RFC 1, boyunca bit kullanır

Tarihsel Bağlam: Erken protokol bit odaklı iletim kullandı

Mesaj başına maksimum 8192 bit
= 1024 bayt
= 128 kelime (36-bit sistemlerde)
= 256 kelime (32-bit sistemlerde)

Ama RFC 17 Haklı: Farklı sistemlerin farklı doğal birimleri var

Önerilen Çözüm: Güncellenmiş RFC bunu netleştirmeli ve belki bayt odaklı ölçüm önermeli

Düzeltme 3: BİRİNCİL vs. YARDIMCI Bağlantı Kullanımı

RFC 17 Sordu: "Kontrol mesajları yardımcı bağlantılarda gönderilebilir mi?"

Cevap: Başlangıçta HAYIR; yardımcıda sadece veri

Ama RFC 17 Haklı: Bu açık olmalı

Önerilen Açıklama:

BİRİNCİL Bağlantı:
- Bağlantı/bağlantı kesme mesajları
- Akış kontrol sinyalleri
- Durum sorguları
- Hata bildirimi
YARDIMCI Bağlantı:
- Sadece veri transferi
- Kontrol mesajı yok
- Güvenilir toplu transfer

Bu, güncellenmiş RFC 1'de belgelenecek

---

RFC 17 Sorunlarına Resmi Yanıt

Sorun 1'e Yanıt: Bağlantı Numaralandırma

RFC 17'nin Sorusu: Bağlantı numaraları global olarak benzersiz mi?

Resmi Cevap: Her kaynak-hedef çiftine yerel

Açıklama:

Başlık, kaynak ve hedef host tanımlayıcıları içerir
Böylece farklı konuşmalardaki yinelenen bağlantı numaraları çakışmaz
Format şu şekilde netleştirilmelidir:
+─────────────────+─────────────┬──────────────────+
| Kaynak Host ID  | Hedef Host ID| Bağlantı #      |
| (8 bit)         | (8 bit)      | (değişken)      |
+─────────────────+─────────────┬──────────────────+

Bu, benzersizliği netleştirir

Sorun 2'ye Yanıt: Bayt vs. Bit İletimi

RFC 17'nin Gözlemi: Tutarsız terminoloji

Resmi Yanıt:

Orijinal protokol spesifikasyonu boyunca bit kullanır.

Bu Neden Garip: Farklı host sistemlerinin farklı kelime boyutları var:

IBM System/360: 32-bit kelimeler
PDP-10: 36-bit kelimeler
IMP: 24-bit kelimeler

İdeal Çözüm: Baytlarda (8-bit birimler) standartlaş

Tüm sistemler baytları doğal olarak işleyebilir:

1024 bayt, yerel kelime boyutundan bağımsız olarak nettir
8192 bit hesaplama gerektirir: ÷8, ÷1024, vb.

Eylem: RFC 1, bayt odaklı ölçüm kullanacak şekilde güncellenecek

Sorun 3'e Yanıt: Kontrol vs. Veri Mesajları

RFC 17'nin Sorusu: Nasıl ayırt edilirler?

Resmi Cevap: Mesaj türü alanı amacı gösterir

Başlık alanı: Mesaj Türü (32 bit)
Değerler:
1 = VERİ
2 = AÇ
3 = KAPAT
4 = SIFIRLA
(ve RFC 12'ye göre diğerleri)

RFC 1 Daha Net Olmalıydı: Bu eklenecek

Sorun 4'e Yanıt: Hata Kurtarma

RFC 17'nin Gözlemi: Kurtarma prosedürleri belirsiz

Resmi Yanıt:

Kabul; bu resmi spesifikasyon gerektirir

Önerilen Prosedür (güncellenmiş RFC için):

Hata Tespiti:
1. IMP kötü sağlama toplamı olan mesaj alır
2. IMP mesajı sessizce atar
3. IMP hata bildirimi GÖNDERMEz
Host Tarafı:
1. Host mesaj gönderir
2. RFNM (Sonraki Mesaj İçin Hazır) bekler
3. 10 saniye içinde RFNM gelmezse: yeniden ilet
4. 3 denemeden sonra: uygulamaya hata bildir

Ana İlke: IMP hatalarda sessizdir; host zaman aşımı ile tespit eder

Bu Tasarım Neden: Hata mesajları için aşırı trafikten kaçınır

Sorun 5'e Yanıt: Mesaj Parçalama

RFC 17'nin Sorusu: Mesaj > 8192 bit ise ne olur?

Resmi Cevap: Host parçalamadan sorumludur

IMP parçalamaz
Host şunları yapmalı:
1. Büyük dosyayı ≤8192-bit parçalara böl
2. Parçaları numaralandır (sıralı olarak)
3. Her birini ayrı mesaj olarak gönder
4. Alıcı sıra numarasına göre yeniden birleştirir

Bu Tasarım Neden: IMP yazılımını basit tutar; karmaşıklığı host'a iter

RFC 1 Belirtmeli: Açık sıra numaralandırma şeması

---

Bekleyen Açıklamalar

Bekleyen 1: Tam Durum Makinesi

Gerekli: Resmi durum diyagramı

Neden Önemli: Farklı sitelerde farklı yorumları önler

Durum: RFC güncellemesi için hazırlık aşamasında

Mevcut Gayri Resmi Durumlar:

KAPALI
↓ (Host açma talep eder)
AÇILIYOR
↓ (IMP onaylar)
AÇIK
↓ (SEND/RFNM mesajları değiş tokuş et)
(Durum sorgula)
(Hataları işle)
↓ (Host kapatmayı başlatır)
KAPANIYOR
↓ (IMP kapatmayı onaylar)
KAPALI
Geçişler:
AÇIK → Zaman aşımı → HATA veya SIFIRLA durumuna gidebilir

Resmi diyagram bunu kesinleştirecek

Bekleyen 2: Zamanlama Parametreleri Tablosu

Gerekli: Açık zamanlama değerleri

Örnek Değerler (Önerilen):

Durum: Topluluk geri bildirimi talep edildi

Bekleyen 3: Genişletilmiş Hata Kodları

Mevcut Spesifikasyon: Minimum hata kodları

Önerilen Eklemeler:

1 = Bilinmeyen bağlantı
2 = Sağlama toplamı hatası
3 = Mesaj çok uzun
4 = Geçersiz mesaj türü
5 = Bağlantı zaman aşımı
6 = Belirtilmemiş IMP hatası
7 = Hedef ulaşılamaz
8 = Kaynak engellenmiş/kısıtlanmış

RFC: Ayrı hata kodu spesifikasyonu olarak yayınlanacak

---

Takip RFC'leri

RFC 1 Geliştirilmiş Baskı (Devam Ediyor)

Başlık: "Host Yazılımı" (Revize Edilmiş)

Orijinal RFC 1 Üzerinde İyileştirmeler:

1. Bitler yerine bayt odaklı ölçüm
2. Alan boyutlarıyla açık mesaj formatı
3. Tam durum makinesi diyagramı
4. Zamanlama parametreleri tablosu
5. Bağlantı numaralandırma açıklaması
6. Parçalama prosedürü
7. Hata kurtarma spesifikasyonu

Hedef Yayın: 5 Eylül 1969

RFC 1a: RFC 1'e Tamamlayıcılar (Planlanmış)

Başlık: "Host Yazılımı - Uygulama Notları"

İçerik:

• RFC 1 notasyonundan gerçek koda çeviri
• UCLA'da örnek uygulama
• Yaygın tuzaklar
• Hata ayıklama stratejileri

Hedef Yayın: 15 Eylül 1969

Yeni RFC: Mesaj Sıralaması (Önerilmiş)

Konu: Sıra dışı gelen mesajları işleme

Tetikleyen: RFC 9 ve RFC 17 gözlemleri

İçerik:

• Ne zaman/neden mesajlar sıra dışı gelir
• Sıra numarası şeması
• Alıcı yeniden birleştirme algoritması
• Sıra numaralarının onaylanması

Hedef Yayın: 30 Eylül 1969

Yeni RFC: Hata Kodları Spesifikasyonu (Önerilmiş)

Konu: Tüm hata türlerinin tam sayımı

Tetikleyen: RFC 17

İçerik:

• Her hata türü: kod, neden, kurtarma
• Hatalar host'a nasıl bildiriliyor
• Hata kurtarma örnekleri

Hedef Yayın: 1 Ekim 1969

---

Güncellenmiş Zaman Çizelgesi

Anında (Bu Hafta)

• RFC 1 ve RFC 17, yazarlık ekibi tarafından incelendi
• RFC 17a (bu belge) yayınlandı
• Bulguları tartışmak için Pazartesi NWG toplantısı

Kısa Vadeli (Sonraki 2 Hafta)

• RFC 1 Geliştirilmiş Baskı tamamlandı ve incelendi
• Topluluk geri bildirimi toplandı
• Uygulama notları taslağı hazırlandı

Orta Vadeli (Gelecek Ay)

• RFC 1 Geliştirilmiş yayınlandı
• Mesaj sıralama RFC'si yayınlandı
• Hata kodları RFC'si yayınlandı
• Tüm host'lar uygulamaları güncelledi
• Siteler arası iletişim test ediliyor

Uzun Vadeli (Gelecek Çeyrek)

• Tüm sitelerin güncellenmiş RFC 1'i kullandığını doğrulama
• Kalan sorunların değerlendirilmesi
• Daha fazla geliştirme planları
• Faz 2 özellikleri değerlendirmesi

---

Önemli Açıklamalar

Açıklama 1: Bu Başarısızlık İtirafı Değildir

Önemli Not: RFC 17 sorunları tanımladı, ancak RFC 1 temelden bozuk DEĞİL

İyi Çalışan:
- Protokol temelleri sağlam
- Ağ operasyonel
- Host'lar başarıyla mesaj değiş tokuş ediyor
- Temel tasarım kusuru yok
İyileştirme Gereken:
- Spesifikasyonun netliği
- Belirsiz olmayan anlamlar
- Uygulama tutarlılığı
- Detayların tamlığı

Bu Normaldir: Tüm ilk spesifikasyonların netleştirilmeye ihtiyacı var

Açıklama 2: Topluluk Süreci Çalışıyor

Ana İçgörü:

• RFC 1 yayınlandı
• RFC 17 sorunları tanımladı
• RFC 17a yanıt veriyor
• Topluluk spesifikasyonu birlikte geliştiriyor

Bu İyidir: Utanılacak değil; standartlar böyle çalışmalı

Açıklama 3: Sorular Teşvik Edilir

Topluluğa Mesaj:

• RFC belirsizse, sor
• Belirsizlik varsa, dile getir
• Alternatifler varsa, öner
• İyileştirme geri bildirimden gelir

---

Önem

RFC 17a, bir yanıt belgesi olarak dikkat çekicidir: standartların gerçek zamanlı iyileştirilmesini gösterir.

Tarihsel Önem

1. Geri Bildirim Döngüsü: Tanımlanan sorunların ele alındığını gösterir
2. Şeffaflık: Sorunlar ve çözümler kamuya açık belgelenir
3. Kalite İyileştirmesi: Ardışık RFC'ler öncekilerden daha iyi
4. Topluluk İşbirliği: Birden fazla yazar katkıda bulunuyor

Süreç Dersi

RFC 17a şunları gösterir:

• Standartlar yaşayan belgelerdir ve evrimleşir
• Eleştiriye yanıtlar zayıflatmak yerine güçlendirir
• Yinelemeli iyileştirme normal ve sağlıklıdır
• Kamuya açık tartışma daha iyi sonuçlar üretir

Modern Paralel

Aynı kalıp bugün tekrarlanır:

• HTTP 1.0/1.1/2.0 → deneyime dayalı evrim
• IPv4 → sınırlamalar IPv6'ya yol açtı
• TCP ayarlamaları → ağ deneyimine dayalı
• Web standartları → geri bildirime dayalı sürekli evrim

---

Sonuç

RFC 17a, doğru çalışan standartlar sürecini temsil eder:

1. Öneri (RFC 1) yayınlandı
2. Sorunlar tanımlandı (RFC 17)
3. Yanıtlar sağlandı (RFC 17a)
4. İyileştirmeler yapıldı
5. Döngü devam ediyor

ARPANET ve internet, erken spesifikasyonlar mükemmel olduğu için değil, topluluğun sürekli iyileştirme için bir sürece sahip olması nedeniyle başarılı oldu.

---

University of California, Los Angeles (UCLA)

Network Working Group

Ağustos 1969