Zusammenfassung

  • RFC 9720 unterscheidet zwischen RFCXML als endgültigem Format, der endgültigen Fassung und den veröffentlichten HTML-, Text- und PDF-Fassungen. Neubearbeitungen sind nur für eng umrissene Wartungsgründe vorgesehen und sollen Semantik so weit wie möglich erhalten.
  • Vertrauen entsteht nicht durch das Etikett „kanonisch“, sondern durch eine prüfbare Kette aus Vorgängerfassung, Datum, Begründung, Differenz und lokaler Entscheidung desjenigen, der von der RFC abhängt.

Stabilität ist kein Verbot jeder Reparatur

Als RFCs im Wesentlichen einzelne ASCII-Dateien waren, schützte die Formel „veröffentlicht heißt unveränderlich“ vor nachträglicher Geschichtsschreibung. Die Serie arbeitet inzwischen mit einem vollständigen RFCXML-Dokument und daraus gerendertem HTML, Klartext und PDF. Ein XML-Fehler kann entdeckt werden, das Schema kann sich entwickeln, ein Renderer kann ausgetauscht werden. Wer jede Änderung verbietet, konserviert vermeidbare Mängel. Wer jede Änderung zur bloßen Formatfrage erklärt, gibt der Produktion eine unsichtbare Redaktionsermächtigung.

RFC 9720 erschien im Januar 2025 im Editorial Stream, ersetzt RFC 7990 und aktualisiert die damalige Stabilitätspolitik aus RFC 9280. Sie ist informational, nicht Standards Track. Der Text ist daher eine veröffentlichungspolitische Regel der RFC-Serie und weder ein Befehl an jeden Betreiber noch ein Unbedenklichkeitszertifikat für jede Dateiänderung.

Die zentrale Klärung ist begrifflich. „Canonical format“ hatte früher zwei Aufgaben: Es bezeichnete die XML-Quelle und zugleich die autorisierte archivierte Fassung. RFC 9720 nennt RFCXML das endgültige Format und ein darin veröffentlichtes RFC die endgültige Fassung. HTML, Text und PDF sind Veröffentlichungsformate; jede konkrete Ausgabe ist eine Veröffentlichungsfassung. Ein anderes PDF beweist damit nicht allein eine andere Norm. Ein wartbares XML ist umgekehrt keine Vollmacht, die Norm frei umzuschreiben.

Enger Wartungsauftrag

Das RFC Production Center darf eine endgültige Fassung wegen Änderungen des RFCXML-Schemas, entdeckter XML-Fehler oder veränderter Erzeugungswerkzeuge neu herausgeben. Dabei soll der semantische Inhalt so weit wie möglich bewahrt werden. Die RFC verspricht nicht unmögliches Nullrisiko: Auch syntaktisch gemeinte Änderungen können unbeabsichtigte Bedeutung verändern. Gefordert sind Risikoverständnis, Begrenzung und Nachprüfbarkeit.

Auch Veröffentlichungsfassungen dürfen, müssen aber nicht, neu herausgegeben werden. Konsistenz der Serie und Risiko einer Bedeutungsänderung sind gegeneinander abzuwägen. Das verhindert beide bequemen Irrtümer: bekannte Fehler müssen nicht wegen eines Starre-Slogans bleiben, und Designvorlieben dürfen keine historische Datei lautlos ersetzen.

Die gemeinsame Regel ist bewusst klein. Sie fixiert die semantische Grenze und die begrenzte Wartungszuständigkeit. Speicherung, Auffindbarkeit alter Dateien und künftige Werkzeuge bleiben bei denjenigen, die sie tatsächlich betreiben. Dass RFC 9720 keinen Locator für historische Dokumente vorschreibt, ist keine Lücke; eine Formatregel übernimmt dadurch nicht die gesamte Archivhoheit.

Ohne Vorgänger keine überprüfbare Erklärung

Die eigentliche Sicherung ist das Archiv. Der RPC muss ältere endgültige und veröffentlichte Fassungen über dieselben Zugangswege wie aktuelle Fassungen verfügbar halten und jeweils Erstellungs- oder Neuherausgabedatum speichern. Für jede Neuherausgabe einer endgültigen Fassung verlangt die RFC zudem eine öffentliche Aufzeichnung mit kurzer Begründung.

Deshalb beantwortet eine heutige HTML-Seite keine historische Abhängigkeitsfrage allein. Bei einer Abbildung, Referenz, nicht-ASCII-Zeichen, normativen Formulierung oder einem von Werkzeugen gelesenen Beispiel braucht man Vorgänger, Nachfolger, Begründung und Diff. Ein Umbruch mag nur Darstellung sein. Ein geändertes MUST, ein URI, ein Datenelement oder ein parsbares Beispiel kann Code, Audit und Vertrag berühren. Weder ein neues Layout noch eine beruhigende Notiz entscheidet das.

Die Rollen bleiben getrennt: Autoren und Freigabeprozess verantworten die beabsichtigte Bedeutung, Produktion die Darstellung innerhalb der Grenze, Implementierer und Betreiber die Version, die sie fixieren und testen. Wer die neue Datei ausliefert, erhält nicht automatisch das Mandat, über fremdes Betriebsrisiko zu entscheiden.

Das IETF-Profil nennt Flanagan als RFC Series Editor von 2012 bis 2019, Principal von Spherical Cow Consulting und gegenwärtige Vorsitzende von SPICE und HotRFC. Das ist der belegte Personenbezug. Es macht sie weder zur Alleinautorin von RFC 9720 noch zur aktuellen RPC-Betreiberin oder Entscheiderin jeder späteren Neuherausgabe.

Eine RFC-Nummer ist kein vollständiger Nachweis

RFC 9920 von Februar 2026 hat RFC 9280 obsolet gemacht und aktualisiert RFC 9720 im Rahmen weiterer Seriendokumente. Auch die Politik hat Versionen. Daraus folgt weder, dass jede neue Datei harmlos ist, noch dass jede Differenz gefährlich sein muss. Entscheidend bleibt: Welche Fassung wurde verwendet? Was hat sich geändert? Welcher Bestandteil wertet die Differenz aus? Ist die Entscheidung reversibel?

Ein Betreiber sollte RFC-Nummer, Kennungen und Daten der endgültigen und veröffentlichten Fassung, Abruf-URL und Hash, Neuherausgabegrund, semantischen und visuellen Diff, abhängige Komponente, Prüfer und Rollback-Grenze bewahren. Die frühere Fassung muss weiter abrufbar sein. Nur dann wird aus einer Erklärung eine nachvollziehbare Beweiskette.

Das entspricht Heng Lus Trennung von Beleg und Mandat. Eine öffentliche Begründung ist ein Beleg für eine Handlung der Produktion. Sie ist keine Weisung, dass ein Dritter seine laufende Abhängigkeit automatisch ändert. Die Entscheidung bleibt bei demjenigen, der die betriebliche Folge trägt.

Quellen