Summary

  • Der IANABIS-Entwurf vom 26. Oktober weist IANA an, in neuen Registern ohne Pflicht zu einem RFC aus dem IETF-Stream ein Feld für den Change Controller einzurichten. Dazu zählen First Come First Served, Expert Review, Specification Required und RFC Required. In einschlägigen alten Registern ohne Feld sollen später zunächst leere Felder erscheinen. Der Text ist weiterhin ein Internet-Draft.
  • RFC 8126 empfahl die Benennung der Änderungsinstanz bereits. Im bestehenden IANA-Register für JSONPath-Funktionserweiterungen ist Glyn Normington als Experte angegeben; die fünf Einträge nennen dagegen IETF als Change Controller.

Wenn der Eintrag älter ist als sein Verfasser

Die Vergabe eines Protokollwerts hat ein klares Verfahren. Schwierig wird es, wenn dieselbe Zeile später erneut angefasst werden muss. Eine Referenz ist veraltet, ein Kontakt wechselt, die Beschreibung soll präzisiert werden. Wer die erste Fassung geschrieben hat, kann längst weg sein. Wer heute E-Mails für das Projekt beantwortet, hat nicht automatisch das Recht zur Freigabe. Ein benannter technischer Experte kann die Qualität beurteilen; die Entscheidung über eine Änderung gehört möglicherweise einer anderen Stelle. Ohne sichtbare Trennung wandert Autorität still mit der Korrespondenz.

Der geltende RFC 8126 kennt diese Trennung. Für Register und Einträge aus RFCs des IETF-Streams liegt die Änderungskontrolle standardmäßig bei der IETF durch die IESG. Bei Registrierungen außerhalb dieses Streams empfiehlt er, den Verantwortlichen zu benennen. Neue Register mit First Come First Served oder Expert Review sollten ein entsprechendes Feld enthalten. Der Entwurf von 2026 verschiebt damit keine völlig neue Figur auf das Spielfeld. Er macht aus einer bestehenden Empfehlung eine konkretere Arbeitsanweisung an IANA.

IANABIS -04 nennt in Abschnitt 11.2 alle neuen Register mit Verfahren ohne IETF-Stream-RFC als Anwendungsbereich. First Come First Served und Expert Review stehen dort ebenso wie Specification Required und RFC Required. Abschnitt 2.5 verlangt für IETF-Stream-Einträge im Regelfall den Namen IETF statt IESG, weil Letztere für Erstere handelt. Quell-RFCs, die ausdrücklich IESG festlegen, sind Ausnahmen. Dieser Unterschied ist eine Aussage darüber, wem die Zuständigkeit gehört und welches Gremium sie ausübt.

Der Wert einer ehrlichen Leerstelle

Bei vorhandenen Registern ohne entsprechende Spalte verspricht der Entwurf, später leere Felder hinzuzufügen. Er erklärt weder jeden bisherigen Autor noch jeden Experten zum neuen Eigentümer der Einträge. Die Tabelle bekommt einen Platz für eine belegte Zuständigkeit. Solange er leer bleibt, sieht ein Bearbeiter die offene Frage. Eine Zahl betroffener Register und einen Zeitplan zum Ausfüllen liefert der Entwurf nicht. Eine Liste der betroffenen Tabellen und der jeweiligen Rechtsgrundlage würde die Aufgabe messbar machen.

Ein bestehendes IANA-Beispiel zeigt die ausgefüllte Variante. Die Function Extensions von JSONPath werden per Expert Review registriert; Glyn Normington ist als Experte aufgeführt. Für length, count, match, search und value steht in der Change-Controller-Spalte IETF. Die Namen stehen auf derselben öffentlichen Seite, bezeichnen aber unterschiedliche Funktionen. Diese Praxis existiert bereits und beweist keine Umsetzung des neuen Entwurfs.

Auch die Änderung eines Controller-Namens selbst muss geregelt sein. Abschnitt 3.1.2 des Entwurfs nimmt grundsätzlich das Registrierungsverfahren auch für Änderungen in Anspruch, soweit nichts anderes festgelegt ist. Bei Einträgen ohne RFC kann IANA Aktualisierungen von Kontakt- und Controller-Daten prüfen und genehmigen; Fachleute oder Area Directors können beraten. Die Spalte und der Weg zu ihrer Korrektur müssen zusammenpassen. Ein Türschild ist wenig wert, wenn jeder es nach Belieben austauschen kann.

Heute gilt die Anleitung des RFC 8126. IANABIS -04 bleibt ein Arbeitsgruppenentwurf. Erst ein verabschiedeter Text und nachweisbare Änderungen in IANA-Tabellen würden die vorgeschlagene Pflicht praktisch belegen.