Zusammenfassung

  • RFC 1280 war ein periodischer Koordinationsstand, kein Echtzeitverzeichnis: Leser sollten die aktuelle Ausgabe suchen und diese Fassung nach dem 31. Juli 1992 nicht mehr verwenden.
  • STATE bezeichnete den Reifegrad der Standardisierung, STATUS die Anforderungen an die Implementierung. Keines der beiden Labels belegte allein Verbreitung oder Betriebserfolg.

Eine Übersicht kann gerade deshalb täuschen, weil sie nützlich ist. Wer wissen musste, wo ein Protokoll im Internet-Standardisierungsprozess stand, brauchte eine gemeinsame Referenz statt vieler einzelner RFCs. RFC 1280 bündelte Einträge, erläuterte die Prozessstufen und ordnete Anforderungen zu. Zugleich begrenzte das Memo seine eigene Aussagekraft: Die Ausgabe vom März 1992 sollte ungefähr vierteljährlich erneuert werden und nach Juli nicht mehr gelten.

Das Ablaufdatum bedeutete nicht, dass sich am 1. August jedes Protokoll ändern würde. Es begrenzte den Zeitraum, für den dieser Katalog als Beleg taugen sollte. Das IAB verwies auf aktuelle Ausgaben beim Network Information Center oder bei IANA und auf die Änderungshinweise der Einträge. Im September löste RFC 1360 die RFC 1280 ab. Ein offizielles Verzeichnis kann also zum Veröffentlichungszeitpunkt maßgeblich sein und bei der nächsten Entscheidung bereits veraltet.

Die Tabelle trennte zwei Koordinaten. STATE beschrieb die Reife einer Spezifikation: Standard, Draft Standard, Proposed Standard, Experimental, Informational oder Historic. STATUS gab die Umsetzungserwartung an: Required, Recommended, Elective, Limited Use oder Not Recommended. Eine vorgeschlagene Spezifikation konnte nur optional sein; ein informatives Dokument konnte eine Nutzung empfehlen. Der erste Wert ordnete den Prozessstand ein, der zweite die Erwartung an bestimmte Systemklassen.

Das war keine Zählung installierter Systeme. RFC 1280 hielt fest, dass einige Herstellerprotokolle ohne Empfehlung des IESG oder Bestätigung des IAB weite Verbreitung erreicht hatten. Umgekehrt dokumentierte „Experimental“ Forschung, ohne den Betriebseinsatz zu empfehlen. Eine Veröffentlichung beweist keine Einführung, und ein Reifestatus misst keine Beliebtheit. Dafür wären andere Belege nötig: unabhängige Implementierungen, Interoperabilitätstests und Betriebserfahrung.

Auch die ergänzenden Referenzdokumente wurden nicht gleichzeitig aktualisiert. Assigned Numbers, Gateway Requirements und Host Requirements hatten eigene Änderungszyklen; bei Widersprüchen sollte das neuere Dokument gelten. RFC 1280 half, die aktuelle RFC für ein Protokoll zu finden, synchronisierte aber nicht alle Grundlagen. RFC 1310 beschrieb das Verfahren und bezeichnete die periodische Übersicht als maßgebliche Statusquelle. Diese Autorität blieb an Datum und Geltungsbereich gebunden: Ein historischer Eintrag belegt weder heutiges Verhalten noch eine konkrete Installation oder erfolgreiche Dienstantwort.

Quellen: RFC 1280; RFC 1310; RFC 1360.