Zusammenfassung

  • RFC 3743 fasste ausgewählte chinesische, japanische und koreanische Zeichenvarianten zu einem administrativen Paket zusammen, das einem einzigen Inhaber zugeordnet wird.
  • Bevorzugte Varianten wurden normalerweise in der Zone aktiviert; andere Zeichenvarianten blieben meist reserviert, ohne zwingend als aktive DNS-Labels veröffentlicht zu werden. Das RFC belegt weder die Einführung einer Tabelle durch ein bestimmtes Registry noch eine erfolgreiche Namensauflösung.

Ein sichtbares Label, ein größerer Verwaltungsgegenstand

Eine Domainregistrierung wirkt oft wie ein Geschäft über genau eine Zeichenfolge: Ist sie frei, wird sie beantragt und kann anschließend in der Zone erscheinen. Internationalisierte Domainnamen machen diese Vorstellung unvollständig. In chinesischen, japanischen und koreanischen Schriften können unterschiedliche Codepunkte ähnlich aussehen, verwandte Bedeutungen tragen oder je nach Sprache und Region als Varianten gelten. DNS kann codierte Labels vergleichen; es entscheidet aber nicht selbst, ob zwei Unicode-Formen demselben Inhaber zugeordnet werden sollten.

Diese Verwaltungslücke adressierten die JET-Leitlinien in RFC 3743, einem im April 2004 veröffentlichten Informational-Dokument. Zu den Beteiligten gehörten Netzwerkinformationsgemeinschaften aus China, Taiwan, Korea und Japan. Die IESG-Notiz würdigte, dass JET eine politische Entscheidung mit einem Durchsetzungsmechanismus verband, stellte jedoch ebenso klar, dass die IETF keine Zonenpolitik vorschreibt. Dasselbe Tabellenformat kann unterschiedliche lokale Entscheidungen abbilden.

Das ist nicht die Umwandlung eines Unicode-Labels in eine ASCII-kompatible DNS-Darstellung. Frühere IDNA-Dokumente standardisierten Vorbereitung und Codierung. RFC 3743 behandelt die Verwaltung potenziell verwirrender Formen, nachdem eine Zone ein Label grundsätzlich akzeptiert hat. Ein technisches Profil kann die Gültigkeit einer Eingabe prüfen, aber nicht alle sprachlichen Gleichheitsurteile verschiedener Gemeinschaften treffen.

Eine Tabelle macht Sprachpolitik zum Registrierungsablauf

Für jede unterstützte Sprache kann eine Zone eine Language Variant Table (LVT) führen. Sie benennt gültige Codepunkte sowie bevorzugte Varianten und Zeichenvarianten. Diese Kategorien beschreiben unterschiedliche Verwaltung, keine allgemeine Rangfolge von Schriften und keine Garantie, dass jede generierte Zeichenfolge ein geläufiges Wort ergibt.

Bei einer Registrierung wird das vorgeschlagene Label zunächst mit Nameprep gemäß dem damaligen IDNA-Regelwerk verarbeitet. Danach prüft das Registry die Zeichen anhand jeder Sprache, die dem Antrag zugeordnet wurde. Es erzeugt Kombinationen bevorzugter Varianten und Zeichenvarianten, entfernt Duplikate und prüft Kandidaten gegen bereits registrierte und reservierte Labels. Eine Zone kann Kandidaten zusätzlich nach eigener Richtlinie filtern. Unicode selbst legt diese Ergebnisse nicht fest; maßgeblich sind Tabelle und lokales Verfahren.

Entscheidend ist die Trennung zwischen Aktivierung und Reservierung. Das ursprüngliche Label und normalerweise die zulässigen bevorzugten Varianten werden aktiviert und in die Zonendatei aufgenommen. Zeichenvarianten bleiben meist reserviert: Andere können sie nicht registrieren, doch sie werden nicht automatisch als aktive Labels im DNS veröffentlicht. RFC 3743 nennt die ursprüngliche IDL, die zugeordneten Sprachen, aktive Zonenvarianten und reservierte Varianten zusammen ein „IDL Package“.

Damit ändert sich die Verwaltungseinheit. Im traditionellen Modell werden Labels einzeln registriert, gelöscht oder übertragen. Das Paket ist hier atomar: Eine Übertragung oder Löschung der IDL betrifft auch die zugehörigen Varianten. So soll verhindert werden, dass unterschiedliche Inhaber Formen erwerben, welche die Zone als verwandt behandelt. Zugleich kann die Registrierung Strings umfassen, die nie im aktiven DNS erscheinen.

Die Beispiele des RFC zeigen, warum die Sprachzuordnung zählt. Ein Label kann mehrere Sprachentabellen bestehen und dabei verschiedene bevorzugte Formen erzeugen. Es kann auch ungültig sein, wenn ein Codepunkt in einer der ausgewählten Sprachen nicht zulässig ist. Das sind Beispiele für den Algorithmus, keine Belege dafür, dass ein bestimmtes Registry die Tabelle übernommen oder eine konkrete kommerzielle Domain nach diesem Modell registriert hat.

Was die Reservierung nicht belegt

RFC 3743 überlässt einer Zone wichtige Entscheidungen: Tabellen, Sprachen, Konfliktregeln, die zulässige Zahl erzeugter Varianten und die Aufgabenteilung zwischen Registrar und Registry. Einige Beispiele setzen „first come, first served“ voraus; eine Zone darf stattdessen ihre örtlichen Rechte- oder Streitregeln anwenden. Das RFC weist weder das rechtliche Eigentum an einem Namen nach noch die Aktivierung eines Pakets, die Aufnahme eines ASCII-Labels in eine Zone oder eine erfolgreiche DNS-Antwort.

Spätere IDNA2008-Dokumente helfen, die Ebenen zu trennen. Sie definieren technische Gültigkeits-, Registrierungs- und Lookup-Regeln und erkennen zugleich an, dass Registries zusätzliche lokale Beschränkungen setzen können. Daraus folgt nicht, dass die IDNA2003-Algorithmen von RFC 3743 heutige Protokollregeln wären oder dass JETs Tabelle zum universellen Sprachstandard geworden sei. Validierung, Registry-Politik, tatsächliche Registrierung, Zoneneintrag und Auflösung sind verschiedene Nachweise.

JETs historischer Beitrag war eine Verwaltungsarchitektur. Das Team versuchte nicht, jede CJK-Gleichheitsentscheidung in DNS einzubauen. Es gab Zonenbetreibern ein Mittel, lokale Variantenregeln auszudrücken und verwandte Formen einem Inhaber zuzuordnen. Das senkt ein Risiko aufgespaltener Inhaberschaft, schafft aber eine andere Abhängigkeit: Sprachentabelle und Lebenszyklusregeln werden Teil des erworbenen Gegenstands. Sichtbar ist ein Label; reserviert sein kann ein ganzes Paket.

Quellen