Zusammenfassung

  • RFC 880 führte Anforderungsstatus, definierendes Dokument, bekannte Probleme, weitere Quellen, Abhängigkeiten und Kontakt als getrennte Felder.
  • Die Einträge widersprechen einer pauschalen Lesart: TCP war empfohlen und dokumentarisch unklar, TFTP wählbar und bereits genutzt, GGP experimentell und zugleich in den Kern-Gateways im Einsatz.
  • Spätere Regeln trennten Reifegrad und Anforderungsstufe; der periodische Gesamtkatalog wurde durch eine Online-Liste ersetzt, ohne dadurch laufenden Code beweisen zu können.

Die im Oktober 1983 veröffentlichte RFC 880 trug den selbstbewussten Titel Official Protocols. Ihr Inhalt war vorsichtiger. Sie ordnete Protokolle ein, verwies auf Spezifikationen und schrieb zugleich auf, wo Dokumente veraltet, Implementierungen abgewichen oder Funktionen kaum genutzt waren.

„Offiziell“ bezeichnete die Aufnahme in dieses kommentierte Arbeitsregister. Das Wort war weder Sicherheitszertifikat noch Implementierungsbericht noch Garantie, dass ein Dienst auf einem bestimmten Host antwortete.

Der Katalog hatte mehrere dokumentarische Quellen

Als erste Näherung berief sich RFC 880 auf das Internet Protocol Transition Workbook vom März 1982. Danach folgten die Ausnahmen. Einige verwendete Protokolle fehlten dort. Andere waren überarbeitet worden. Mail, Telnet und Implementierungshinweise lagen in neueren Bänden; nicht revidierte Optionen stammten noch aus dem ARPANET-Handbuch von 1978.

Schon die RFC 840 vom April 1983 hatte diese Lage in fast derselben Feldstruktur erfasst. RFC 880 löste sie ab. Eine neue Katalogversion konnte erscheinen, ohne dass alle installierten Systeme gleichzeitig wechselten.

STATUS, SPECIFICATION, COMMENTS, OTHER REFERENCES, DEPENDENCIES und CONTACT erfüllten verschiedene Aufgaben. Erwartung, Text, Abweichung, Kontext, technische Voraussetzung und Verantwortungsweg blieben unterscheidbar.

Die Statuswerte waren keine Güteskala

Required verlangte Implementierung auf allen Hosts. Recommended empfahl sie. Elective ließ die Entscheidung offen. Experimental beschränkte sie auf koordinierte Versuchsteilnehmer. None bedeutete, dass der Eintrag kein Protokoll war.

IP und ICMP waren Required, UDP und TCP Recommended, TFTP Elective, EGP und GGP Experimental. Das Catenet Model erhielt None, weil es ein Architekturmodell beschrieb.

Keines dieser Wörter maß aktuelle Ausführung. Required bewies kein aktiviertes Paket. Recommended bewies keine Interoperabilität. Elective bewies keine geringe Verbreitung. Experimental bewies keinen leeren Produktionspfad.

TCP behielt neben der Empfehlung eine Mängelliste

Der TCP-Eintrag verwies auf RFC 793 und nannte den Status Recommended. Anschließend führte er viele Korrekturen auf, überwiegend Dokument- statt Protokollfehler.

Die Ereignisverarbeitung brauchte Klarstellungen. Push klang an einigen Stellen noch wie eine Satzgrenze. MSS-Standardwert und -Umfang waren unklar. Listening Server, Leerlaufverbindungen, gepufferte Daten beim Schließen, ungeordnete Segmente und User Timeout verlangten genauere Regeln.

Die Empfehlung blieb bestehen, gerade weil die Kommentare den offenen Interpretationsraum sichtbar hielten. Wer nur den Status in eine Freigabeliste kopierte, entfernte einen wesentlichen Teil der offiziellen Information.

Experimental konnte im Kern laufen

EGP war Experimental und befand sich in Entwicklung. GGP war ebenfalls Experimental; die Kommentare beschrieben es jedoch als das damals in den Kern-Gateways eingesetzte Protokoll.

Das ist keine Messung von Stückzahl, Konformität oder Verfügbarkeit. Es widerlegt nur die Gleichsetzung von Experimental mit nicht betrieben. Ein Verfahrensstatus und ein beobachteter Einsatzort waren zwei Aussagen.

Beim Stream Protocol hatte sich die Implementierung weiterentwickelt und entsprach möglicherweise nicht mehr der Spezifikation. Laufender Code authentifizierte den Text also nicht. TFTP war Elective und zugleich in mehreren lokalen Netzen in Gebrauch. Wahlfreiheit war nicht Nichtwahl.

Telnet brauchte eine eigene USE-Spalte

Die Tabelle der Telnet-Optionen verzeichnete RFC- oder NIC-Dokumente, Aufnahme in den neuen Telnet-Band, Herkunft aus dem alten Handbuch und USE. Echo, Binary Transmission, Suppress Go Ahead und weitere aktualisierte Optionen waren häufig implementiert; viele ältere nicht allgemein genutzt.

Die Optionsfamilie war insgesamt Elective. Daraus leitete RFC 880 nicht die Unterstützung jedes Merkmals ab. „Telnet-fähig“ sagte nichts Sicheres über die konkrete Optionsaushandlung zweier Partner.

USE war keine vollständige Telemetrie mit bekanntem Nenner. Die Spalte erkannte aber an, dass Dokumentation, Erlaubnis und beobachtete Nutzung getrennt erhoben werden müssen.

Abhängigkeiten banden den Eintrag an eine Kette

SMTP und Telnet benötigten TCP, TFTP benötigte UDP, Gateway-Protokolle benötigten IP. Der obere Katalogeintrag erzeugte die unteren Implementierungen nicht automatisch.

CONTACT gab Experimenten und Auslegungsfragen einen Adressaten. Das verlieh keiner Person Herrschaft über alle Netze. Es zeigte, dass Klassifikation Wartung und lokale Entscheidungen nicht ersetzte.

Die RFC 991 setzte diese Reihe 1986 als offiziellen Statusbericht fort. Die Folge der Ausgaben machte Aktualisierung zum Teil des Mechanismus.

Reife und Verpflichtung wurden formell getrennt

1991 unterschied RFC 1200 den Standardisierungs-STATE — Standard, Draft Standard, Proposed Standard, Experimental, Informational, Historic — vom Anforderungs-STATUS — Required, Recommended, Elective, Limited Use, Not Recommended.

RFC 2026 entwickelte Standards Track und Anwendbarkeit weiter. RFC 6410 reduzierte später drei Reifestufen auf zwei. Das Verfahren änderte sich; die Zahl laufender Implementierungen wurde dadurch nicht gemessen.

Schließlich veraltete auch die periodische Gesamtausgabe. RFC 7100 setzte 2013 die letzte Zusammenfassung und STD 1 außer Kraft, nachdem die Online-Liste des RFC Editor sie verdrängt hatte. Leichtere Aktualisierung machte den Katalog praktischer, nicht allwissend.

Quellen und Grenzen

Die Darstellung stützt sich auf RFC 840, RFC 880, RFC 991, RFC 1200, RFC 2026, RFC 6410 und RFC 7100. Sie belegen weder heutige Verbreitung noch Produktkonformität, aktuelle Sicherheit, Betreiberpolitik, Ausfall oder Vorfall.