Zusammenfassung

  • RFC 3490 beließ DNS bei ASCII und setzte IDNA in die Anwendung. ToASCII durfte ein Label zurückweisen; ToUnicode meldete nie einen Fehler, sondern gab bei einem fehlgeschlagenen Schritt die ursprüngliche Eingabe zurück.
  • Eine angezeigte Zeichenfolge belegte daher weder Gültigkeit noch Registrierung, Zoneneintrag, Auflösung, DNSSEC-Authentisierung oder Kontrolle. Für jede Stufe war ein eigener Nachweis nötig.

„ToUnicode never fails“ klingt wie eine Garantie, dass jeder Name verstanden wird. Im Algorithmus von RFC 3490 bedeutete es etwas Bescheideneres. Die Funktion lieferte immer eine Unicode-Folge. Misslang Vorbereitung, Dekodierung oder Rückprüfung, brach sie nicht mit einem Fehler ab, sondern gab die Eingabe unverändert zurück. Die Oberfläche hatte weiterhin etwas zu zeigen. Der Name war damit nicht für gültig erklärt.

Diese Trennung folgte aus der Architektur von 2003. IDNA änderte weder DNS-Server noch Resolver oder das Protokoll auf der Leitung. Die Verarbeitung saß vollständig in der Anwendung, als schmale Zwischenschicht zwischen einer Unicode-Oberfläche und einer ASCII-Infrastruktur. Internationalisierung verlangte so keine gleichzeitige Erneuerung des weltweiten Namenssystems.

Die Spezifikation begrenzte ihren Geltungsbereich mit dem „domain name slot“: etwa QNAME, das Argument einer Resolver-Funktion, der Domainteil einer Mailadresse oder der Hostteil eines URI. Ein Name in gewöhnlichem Text war nicht allein durch sein Aussehen ein solcher Slot. Verwendung und Kontext bestimmten die Regeln.

Auf dem Weg zum DNS musste ToASCII ablehnen können. Es arbeitete labelweise. Nicht-ASCII-Eingaben durchliefen Nameprep; optional galten die alten Buchstaben-Ziffern-Bindestrich-Regeln; eine Nicht-ASCII-Folge mit reserviertem Präfix wurde abgewiesen; anschließend folgten Punycode, xn-- und die Prüfung auf eine Länge von einem bis 63 Codepunkten. Scheiterte ein Schritt, scheiterte die Operation. Scheiterte ein Label, durfte der gesamte Name nicht als IDN verwendet werden.

Auf dem Weg zur Anzeige hatte ToUnicode einen anderen Auftrag. Es prüfte und entfernte das ACE-Präfix, dekodierte Punycode und schickte das Ergebnis erneut durch ToASCII. Nur wenn die neu erzeugte ASCII-Form ohne Beachtung der ASCII-Großschreibung mit der gespeicherten Eingabe übereinstimmte, wurde die dekodierte Unicode-Form ausgegeben. Die Rundreise bewies die Äquivalenz beider Darstellungen.

Misslang diese Probe, wurde das Zwischenergebnis nicht aus Bequemlichkeit zum gültigen Namen. Die Originaleingabe kam zurück. RFC 3490 erklärte ausdrücklich: Blieb nach ToUnicode das ACE-Präfix stehen, war das Label kein gültiges ACE-Label und zu keiner erzeugten Unicode-Zwischenfolge äquivalent. Eine Rückgabe war ein Beleg für kontinuierliche Anzeige, nicht für Annahme.

Daraus ergibt sich eine Beweiskette. Eine Zeichenfolge kann darstellbar sein, ohne ToASCII zu bestehen. Ein bestandenes ToASCII verpflichtet keine Registry zur Zulassung. Zulassung ist noch kein Zoneneintrag. Eine DNS-Antwort kann von einem Wildcard stammen. DNSSEC authentisiert Daten unter dem signierten ASCII-Namen, nicht die Unicode-Darstellung und nicht deren menschliche Deutung. Auflösung belegt weder Eigentum noch erwartete Identität.

RFC 3490 beanspruchte auch keine vollständige Sprachregelung. DNS blieb exakter Abgleich. Ähnlich aussehende Zeichen, alternative Schreibweisen, vereinfachtes und traditionelles Chinesisch oder sprachspezifische Gleichsetzungen wurden nicht automatisch eins. Zonenbetreiber durften strengere Regeln festlegen. Die Kodierung schuf Interoperabilität, keine weltweite Namensgerichtsbarkeit.

RFC 4690 dokumentierte später Konflikte um Verwechslungsgefahr, Registry-Politik, Unicode-Fortschreibung und Übergang. RFC 5890 und RFC 5891 ersetzten 2010 den alten Rahmen durch A-Label und U-Label und trennten Registrierung ausdrücklich von Lookup. Die Registrierung konnte exakte Übereinstimmung verlangen und Abweichungen ablehnen; der Lookup war großzügiger, behielt aber Prüfungen. Erfolgreicher Vergleich bedeutet nicht Gültigkeit, stellte RFC 5891 klar.

RFC 5895 behandelte benutzernahe Abbildungen als lokale Vorverarbeitung. Das entspricht Heng Lus Prinzip der minimalen Anfangsspezifikation: Die gemeinsame Ebene standardisiert nur das für Zusammenarbeit Nötige; Sprache, Darstellung und Zulassung bleiben dort, wo Kontext und Verantwortung liegen. Eine schlanke Koordinationsschicht muss nicht zur zentralen Sprachinstanz werden.

Der vollständige Mechanismus von RFC 3490 wurde abgelöst. Seine asymmetrische Fehlerlogik bleibt dennoch lehrreich. Eine Funktion, die stets etwas zurückgibt, ist für die Anzeige robust. Als Gültigkeitsorakel wäre sie gefährlich. ToUnicode lieferte Material für den Menschen; ToASCII konnte eine Darstellung für den alten Kanal zulassen. Registrierung, Existenz, Antwort, Authentisierung und Kontrolle blieben eigene Tatsachen.

Quellen