Zusammenfassung

  • Obsoletes ist für die Dokumentenlinie verbindlich: Der neue RFC wird zum allgemeinen Ausgangspunkt für die aktuelle Spezifikation oder Praxis, während der ältere RFC im dauerhaften Archiv verbleibt.
  • Die Beziehung patcht keine Software, deaktiviert keine Funktion, zieht kein Produkt zurück und schafft kein gesetzliches Verbot. Für jede dieser Wirkungen braucht es einen anderen Akteur und einen eigenen Nachweis.
  • HTTP/2 zeigt, wie eine Protokollidentität auf dem Draht fortbesteht, obwohl der maßgebliche Text wechselt. TLS zeigt, dass formell aufgegebene Versionen lange genug weiterlaufen können, um Sicherheit und Interoperabilität gegeneinander abzuwägen.
  • Erst ein Migrationsbeleg schließt die Lücke: Dokumentenlinie, geladene Version, Abhängigkeiten, Tests, Ausnahmeverantwortung, Rückfallbedingung und Telemetrie über die tatsächliche Stilllegung.

Als sich der Katalog änderte

Im Kopf von RFC 9113 steht, dass das Dokument RFC 7540 und RFC 8740 obsolet macht. Innerhalb der RFC-Serie ist dies ein wirksamer Akt. Wer HTTP/2 heute verstehen will, soll beim neueren Text beginnen. Der Eintrag des alten Dokuments verweist auf seinen Nachfolger. IANA aktualisiert bestimmte Referenzen. Wer Konformität mit RFC 9113 beansprucht, muss dessen sachliche Änderungen beachten.

Der Publikationsakt eröffnet jedoch keine Administratorsitzung auf einem Server. Eine bereits ausgelieferte Bibliothek lernt keine neue Validierungsregel. Ein Proxy verliert nicht automatisch den Klartext-Upgradepfad. Eine Appliance installiert keine Firmware. Der normative Vorgang ist real, doch sein unmittelbarer Gegenstand ist zunächst der Dokumentenbestand.

Diese Feststellung schwächt die IETF nicht. Sie macht ihre Rolle zurechenbar. Das Normungsverfahren bestimmt die aktuelle technische Grundlage. Der RFC Editor erhält unveränderliche Texte und ihre Beziehungen. IANA pflegt genaue Registerverweise. Keine dieser Stellen muss so tun, als könne sie fremde Maschinen fernsteuern, um wirksam zu koordinieren.

Die Verwechslung ist trotzdem attraktiv. Eine RFC-Nummer in einer Kontrolltabelle zu ändern kostet wenig. Alte Clients, eingebettete Geräte, Zwischenstellen und Geschäftspartner zu finden kostet viel. Wird die neue Dokumentenbeziehung als vollzogene Einführung ausgegeben, erhält eine Organisation einen grünen Bericht, bevor sie ihren tatsächlichen Bestand kennt.

Der Katalog soll die richtige Frage auslösen. Er darf nicht für die Maschine antworten.

Ersetzt heißt nicht gelöscht

Der RFC Editor beschreibt die Beziehung nüchtern. Veröffentlichter RFC-Text wird nicht nachträglich geändert. Eine Überarbeitung oder Ablösung erhält eine neue Nummer. Obsoletes bedeutet, dass der neue RFC die aufgeführten RFCs als allgemeinen Bezugspunkt für die gegenwärtige Spezifikation oder Praxis ersetzt. Die älteren Dokumente bleiben Teil des dauerhaften Archivs.

Das Archiv ist technisches Gedächtnis. Es zeigt, welche Regel ein älteres Produkt zum Zeitpunkt seiner Entwicklung umsetzen sollte. Es erlaubt, eine Abweichung der richtigen Textfassung zuzuordnen. Nach einem Vorfall lässt sich unterscheiden, ob eine Komponente der damaligen Spezifikation folgte oder eine spätere Änderung unvollständig übernahm. Eine Löschung würde die Übersicht vereinfachen und die Beweislage verschlechtern.

RFC 7322 ordnet Updates und Obsoletes dem Dokumentenkopf zu. Er erkennt zugleich an, dass ein obsoleter RFC weiter zitiert werden kann, meist zusammen mit der jüngeren Fassung. Eine unveränderliche Reihe entwickelt sich über sichtbare Beziehungen, nicht über heimliche Änderungen an der Vergangenheit.

Die Zeile ist deshalb keine unverbindliche Randnotiz. Ein Hersteller kann nicht Konformität mit RFC 9113 behaupten und nur die bequemen Teile von RFC 7540 behalten. Eine Architekturprüfung, die die Beziehung ignoriert, kann auf einer ersetzten Regel aufbauen.

Direkt bewiesen wird jedoch nur die Dokumentenlinie. Nicht bewiesen sind ein geladener Patch, eine ausgeschaltete Einstellung, das Ende eines Produkts, eine geänderte Vertragslage oder ein behördliches Verbot. Wer all dies unter „obsolet“ zusammenfasst, verdeckt mehrere Entscheidungsflächen.

Sechs verschiedene Handlungen

Die erste ist die Dokumentenablösung. Das Normungsverfahren setzt den jüngeren allgemeinen Bezugspunkt; das Archiv behält beide Texte und verbindet sie.

Die zweite ist eine Status- oder Anwendungsentscheidung. Eine Spezifikation kann Historic werden. Eine Best Current Practice kann Sicherheitsanforderungen verschärfen. Eine Anwendbarkeitserklärung kann eine Regel auf neue Protokolle oder bestimmte Umgebungen begrenzen.

Die dritte ist die Abkündigung einer Funktion. Das Protokoll kann seinen Namen und einen großen Teil seines Verhaltens behalten, während ein einzelner Pfad entfernt oder nicht mehr empfohlen wird.

Die vierte ist eine Implementierungsänderung. Maintainer ändern Quellcode, bauen Releases, wählen unterstützte Zweige und erstellen Backports. Verfügbarer Code ist kein Nachweis für geladenen Code.

Die fünfte ist die Betriebsentscheidung. Der Betreiber inventarisiert, prüft Gegenstellen, ändert Konfigurationen in Kohorten, beobachtet Fehler und genehmigt eine befristete Ausnahme oder lehnt sie ab. Hier wird das Ausfall- oder Restrisiko tatsächlich übernommen.

Die sechste ist eine äußere Verpflichtung. Kunde, Vertrag, Versicherer, Beschaffung, Regulierer oder Gericht können eine Entfernung auf eigener Grundlage verlangen. Ihre Autorität stammt nicht aus dem Layout des RFC-Kopfs.

Eine Handlung kann die nächste verursachen. Ein RFC kann ein Release auslösen, eine BCP die Risikoeinschätzung eines Versicherers verändern, ein Supportende den Zeitplan eines Betreibers verkürzen. Ursache ist aber nicht Identität. Wer den Wechsel anstößt, führt ihn nicht automatisch aus und trägt nicht automatisch seine lokalen Kosten.

Auch die umgekehrte Ausrede ist falsch. Ein Betreiber kann einen RFC nicht als „bloßes Dokument“ abtun und zugleich Konformität mit ihm behaupten. Die Norm definiert reales gemeinsames Verhalten für Systeme, die sich daran binden. Die Grenze beschränkt die Ausführungsgewalt, nicht den Sinn normativer Anforderungen.

HTTP/2 blieb h2

RFC 9113 enthält mehr als eine neue Nummer. Er übernimmt die zuvor in RFC 8740 beschriebene Behandlung von TLS 1.3, präzisiert Validierung, verändert Klartext-Upgrade und Priorisierung und klärt das Verhältnis von Host und :authority. Anhang B führt sachliche und redaktionelle Unterschiede auf.

Gleichzeitig bleibt die ALPN-Kennung h2. Die Register für Rahmentypen, Einstellungen und Fehlercodes bestehen fort. IANA aktualisiert Verweise auf das neue Dokument, erfindet aber keine zweite Identität für das überarbeitete HTTP/2. Gegenstellen handeln eine Fähigkeit auf dem Draht aus, keine RFC-Nummer.

Bestimmte Mechanismen werden enger behandelt. Das Feld HTTP2-Settings und das Upgrade-Token h2c werden als obsolet markiert. Das Prioritätsschema aus RFC 7540 ist abgekündigt. Dennoch verweist RFC 9113 für die alte Semantik auf RFC 7540.

Das ersetzte Dokument ist nicht mehr der allgemeine aktuelle Einstieg, bleibt aber zum Verständnis beobachtbarer Altlasten nützlich. Das Archiv bewahrt Erinnerung, der aktuelle RFC weist die Richtung, Maintainer und Betreiber bestimmen, wann diese Richtung die Produktion erreicht.

Eine Kontrollmatrix mit „RFC 9113 eingeführt“ beantwortet daher nicht, ob der Proxy den entfernten Pfad ablehnt, die Bibliothek alte Signale sendet, die Appliance aktualisiert ist oder ältere Clients einen Kompatibilitätszweig nutzen. Der RFC sagt, wonach zu suchen ist; er sieht den lokalen Zustand nicht.

TLS legt die Übergangszeit offen

RFC 8446 spezifiziert TLS 1.3 und macht RFC 5246 für TLS 1.2 obsolet. Trotzdem behandelt sein Kompatibilitätsanhang die Aushandlung mit älteren Servern und Clients, die schrittweise Einführung in gemischten Servergruppen und Fehler alter Middleboxes.

Die Autoren gingen nicht davon aus, dass der Dokumentenkopf die installierte Basis beseitigt. Sie schrieben eine neue Version, die ihr begegnen kann.

RFC 8996 trifft anschließend eine stärkere Entscheidung zu TLS 1.0 und 1.1. Er kündigt beide formell ab, verschiebt ihre Dokumente nach Historic und verlangt, dass Implementierungen sie nicht aushandeln. Dies ist eine klare Sicherheitsgrenze innerhalb einer Best Current Practice.

Selbst dort werden verbleibende Systeme anerkannt, die TLS 1.2 oder höher nicht unterstützen. Wer die Empfehlung anwendet, kann die Interoperabilität mit ihnen verlieren. Wer sie ignoriert, übernimmt Sicherheitsrisiko. Übergangsgeschwindigkeit muss beide Schäden, mögliche Ausgleichsmaßnahmen und das Aktualisierungsrisiko berücksichtigen.

Das ist keine unbefristete Erlaubnis für TLS 1.0. Es verteilt Verantwortung. Die IETF setzt die aktuelle Praxis. Der Systemeigentümer findet die Abhängigkeit, ersetzt oder isoliert sie, akzeptiert gegebenenfalls den Verbindungsabbruch und beweist, dass die alte Version nicht mehr ausgehandelt wird.

RFC 9325 enthält getrennte aktuelle Hinweise für TLS 1.2 und TLS 1.3 und verbietet den Rückfall auf abgekündigte frühere Versionen. RFC 9852 hebt die Mindestanforderung für neue TLS-verwendende Protokolle an. Gegenwärtige Praxis ist ein Geflecht aus Ablösung, Aktualisierung und Anwendungsbereich, nicht schlicht die höchste Zahl.

MUST NOT ist kein Dienst mit Root-Rechten

Ein großgeschriebenes normatives Schlüsselwort hat Gewicht. In seinem Geltungsbereich definiert MUST NOT, was eine konforme Implementierung nicht tun darf. Es schafft eine Grundlage für Tests, Beschaffung und Sicherheitsprüfung.

Es ist jedoch kein Prozess mit Administratorrechten auf allen Maschinen. Maintainer schreiben die Regel in Code. Anbieter liefern ein Artefakt. Betreiber laden und konfigurieren es. Gegenstellen müssen das Ergebnis verarbeiten. Prüfer testen den aktiven Zustand.

Normative Autorität beschreibt konformes Verhalten. Ausführungsautorität benötigt Kontrolle über Gerät, Wartungsfenster, Abhängigkeiten und Ausfallfolgen. Die Trennung ermöglicht Zurechnung.

Nach einem fehlgeschlagenen Wechsel sagt „der RFC verlangte es“ nicht, wer den Termin wählte oder die Ausnahme freigab. Bei einer weiter aktiven Alt-Funktion sagt „sie war obsolet“ nicht, ob Maintainer, Anbieter oder Betreiber untätig blieb. Jeder Übergang braucht Eigentümer und Beleg.

Installierte Basis: Beweis, nicht ewiges Veto

RFC 2026 sagt, eine neue Fassung eines Internet Standards ersetze üblicherweise die alte. In manchen Fällen könnten jedoch beide Standards bleiben, um den Anforderungen einer installierten Basis Rechnung zu tragen, sofern ihre Beziehung ausdrücklich beschrieben wird.

Das anerkennt, dass Interoperabilität zwischen wirklichen Systemen entsteht. Eine elegante Spezifikation, die vorhandene Gegenstellen ignoriert, kann ihre Koordinationsaufgabe verfehlen.

„Installierte Basis“ kann aber missbraucht werden. Eine nie gemessene Abhängigkeit wird kritisch genannt. Wenige alte Partner halten Angriffsfläche für alle offen. Eine temporäre Ausnahme verliert Eigentümer und Enddatum.

Die Beweislast muss sich verschieben. Anfangs zeigt die Stilllegungsseite, dass der Ersatz funktioniert und Fehlerbilder verstanden sind. Sobald unterstützte Versionen, Migrationserfahrung und Risikobelege vorliegen, muss die Ausnahme ihre Notwendigkeit, Isolation und Laufzeit erklären.

Inventar zeigt, wo eine Alt-Fähigkeit existieren könnte. Verhandlungstelemetrie zeigt, wo sie genutzt wird. Abschalttests zeigen, was bricht. Der geladene Stand zeigt, welcher Code Verkehr bedient. Der Dokumentenkopf kann diese Untersuchung auslösen, aber keine ihrer Antworten ersetzen.

Ein belastbarer Migrationsbeleg

Erstens braucht es die Linie: neuer RFC, alle Updates- und Obsoletes-Kanten, spätere BCPs und das konkret betroffene Verhalten. „RFC 9113 einführen“ ist zu grob, wenn nur ein Upgradepfad entfernt wird.

Zweitens den geladenen Zustand: tatsächliche Version, Build, Firmware und Konfiguration. Verfügbar, heruntergeladen oder freigegeben bedeutet nicht aktiv.

Drittens die Abhängigkeiten: Clients, Server, Zwischenstellen, eingebettete Systeme und externe Partner. Fehlt vollständige Sicht, werden Beobachtungszeitraum und Blindstelle genannt; Stille ist kein gemessener Nullwert.

Viertens Risiko und Befugnis: Warum wird entfernt, wer entscheidet, und stammt die Frist vom Betreiber, Kundenvertrag, Supportplan oder Regulierer? Der RFC kann die technische Begründung liefern, ohne den äußeren Zwang zu liefern.

Fünftens Test und Rückfall: erwarteter Fehler, Kohorten, Abbruchschwelle und erlaubte Rückfalldauer. Öffnet der Rückfall eine verwundbare Version, braucht er eine neue Risikofreigabe.

Sechstens Ausnahmeverwahrung: System, Eigentümer, kompensierende Kontrolle, Ablauf und neuer Prüftrigger. „Legacy erforderlich“ ohne Person und Uhr ist keine Ausnahme.

Am Ende steht der Stilllegungsnachweis: Das Verhalten wird nicht mehr ausgehandelt, Warnungen wurden nicht nur unterdrückt, und der Nachfolgepfad trägt den Dienst. Abschluss ist eine Aussage über Runtime.

Zwei bequeme Unwahrheiten

Die erste ist automatischer Abschluss. Ein neuer RFC erscheint, also verschwindet das alte Verhalten aus dem Risikobericht, bevor es vom Draht verschwindet. Beschaffung fragt nach Nummern, Prüfung nach Richtliniendokumenten, niemand nach Handshakes.

Die zweite ist ewige Freiwilligkeit. Weil der RFC die Maschine nicht selbst ändert, wird jede Migration unbegrenzt aufschiebbar. Normative Anforderungen werden zu Meinungen, Kompatibilität zu einer Ausnahme ohne Datum.

Verantwortliche Governance hält beide Beweisarten zusammen. Die RFC-Beziehung belegt die aktuelle dokumentarische Grundlage. Das laufende System belegt die Einführung. Dazwischen liegt ein zurechenbarer, begrenzter und getesteter Entscheidungsweg.

Wenn „obsolet“ in einem Bericht steht, folgen vier Fragen: Welche Regel änderte sich? Welches alte Verhalten bleibt möglich? Wer kontrolliert die Systeme? Welche Messung beweist die Entfernung?

Der RFC Editor bewahrt die Geschichte. Die IETF beschreibt die aktuelle technische Linie. IANA pflegt Verweise. Entwickler liefern Code. Betreiber führen ein und prüfen. Äußere Stellen nennen ihre eigene Befugnis. Diese Aufteilung ist keine Zersplitterung, sondern die Beweiskette der Migration.

Obsoletes sagt, wo die heutige Lektüre beginnt. Es sagt nicht, dass der Code von gestern angehalten wurde.

Quellen