Zusammenfassung

  • Seit 31. August läuft ein IETF-weites Last Call zur Hochstufung von RFC 7405 und Aufnahme in STD 68. Stellungnahmen sind bis 28. September möglich; entschieden ist noch nichts.
  • RFC 7405 ergänzt %s für groß-/kleinschreibungssensitive und %i für ausdrücklich insensitive ABNF-Zeichenfolgen. Unmarkierte Literale behalten das alte insensitive Verhalten.
  • Der Antrag nennt 20 normative RFC-Verweise im zweiten Quartal 2026, HTTP/1.1, YANG, breite Werkzeugunterstützung und keine bekannten Interoperabilitätsprobleme.
  • RFC 6410 verlangt mindestens zwei unabhängige interoperierende Implementierungen, breite Verbreitung und erfolgreiche Betriebserfahrung. Der öffentliche Antrag ordnet seine Sammelindikatoren diesen Teilbehauptungen nicht anhand benannter Beispiele zu.
  • Ein schlanker Belegsatz kann diese Lücke schließen, ohne den abgeschafften formalen Interoperabilitätsbericht wieder einzuführen.

Der Text bleibt, sein Reifestatus soll wechseln

ABNF beschreibt die Syntax vieler Internetprotokolle und Datenformate. In RFC 5234, dem heutigen Inhalt von STD 68, ist ein Zeichenkettenliteral ohne Präfix standardmäßig nicht groß-/kleinschreibungssensitiv. Exakte Schreibweisen mussten Autoren früher als Folgen dezimaler oder hexadezimaler Zeichenwerte ausdrücken.

RFC 7405 ersetzt diese schwer lesbare Methode durch zwei Präfixe. %s"false" trifft nur exakt diese Schreibweise. %i"aBc" macht die Insensitivität ausdrücklich. Ohne Präfix bleibt die Rückwärtskompatibilität erhalten. Die Erweiterung ändert zwei Teile der Basisspezifikation und umfasst vier Seiten.

Das neue Verfahren ändert keine Normzeile. Nach RFC 6410 kann die IESG ein bestehendes Proposed Standard nach mindestens vier Wochen IETF-weitem Last Call neu einstufen. Die Bekanntmachung vom 31. August nennt einen individuellen Teilnehmer als Antragsteller, eine Entscheidung in den folgenden Wochen und den 28. September als Frist. Im eingefrorenen Datatracker stand der Vorgang noch auf AD Review.

Antrag, öffentliche Prüfung und wirksame Neueinstufung sind damit getrennte Zustände. Das Last Call ist keine vorweggenommene Zustimmung.

Für die Aufnahme in Spezifikationen gibt es gute Belege

Der Antrag zählte im zweiten Quartal 2026 zwanzig RFCs mit normativem Verweis. Die aktuelle Referenzseite zeigt Verwendungen in HTTP, YANG, E-Mail, Medien, CDDL, DNS und weiteren Bereichen sowie aktive Entwürfe. Sie weist zugleich darauf hin, dass Abhängigkeiten heuristisch erkannt werden.

RFC 7950 macht die Verwendung greifbar. Die Grammatik von YANG 1.1 kennzeichnet zahlreiche Schlüsselwörter wie module, container, leaf und rpc mit %s. Der Antrag nennt außerdem HTTP/1.1 und erklärt, ABNF-Werkzeuge hätten die Erweiterung inzwischen breit umgesetzt. Abweichende Interpretationen oder bekannte Interoperabilitätsprobleme seien nicht vorhanden.

RFC 9535 zeigt die noch bestehende redaktionelle Reibung. Sie schrieb 2024 die kleingeschriebenen JSON-Werte true, false und null weiterhin als Hexadezimalwerte. Daraus folgt weder Werkzeugversagen noch Ablehnung von RFC 7405. Es zeigt nur, dass selbst neue Texte noch auf die alte Ausdrucksform zurückgreifen.

Auch die übrigen Kriterien werden plausibel adressiert. Ein Erratum mit dem Vorschlag einfacher Anführungszeichen wurde abgelehnt. Ein interoperabilitätsbrechendes Erratum ist nicht bekannt. Die Funktion ist klein, erhöht nicht erheblich die ungenutzte Komplexität und setzt keine kontrollierte Technologie voraus.

Zitate, Implementierung und Betrieb sind verschiedene Belege

Das erste Kriterium von RFC 6410 enthält fünf Prüfungen: zwei Implementierungen, Unabhängigkeit, Interoperabilität, breite Verbreitung und erfolgreiche Betriebserfahrung. Der Antrag verdichtet sie zu Referenzzahl, prominenten Spezifikationen, Werkzeugaussage und fehlenden Problemberichten.

Im öffentlichen Text stehen keine zwei Implementierungsnamen und Versionen. Es gibt keine Erläuterung getrennter Codebasen, keinen gemeinsamen Grammatikkorpus, keine abgegrenzte Einsatzklasse, keinen Beobachtungszeitraum und kein Betriebsergebnis. Das ist keine Behauptung, solche Implementierungen oder Erfahrungen existierten nicht. Die Belege können über Repositorien, Maintainer, Mailinglisten und private Betriebe verteilt sein.

Ein normativer Verweis beweist eine Dokumentabhängigkeit. Werkzeugunterstützung beweist Fähigkeit. Einsatz beweist Nutzung, und erfolgreiche Erfahrung fügt Zeit und Ergebnis hinzu. Diese Ebenen unterstützen einander, sollten aber nicht durch ein einziges Wort „verbreitet“ ersetzt werden.

Kein Rückfall in Prüfungsbürokratie

RFC 6410 schaffte den zwingenden formalen Interoperabilitätsbericht bewusst ab. Verbreitung und Gebrauch können Interoperabilität hinreichend zeigen. Für ein zwölf Jahre altes, enges Grammatikmerkmal ein künstliches Laborereignis zu veranstalten, wäre leicht mehr Ritual als Erkenntnis.

Ein kurzer Nachweis genügt. Für wenigstens zwei Beispiele kann er Implementierung und Version, Unabhängigkeitsgrund, verwendetes RFC-7405-Konstrukt, Gegenstück oder gemeinsamen Korpus, Einsatzklasse, Beobachtungsfenster, Ergebnis, bekannte Grenzen und eine stabile Quelle nennen. Schutzbedürftige Betreiberinformationen müssen nicht veröffentlicht werden.

Die IESG behält das Urteil, warum die Beispiele zusammen breite Verbreitung und erfolgreiche Erfahrung darstellen. Wesentliche Last-Call-Einwände erhalten eine begründete Behandlung. Der Nachweis unterstützt Autorität, er ersetzt sie nicht.

Laufender Code braucht Herkunft

Heng Lus Running-Code-Prinzip ist hier eine Evidenzregel. Technische Aussagen sollen an realer Ausführung scheitern können. Bleiben Name, Version, Eingabe und Ergebnis unsichtbar, wird aber auch „laufender Code“ zu einer abstrakten Autoritätsformel.

Implementierer liefern Tatsachen, Referenzen zeigen textliche Aufnahme, Teilnehmer bringen Erfahrung und Widerspruch ein, die IESG entscheidet. RFC 7405 kann die Hochstufung verdienen. Ein zurechenbarer Pfad macht dieses Urteil belastbarer, nicht langsamer.

Quellen

  1. IETF — Last Call zur Hochstufung von RFC 7405
  2. IETF Datatracker — Statusänderungsantrag
  3. RFC 6410 — zwei Reifestufen
  4. RFC 7405 — sensitive Zeichenfolgen in ABNF
  5. IETF Datatracker — Verweise auf RFC 7405
  6. RFC 5234 — ABNF-Spezifikation
  7. RFC 7950 — YANG 1.1
  8. RFC 9535 — JSONPath
  9. RFC Editor — Errata zu RFC 7405
  10. Heng Lu — Running-Code Primacy