Zusammenfassung

  • Revision 10 von draft-ietf-mediaman-6838bis wurde am 9. September 2026 UTC verfügbar. Sie ist ein aktiver Entwurf der Media Type Maintenance Working Group, weder RFC noch abgeschlossene IANA-Änderung.
  • Revision 09 machte die Vorrangregel vom Erfolg einer Laufzeitauflösung abhängig. Die neue Fassung verlangt stattdessen statische Konsistenz mit tatsächlich definierten Suffixregeln; andernfalls entscheidet der konkrete Medientyp.
  • Der neue IANA-Abschnitt nennt dreizehn Suffixeinträge mit einer Drei-Fälle-Regel. Dieselben Einträge sagen, dass für das jeweilige Suffix keine Fragment-Syntax definiert ist, sodass die Fälle nicht eintreten können.
  • Eine spätere Genehmigung hätte dreizehn Ausführungsziele. Ich schlage ein Auffächerungsmanifest vor, das die endgültige Regel mit jedem Vorher-/Nachher-Eintrag verbindet. Das ist Daniel Kades redaktioneller Vorschlag, keine Draft-Vorgabe.

Der Entscheidungsweg hing von seinem eigenen Ergebnis ab

In Revision 09 sollte die Suffixregel gelten, wenn sie Fragmentverarbeitung definierte und das Fragment erfolgreich auflöste. Sonst griff die Regel des spezifischen Medientyps. Issue 93 benennt das Ordnungsproblem: Ob die Auflösung erfolgreich ist, erfährt ein Prozessor erst, nachdem er eine der Regeln gewählt und angewendet hat.

Revision 10 ersetzt den Versuch durch eine Spezifikationsbeziehung. Definiert ein Structured-Syntax-Suffix Fragment-Syntax und -Semantik, muss ein Medientyp damit vereinbar sein und darf verlangte Syntax nicht ausschließen. Fehlt eine Suffixdefinition, bestimmt der Medientyp die Behandlung. Der offizielle Versionsvergleich zeigt, dass nicht bloß die Formulierung, sondern das Auswahlmodell geändert wurde.

Danach zählt der Entwurf die betroffenen Registerzeilen auf: +json, +ber, +cbor, +der, +fastinfoset, +wbxml, +zip, +tlv, +json-seq, +sqlite3, +jwt, +gzip und +cbor-seq. Das Drei-Fälle-Muster stammt aus RFC 6839 und wurde weitergegeben. In allen dreizehn Zeilen steht jedoch auch, dass keine Fragment-Syntax für das Suffix definiert ist. Revision 10 fordert deshalb, nur diesen Falltext zu entfernen und den übrigen Inhalt zu erhalten.

Ein Merge ist noch keine Registermigration

Das IANA-Register trug bei der Prüfung den Stand 25. Juni 2026. Es umfasste 24 Einträge, verwendete Expert Review und nannte zwei Designated Experts. Jeder der dreizehn Zielblöcke enthielt die drei Fälle und die Aussage fehlender Syntax. Das ist ein zulässiger Vorher-Zustand: Der Arbeitsentwurf ist noch keine veröffentlichte Anweisung an IANA.

Die Verantwortungen sind verteilt. Media Type Maintenance entwickelt den möglichen Nachfolger von RFC 6838. IANA pflegt die öffentlichen Daten. Die Experten handeln nach der Registerrichtlinie und dem Rahmen aus RFC 8126. Die IESG verwaltet Experten für IETF-Register und wird einbezogen, soweit dies erforderlich ist. Der Merge von Pull Request 108 belegt die Textarbeit, nicht die Änderung der dreizehn IANA-Zeilen.

Auch die Prozessetiketten sind vorläufig. Im Entwurf steht als Ziel Best Current Practice; Datatracker zeigt gegenwärtig keinen vorgesehenen RFC-Status. In WG Last Call besteht seit Revision 06 vom Oktober 2025. Daraus folgen weder IESG-Genehmigung noch RFC-Veröffentlichung oder Registervollzug.

Ein gemeinsames Suffix macht Inhalte nicht gleich

Ein Structured Suffix signalisiert einem generischen Prozessor ein Grundformat. Es garantiert nicht, dass alle Namen mit +json, +zip oder +jwt dieselben Fragmentbedeutungen und Sicherheitsmerkmale haben. Revision 10 warnt ausdrücklich, dass sich die Beziehung zwischen einem suffigierten Typ und dem Namen ohne Suffix nicht aus den Zeichen allein ergibt.

Die Löschung repariert daher widersprüchliche gemeinsame Hinweise. Sie erfindet keine Fragment-Syntax, aktualisiert keine Implementierung und belegt weder Interoperabilität noch einen Sicherheitsvorfall. RFC 3986 liefert das allgemeine URI-Fragmentmodell, aber nicht die Semantik jedes Medientyps.

Der Entwurf würde außerdem RFC 9694 aufnehmen und bei Genehmigung RFC 6838 sowie RFC 9694 ablösen. Diese Konsolidierung ist kein Nachweis, dass die geplante Registerbereinigung bereits durchgeführt wurde.

Der Abschlussbeleg braucht dreizehn Zeilen

Ein minimales Manifest sollte das endgültige Dokument, seinen Abschnitt und Hash binden. Danach folgen die geschlossene Zielliste, stabile Identität und Vorher-Hash jedes Eintrags, die freigegebene Textklasse sowie ein Hash des zu erhaltenden Inhalts. Bei der Ausführung kommen IANA-Aktion und Zeitpunkt, tatsächlich genutzte Expert- oder IESG-Dispositionen, dreizehn Nachher-Hashes und ein Korrektur- oder Rückverweis hinzu.

Das schafft keine neue Genehmigungsinstanz, veröffentlicht keine geschützte Beratung und schreibt Anwendungen keine Fragmentsemantik vor. Es beweist nur, dass ein gemeinsamer Beschluss alle benannten Ziele erreichte, ohne Nachbarfelder zu verlieren.

Die Beschränkung folgt Heng Lus Minimum Initial Specification: Gemeinsam wird nur der kleinste Koordinationsnachweis; typspezifische Entscheidungen bleiben bei der zuständigen Spezifikation.

Beweisgrenze

Der Datatracker-Eintrag und seine Historie belegen Revision und Prozessstand. Der Merge-Commit belegt die redaktionelle Integration. Keiner dieser Nachweise sagt die spätere Standardisierung oder IANA-Ausführung voraus.

Quellen