Zusammenfassung

  • RFC 1700 war nach eigener Aussage eine Momentaufnahme vom Oktober 1994, zusammengestellt aus laufend gepflegten Online-Dateien. RFC 3232 setzte ihn auf Historic, weil die Werte lückenhaft und teilweise falsch geworden waren.
  • Wer eine heutige Zuteilung belegen will, braucht Registername und -URI, Abrufzeit, Zeile, Status, Referenz, Registrierungsregel und einen unveränderlichen Mitschnitt. Der RFC belegt Herkunft, nicht Gegenwart.

Zwei Quellen können einander widersprechen, ohne dass eine gefälscht ist. In RFC 1700 steht eine Zuteilung; das heutige IANA-Register zeigt etwas anderes. Erst die Zeitachse löst den Widerspruch. Die eine Quelle beschreibt eine Ausgabe von 1994, die andere den beim Abruf sichtbaren Stand.

Joyce K. Reynolds machte das in RFC 3232 zur offiziellen Dokumentenlage. Die periodische Assigned-Numbers-Reihe war durch die Online-Datenbank auf der IANA-Seite ersetzt worden. RFC 1700 enthielt nicht mehr alle Werte und lag in einzelnen Fällen falsch. 2002 wurde er deshalb Historic.

Damit verlor der alte RFC nicht seinen Wert. Er verlor lediglich den Anspruch, ein laufendes Register zu sein.

Eine Ausgabe aus gepflegten Dateien

RFC 1700, herausgegeben von Reynolds und Jon Postel, nannte sich ausdrücklich Momentaufnahme eines fortlaufenden Zuteilungsprozesses. Die aktuellen Einträge wurden in Online-Textdateien gepflegt. Für den RFC wurden diese Dateien zusammengefügt und um die nötige Formatierung ergänzt. Anträge und Korrekturen gingen weiterhin an IANA; Reynolds war als Kontakt genannt.

Im älteren RFC 900 ist der Wandel sogar in der Tabelle sichtbar. Alte Netznummern konnten während einer Übergangszeit weiter aufgeführt werden, ergänzt durch Statuszeichen und Verweise. Die Veröffentlichung fror einen Arbeitsstand ein, nicht den Arbeitsprozess.

Die RFC-Nummer machte diesen Stand dauerhaft adressierbar. Doch jede spätere Zuteilung vergrößerte den Abstand zur Ausgabe. Bei einem neuen Eintrag war der RFC bloß unvollständig. Nach einer Korrektur konnte eine alte Zeile aktiv in die Irre führen.

RFC 3232 ordnete daher zwei Erkenntnisfragen. Was im Oktober 1994 veröffentlicht war, lässt sich mit RFC 1700 belegen. Was aktuell zugeteilt ist, verlangt einen datierten Abruf des gepflegten Registers. Wer beides in einer undatierten Quellenangabe vermischt, entfernt genau die Unterscheidung, die Reynolds festhielt.

Hinter jedem Eintrag steht ein Verfahren

Die Online-Fassung ist nicht deshalb maßgeblich, weil sie moderner aussieht. RFC 2860 verteilt Zuständigkeiten für IETF-Protokollparameter. IANA teilt zu und registriert nach Kriterien und Verfahren, die in RFCs stehen. Bei Unklarheiten gibt das IESG technische Anleitung; Streitfälle können zum IAB gelangen.

Zugleich verlangt die Vereinbarung frei zugängliche Online-Informationen über aktuelle Zuteilungen und Einrichtungen für Anträge. Ein Registereintrag ist somit der veröffentlichte Endpunkt einer Kette aus Regel, Antrag, Prüfung und Ausführung.

RFC 8126 zeigt, wie unterschiedlich diese Kette sein kann. Ein neues Register braucht einen eindeutigen Namen, Pflichtfelder, Anfangsbestand, Änderungszuständigkeit und eine Regel für künftige Registrierungen. First Come First Served prüft vor allem Form und Doppelbelegung. Expert Review verlangt die Bewertung durch einen benannten Fachgutachter. Specification Required, RFC Required, IETF Review und Standards Action setzen jeweils andere Hürden bei Dokumentation oder Konsens.

Eine Kopie aus Wert und Bezeichnung reicht deshalb nicht. Sie verliert Status, Referenzen, Änderungsverantwortung und Zuteilungspolitik. Auch Reserved, Unassigned und Deprecated sind unterschiedliche Aussagen, keine Varianten eines leeren Feldes.

Gegenwart ist eine Beobachtung

Die IANA-Selbstdarstellung beschreibt öffentlich zugängliche, maßgebliche Register für weltweit konsistente Kennungen. Am 10. September 2026 erklärte sie außerdem, dass Public Technical Identifiers als ICANN-Tochter die IANA-Funktionen ausführt. Das ist eine datierte Gegenwartsbeschreibung und darf nicht ohne weiteres auf frühere oder spätere Zeiten übertragen werden.

Auch eine dauerhafte Register-URL liefert veränderlichen Inhalt. Ein Status kann wechseln, ein Verweis hinzukommen, ein Fehler berichtigt werden. Deshalb gehören in einen belastbaren Beleg der exakte Registername, die URI, Abrufzeit samt Zeitzone, Zeile oder Bereich, sichtbarer Status und Referenzen sowie die Rohdatei mit Hash.

Wo HTML und strukturierte Daten vorliegen, sollte beides erhalten bleiben. Die normalisierte Tabelle verweist auf diese Ursprungsstücke, statt sie zu ersetzen. Antrag, Fachprüfung, IETF-Entscheidung, IANA-Aktion und spätere Korrektur werden als getrennte Ereignisse verbunden.

Weicht der nächste Abruf ab, bleiben beide Fassungen erhalten. Erst danach wird bestimmt, ob sich Wert, Status, Verweis, Politik oder lediglich der Sammler geändert hat. Ohne Vorher-Version ist diese Diagnose unmöglich.

Reynolds' eigentliche redaktionelle Leistung

Die Internet Hall of Fame nahm Joyce Reynolds 2025 posthum auf. Ihr Porträt nennt die Zusammenarbeit mit Postel am Information Sciences Institute der USC und ihre spätere Mitverantwortung für den RFC Editor. Reynolds starb 2015; daraus folgt ein historischer Beitrag, keine heutige Funktion oder Position.

Gerade weil sie die Umwandlung beweglicher Zuteilungsdaten in dauerhafte RFCs kannte, ist RFC 3232 mehr als eine Statusnotiz. Reynolds ließ Archiv und Betriebsdienst nicht um dieselbe Autorität konkurrieren. Sie gab beiden einen klaren Geltungsbereich.

Ein Forschungsbeleg kann diese Trennung in drei Schichten nachbauen: zeitgestempelter Registerstand; Politik und Entscheidungskette; normative und historische RFCs. Jede Schicht wird unabhängig versioniert und über eindeutige Verweise verbunden.

Ändert sich nur die Politik, entsteht ein Governance-Ereignis. Ändert sich eine Zeile ohne neuen RFC, entsteht ein Registerereignis. Eine Berichtigung des Archivs bleibt mit der ursprünglichen Fassung verknüpft. So wird die Gegenwart aktualisiert, ohne die Vergangenheit umzuschreiben.

Quellen