← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 17a · protokol

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

Yazar
Steve Crocker
Kurum
UCLA
Tarih
29 Ağustos 1969
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

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 oluşturma.

İç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:

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):

Olay Zaman Aşımı Yeniden Deneme Sayısı
AÇMA Yanıtı 10 saniye 3 kez
MESAJ için RFNM 10 saniye 3 kez
Bağlantı boşta 300 saniye N/A (kapat)
Canlı tutma (NOOP) 60 saniye Periyodik

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:

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:

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:

Hedef Yayın: 1 Ekim 1969

Güncellenmiş Zaman Çizelgesi

Anında (Bu Hafta)

Kısa Vadeli (Sonraki 2 Hafta)

Orta Vadeli (Gelecek Ay)

Uzun Vadeli (Gelecek Çeyrek)

Ö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ü:

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

Açıklama 3: Sorular Teşvik Edilir

Topluluğa Mesaj:

Ö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:

Modern Paralel

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

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