Zusammenfassung

  • ICANNs Bericht vom 24. August 2026 erfasst eine präzise Korrektur: U+A9B4 darf auf U+A9BA oder U+A9BB folgen, nicht auf U+A9BA oder U+A9BC wie im Entwurf.
  • Die fehlerhafte Kombination steht im Begleitvorschlag, in der HTML-Darstellung und im XML vom 23. April. Dort heißt die auf U+A9B4 angewandte Regel follows-A9BA-A9BC.
  • ICANN will die Änderung mit der javanischen Gemeinschaft beraten und danach in die Endfassung einarbeiten. Zum Stichtag führte die Veröffentlichungsseite noch die Fassung vom 25. Oktober 2024 und keinen endgültigen javanischen Eintrag.
  • Ein Referenz-LGR unterstützt Registry-Betreiber beim Entwurf von IDN-Tabellen und ICANN bei deren Prüfung; es ist nicht selbst die Tabelle eines Betreibers.
  • Ein versionierter Korrekturbeleg sollte Einreichung, Gemeinschaftsentscheidung, exakten Diff und Hashes der Enddateien verbinden, ohne nachgelagerte Übernahme zu unterstellen.

Drei Darstellungen tragen denselben Fehler

Das Verfahren lief vom 12. Mai bis 23. Juni. Es umfasste zwei neue Referenz-LGRs für Javanisch und UCAS sowie sechs Aktualisierungen. Von 33 einschlägigen Kommentaren unterstützten 32 das Paket. Ein Kommentar konzentrierte sich auf die Korrektur und eine Erläuterung zweier javanischer Regeln.

Arif Budiarto, Mitwirkender am Vorschlag, benennt die beabsichtigte Bedingung: U+A9B4, JAVANESE VOWEL SIGN TARUNG, kann nach U+A9BA, JAVANESE VOWEL SIGN TALING, oder U+A9BB, JAVANESE VOWEL SIGN DIRGA MURE, stehen. Der Entwurf nennt stattdessen U+A9BC, JAVANESE VOWEL SIGN PEPET. Die Änderung soll die vorhandene orthografische Absicht korrekt wiedergeben, nicht eine neue einführen.

Der Befund erreicht die normative Ebene. Auf Seite 38 des 40-seitigen Begleitdokuments steht A9BA/A9BC in Regel 4. Die HTML-Ansicht wiederholt die Bedingung. Im XML verweist U+A9B4 auf follows-A9BA-A9BC, dessen Klasse A9BA und A9BC enthält. Eine bloße Berichtigung im Fließtext würde deshalb nicht genügen.

Regel 3 legt allgemein fest, dass ein abhängiger Vokal auf einen Konsonanten, einen medialen Konsonanten oder einen unabhängigen Vokal folgen muss. Regel 4 schränkt U+A9B4 zusätzlich ein. Die Arbeitsgruppe kündigte an, Text, Regelverweise und Erläuterung in der Endfassung miteinander in Einklang zu bringen.

A9BC wird dadurch nicht allgemein aus dem javanischen Repertoire ausgeschlossen. Korrigiert wird nur seine Rolle als möglicher Vorgänger von U+A9B4 in dieser besonderen Bedingung.

Eine Disposition ist noch keine Enddatei

ICANN antwortet eindeutig: Die Aktualisierung wird mit der javanischen Gemeinschaft besprochen und anschließend in die endgültige Fassung eingearbeitet. Nach Auswertung der Kommentare und erforderlichen Änderungen sollen die finalen Referenz-LGRs auf der zentralen Seite erscheinen.

Diese Aussage widerlegt die Behauptung, der Hinweis sei ignoriert worden. Sie ersetzt aber kein korrigiertes XML. Bei der Prüfung am 1. September bezeichnete die Seite den 25. Oktober 2024 als aktuelle Version; in der Liste der skriptbasierten LGRs gab es keinen javanischen Datensatz. Die April-Dateien blieben das öffentlich zugängliche Konsultationspaket.

Acht Tage sind kein Beleg für eine unangemessene Verzögerung. Gemeinschaftliche Bestätigung, synchrone Änderungen an XML, HTML und Vorschlag sowie technische Validierung benötigen Zeit. Entscheidend ist die Zustandsbezeichnung: „Korrektur erfasst, Endfassung ausstehend“ hält Zusage und Datei auseinander.

ICANNs Richtlinien machen XML zum Prüfobjekt. Die Regeln werden nach RFC 7940 dargestellt; zu den Kontrollfragen gehört, ob die gewünschten Codepunkte und Regeln richtig charakterisiert sind. Die Zusammenfassung belegt den Beschlussweg, die versionierten Bytes dessen Umsetzung.

Referenz und Registry-Tabelle bleiben getrennt

Registry-Betreiber können Referenz-LGRs beim Entwurf ihrer Tabellen für internationalisierte Domainnamen verwenden. ICANN nutzt sie bei der Prüfung eingereichter gTLD-Tabellen. Das ist ein praktischer Steuerungspunkt, aber kein automatischer Konfigurationsdienst.

Referenzdatei, eingereichte Tabelle, Prüfergebnis und produktiver Stand gehören zu unterschiedlichen Akteuren. Keine geprüfte Quelle nennt eine Registry, die die April-Bedingung übernommen hat, eine abgelehnte Registrierung, einen ausgefallenen Domainnamen oder einen Sicherheitsvorfall. Ebenso wenig wird eine spätere Enddatei die Übernahme durch alle Betreiber beweisen.

Der fehlende Beleg ist überschaubar

Zuerst bindet er die Beobachtung: Datum und Hashes des April-Pakets, U+A9B4, betroffene Regel, A9BA/A9BC im Entwurf, Einreichung und gewünschtes A9BA/A9BB. Die Beziehung zwischen Regel 3 und Regel 4 gehört als Auslegungsgrenze dazu.

Danach folgt die Zuständigkeit: Einreichungszeit, Stand der Gemeinschaftsberatung, ICANN-Disposition und verantwortliche Funktion für die Freigabe. Wird die Regel umbenannt oder strukturell anders umgesetzt, muss der Beleg semantische Gleichheit statt bloßen Texttausch zeigen.

Für die Veröffentlichung gehören Version, Datum, URLs und Hashes von XML, HTML und Begleitdokument zusammen. Ein maschinenlesbarer Diff weist A9BC aus der besonderen Vorgängermenge hinaus und A9BB hinein. Konformitätsbeispiele zeigen erlaubte und nicht erlaubte Folgen. Der Entwurf bleibt als Historie erreichbar, erhält aber eine eindeutige Ablösemarke.

Nachgelagerte Registry-Schritte werden verlinkt, nicht angenommen: zitierte Referenzversion, ICANN-Prüfung und Betreiberübernahme. Fehlt ein Link, lautet der Zustand „öffentlich nicht belegt“.

Heng Lus Minimalprinzip begrenzt den gemeinsamen Datensatz auf Akteur, Artefakt, Regel, Zustand, Version, Datum und Revision. Lokale Implementierungsentscheidungen bleiben bei der verantwortlichen Stelle.

Grenzen der Aussage

Der Vorgang belegt keinen Fehler im laufenden DNS und keine Schädigung von Nutzern. Öffentliche Kommentierung soll Entwurfsfehler gerade vor der Finalisierung finden. Er belegt auch keine Ablehnung durch ICANN; der Bericht sagt die Einarbeitung ausdrücklich zu.

Die verbleibende Governance-Aufgabe ist daher nüchtern: Der Abschluss muss ebenso nachvollziehbar werden wie die Entdeckung.

Quellen

  1. ICANN — Zusammenfassender Bericht, 24. August 2026
  2. ICANN — Konsultation zu zusätzlichen Referenz-LGRs
  3. ICANN — Eingabe von Arif Budiarto
  4. ICANN — Paketübersicht vom 12. Mai
  5. ICANN — javanischer XML-Entwurf
  6. ICANN — javanischer HTML-Entwurf
  7. Javanisches Generation Panel — Begleitvorschlag
  8. ICANN — Second-Level Reference LGR
  9. ICANN — Entwicklungsrichtlinien
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption