Zusammenfassung

  • Die Veröffentlichung vom 5. Oktober ergänzt Referenzregeln für die javanische Schrift und die kanadische indigene Silbenschrift und aktualisiert sieben weitere LGRs. Varianten zwischen Schriftsystemen machen daraus ein zusammenhängendes Änderungspaket, nicht bloß zwei neue Einträge.
  • Die Regeln für die zweite Ebene unterstützen Registries bei Entwurf und Prüfung ihrer IDN-Tabellen. Die Zahl der erfassten Schriften belegt weder Delegierungen auf oberster Ebene noch allgemeine Softwarekompatibilität oder tatsächliche Verbreitung.

Analyse

Eine Sprachliste sieht schnell wie ein Katalog aus. ICANNs Veröffentlichung vom 5. Oktober lässt sich besser als Abhängigkeitskarte lesen.

ICANN hat Referenzregeln zur Label-Generierung (LGRs) auf der zweiten Ebene für die javanische Schrift und die kanadische indigene Silbenschrift (UCAS) veröffentlicht. Zugleich wurden sieben weitere Regelwerke aktualisiert: arabische Schrift, arabische Sprache, Inuktitut-Sprache, japanische Sprache, japanische Schrift, lateinische Schrift und der vollständige Variantenbestand der lateinischen Schrift. Laut ICANN decken die Referenzregeln nun 30 Schriften und 32 Sprachen ab.

Diese Zahlen beschreiben veröffentlichte Referenzmaterialien, nicht die Sprachen, die bei jedem Registrar, Browser, E-Mail-System und jeder Anwendung durchgängig funktionieren.

Die Änderungshinweise zeigen, warum die Zahl der Ergänzungen die operative Aufgabe nicht erfasst. Mit der neuen UCAS-Regel kamen zusätzliche schriftübergreifende Varianten in den Inuktitut-Regeln hinzu. Ein ergänztes lateinisches Zeichen für algonkinische Sprachen in Kanada führte außerdem zu Änderungen an Varianten im vollständigen lateinischen Variantenbestand. Die Regeln für japanische Sprache und Schrift wurden an Version 6 der Root-Zone-LGR angeglichen. Änderungen an der arabischen Schrift unterstützen die Pegon-Schreibweise in Indonesien.

Jeder Eintrag hängt damit mit anderen Regeln zusammen, die Registries und Prüfteams berücksichtigen müssen.

Das ist relevant, weil die Regeln in konkrete Prüfentscheidungen einfließen. ICANN beschreibt die Referenz-LGRs für die zweite Ebene als Hilfsmittel, mit denen Betreiber generischer Top-Level-Registries ihre Tabellen für Internationalisierte Domainnamen (IDN) entwerfen können. ICANN nutzt sie außerdem bei der Sicherheits- und Stabilitätsprüfung der von Registries eingereichten Tabellen. Eine solche Tabelle legt gemäß der jeweiligen Zonenpolitik fest, welche Labels akzeptiert werden und wie Varianten behandelt werden.

Eine Änderung an einer Referenzdatei kann deshalb weitere Teile der eigenen Tabelle oder des Prüfverfahrens betreffen, auch wenn sie im Titel der Ankündigung nicht genannt sind.

Das heißt weder, dass Registries die Oktober-Versionen bereits übernommen haben, noch, dass jede betroffene Tabelle auf dieselbe Weise geändert werden muss. Zuerst ist die Versionsfrage zu klären: Welche Referenzversion wurde verwendet? Was hat sich geändert? Welche Labels oder Variantenbeziehungen müssen erneut getestet werden? Wer nur die zwei neu hinzugekommenen Schriften verfolgt, könnte eine zugehörige Änderung in der eigenen IDN-Tabelle oder im Prüfablauf übersehen.

Auch die Ebenen müssen getrennt bleiben. Referenz-LGRs für die zweite Ebene betreffen IDN-Tabellen unter generischen Top-Level-Domains. Der Applicant Guidebook für die Runde 2026 verwendet Root-Zone-LGR Version 6, um Top-Level-Strings zu validieren und ihre Varianten zu berechnen. Beide Regelwerke sind über technische Abgleiche und Abhängigkeiten verbunden, beantworten aber verschiedene Fragen. Eine Referenzregel für die zweite Ebene genehmigt keine neue Top-Level-Domain, delegiert kein Label und gewährt dem Registranten kein Nutzungsrecht.

ICANNs Auswertung der öffentlichen Kommentierung nennt 33 einschlägige Beiträge: 32 unterstützten die vorgeschlagenen neuen und aktualisierten Regeln; ein Beitrag bezog sich auf einen Schreibfehler und eine Klarstellung zur javanischen Schrift. Das zeigt, welche Rückmeldungen ICANN erhielt. Es ist keine Abstimmung aller Registries, aller Nutzer dieser Schriften oder sämtlicher Sprachgemeinschaften. Auch die Aussage, die Regeln seien mit den Gemeinschaften entwickelt worden, muss in diesem Rahmen bleiben: Fachleute und betroffene Gruppen wurden einbezogen, doch die Zahl der Kommentare hat einen klar begrenzten Adressatenkreis und Zweck.

Die Veröffentlichung belegt ebenso wenig Universal Acceptance. Maschinenlesbare Label-Regeln helfen einer Registry zu prüfen, ob ein Label zu ihrer Tabelle passt und wie Varianten behandelt werden sollen. Sie sorgen nicht dafür, dass ein Webformular eine Adresse annimmt, E-Mail zugestellt wird oder eine Software den Namen korrekt speichert und anzeigt. ICANN lässt weitere Sprachen und Schriften zu, sobald relevante Beiträge aus den Gemeinschaften vorliegen. Die Zahl veröffentlichter Referenzen ist eine Grundlage für technische Prüfungen, keine Nutzungskennzahl.

Für Registries heißt das praktisch: die Veröffentlichung als Änderungssatz verwalten. Die neue Version mit der bisher eingesetzten vergleichen, jede Änderung der eigenen IDN-Tabelle zuordnen, betroffene Labels und Variantenbeziehungen testen und Richtlinien- sowie Einführungstermine mit Registry-Dienstleistern abstimmen. Schriftübergreifende Beziehungen verdienen besondere Aufmerksamkeit, denn Nutzer und Registries verarbeiten Labels, keine voneinander losgelösten Codepoint-Listen.

Die entscheidende Frage lautet nicht nur, wie viele Schriften ICANN ergänzt hat. Es geht darum, ob das Regelwerk mit wachsender Abdeckung in sich konsistent bleibt. Die Veröffentlichung im Oktober zeigt, wie eine Ergänzung weiterwirkt: Eine neu berücksichtigte Schrift kann eine Neubewertung von Varianten einer anderen Sprache erfordern; ein weiteres Zeichen kann den vollständigen Variantenbestand verändern. Der Katalog ist daher zugleich eine Wartungsfläche.