Zusammenfassung

  • RFC 7942 erlaubt in einem Internet-Draft einen optionalen Implementation-Status-Abschnitt mit Verantwortlichem, Implementierungsidentität, Reifegrad, Abdeckung, kompatiblen Entwurfsversionen, Lizenz, Erfahrung, Kontakt, Aktualisierungsdatum und Interoperabilitätstests.
  • Die Angaben stammen von Mitwirkenden, sind nicht durch die IETF geprüft, keine Empfehlung und kein vollständiger Katalog. Wegen ihrer Zeitabhängigkeit sollen Abschnitt und RFC-7942-Verweis vor Veröffentlichung als RFC entfernt werden.
  • Laufender Code kann eine noch veränderbare Spezifikation prüfen und verbessern. Er ersetzt keinen klaren Text und belegt nicht automatisch endgültige Konformität, Einsatz, Sicherheit oder Betriebserfolg.

Der temporäre Teil der Standardisierung

Ein Internet-Draft ist Werkstatt und öffentlicher Vorschlag zugleich. Ein RFC soll später als beständiger technischer Bezugspunkt dienen. Yaron Sheffer und Adrian Farrel haben in RFC 7942 ein Verfahren beschrieben, das Implementierungserfahrung in der Werkstatt sichtbar macht, ohne eine Momentaufnahme von Produkten in den dauerhaften Bezugspunkt einzubauen.

Das Dokument erschien im Juli 2016 als BCP 205. Es erklärt Implementierung nicht zur allgemeinen Voraussetzung für die RFC-Veröffentlichung. Es verweist darauf, dass Proposed Standards auch ohne Implementierung entstehen können, und lässt Arbeitsgruppen eigene Anforderungen setzen. Der Statusabschnitt ist freiwillig; seine Stärke kommt von prüfbaren Einzelheiten, nicht von Zwang.

Vor dem BCP stand ein Experiment. RFC 6982 hatte das Verfahren 2013 für 18 Monate vorgeschlagen. Die Erfolgskriterien fragten, ob Arbeitsgruppen bei konkurrierenden Lösungen informierter entschieden, ob Implementierungserfahrung Protokolle veränderte, ob mehr Interoperabilitätstests stattfanden und ob Nichtautoren durch Code oder Nutzung am Review teilnahmen. RFC 7942 löste das Experimental RFC später ab. Das Verfahren wurde damit selbst zeitlich begrenzt erprobt, bevor es verstetigt wurde.

Aus einem Namen wird erst durch Grenzen ein Nachweis

Der Abschnitt kann die verantwortliche Organisation, Implementierungsname oder Webseite, Beschreibung und Reifegrad enthalten. Hinzu kommen die abgedeckten Spezifikationsteile, kompatible Internet-Draft-Versionen, Lizenzbedingungen, Umsetzungserfahrung, Kontakt und Datum der letzten Aktualisierung. Testfälle und Interoperabilitätsberichte dürfen ergänzt werden.

Die Felder verhindern Bedeutungsinflation. Widely used ohne Datum ist keine aktuelle Messung. „Unterstützt das Protokoll“ ohne Feature-Matrix trennt Pflicht, Option und Fehlerpfad nicht. Ein Repository ohne Commit, Build und zugehörige Draft-Revision reproduziert den Testzustand nicht. Zwei Produktnamen können dieselbe Bibliothek teilen. Zwei Programme können im happy path übereinstimmen und bei Aushandlung oder Recovery auseinanderlaufen.

Der vorgeschlagene Einleitungstext macht die Herkunft offen: Die Aufnahme bedeutet keine IETF-Empfehlung; die IETF hat die von Mitwirkenden gelieferten Informationen nicht geprüft; die Liste ist kein Katalog aller Implementierungen und Funktionen; weitere Implementierungen können existieren. WG Chairs und Area Directors sollen außerdem verhindern, dass der Abschnitt als Marketingfläche dient.

Das ist kein Misstrauensvotum gegen Implementierer. Früher Code kann Fehler schneller aufdecken, Vergleichsvorschläge konkretisieren und Interoperabilität ermöglichen. Gerade weil die Sichtbarkeit Einfluss schafft, dürfen frühe Verfügbarkeit, organisatorische Unabhängigkeit und technische Richtigkeit nicht verwechselt werden. Ein nachvollziehbarer Nachweis braucht Identität, Version, Eigentumsbezug, Abdeckung, Test und Zeit.

Warum Löschen genauer sein kann als Bewahren

RFC 7942 nennt die Information zwangsläufig zeitabhängig und deshalb ungeeignet für das veröffentlichte RFC. Autoren sollen den RFC Editor anweisen, den gesamten Abschnitt und den Verweis auf RFC 7942 vor Veröffentlichung zu entfernen. Das Errata-Verfahren soll die verschwundene Momentaufnahme nicht weiterpflegen.

Ein stehengebliebener Prototypstatus könnte Jahre später wie aktueller Support aussehen. Eine geänderte Lizenz würde falsch dargestellt. Code für eine Zwischenrevision könnte als Umsetzung des endgültigen Texts gelten. Später entstandene Projekte fehlten dauerhaft. Der stabile RFC würde einem ungeprüften Markt- und Entwicklungsbild eine Autorität verleihen, die es während der Arbeitsgruppendiskussion nie hatte.

Wenn der Status nach Veröffentlichung wichtig bleibt, kann er laut BCP in einer getrennten offenen Ressource leben, etwa einem WG-Wiki. Implementierer können sie aktualisieren, die Liste kann wachsen und nach RFC-Veröffentlichung weitergeführt werden. Damit sie nützt, soll sie keine Anmeldung, Registrierung oder Zugriffskontrolle verlangen. Die technische Spezifikation bleibt stabil; der Implementierungsstand bleibt korrigierbar.

Running Code ist Evidenz, keine Hoheitsgewalt

RFC 3935 verankert IETF-Entscheidungen in technischem Urteil und realer Implementierungs- und Einsatzerfahrung. RFC 7282 erklärt rough consensus als Bearbeitung technischer Einwände statt Abstimmung und lässt tatsächliche Ingenieursprodukte theoretische Entwürfe herausfordern. Heng Lus Running-Code Primacy zieht die institutionelle Grenze: Eine Veröffentlichung ist kein Betriebszustand, und gemeinsame Regeln müssen sich an den minimalen Erfordernissen unabhängiger Systeme messen lassen.

RFC 7942 setzt diese Haltung um, ohne dem Code ein Vetorecht zu geben. Eine Implementierung kann eine Lesart verwirklichen, Unklarheiten aufdecken, Testpakete erzeugen und mit einem Peer kommunizieren. Der BCP sagt zugleich, Code dürfe nie eine klare Spezifikation ersetzen. Er schreibt auch nicht vor, wie stark eine Arbeitsgruppe Vorschläge mit Code bevorzugen muss.

Die Existenz eines Programms beweist weder Sicherheit noch Skalierung, Unabhängigkeit, Verbreitung oder Betriebsergebnis. Reife ist eine gemeldete Einstufung. Konformität ist versions- und abdeckungsgebunden. Interoperabilität ist peer- und testgebunden. Einsatz ist produkt-, konfigurations- und betreibergebunden. Jede Aussage hat einen anderen Kontrolleur.

Der Übergang zum RFC schließt die Beweiskette nicht

Ein belastbares Protokoll bewahrt zuerst Draft-Name und Revision. Es verbindet damit Quelle und Datum der Meldung, Code-Version oder Build, Lizenz, Feature-Abdeckung, Testfälle und Umgebung, Peer-Versionen, positive und negative Ergebnisse, die Verwendung durch die Arbeitsgruppe und später den beobachteten Einsatz.

Eine Implementierung von Revision 08 belegt Revision 12 nicht. Ein erfolgreicher Pflichtaustausch belegt optionale Funktionen nicht. Eine durch einen Prototyp ausgelöste Textänderung belegt nicht, dass derselbe Code dem finalen RFC folgt. Eine RFC-Nummer belegt kein Release, keine Aktivierung, keinen Verkehr und keinen erfolgreichen Dienst.

Das offizielle IETF-Datatracker-Profil verband am 1. September 2026 82 RFCs und mehrere damalige Rollen mit Adrian Farrels öffentlicher Identität. Das belegt Person, lange Mitarbeit und den Kontext eines Mitautors. Es überträgt ihm nicht die Prüfung aller Angaben. RFC 7942 verteilt die Zuständigkeit: Implementierer melden, Autoren strukturieren, Prozessverantwortliche begrenzen Werbung, die WG bewertet, der RFC Editor entfernt, Betreiber setzen ein.

Der verschwindende Abschnitt ist deshalb kein verlorenes Archiv. Er ist eine Zeitgrenze. Solange die Spezifikation formbar ist, soll Code sie verändern können. Danach gehört die veränderliche Implementierungswahrheit in ein datiertes, zurechenbares und korrigierbares Register.

Quellen