Zusammenfassung

  • RFC 3987 gab Unicode-fähigen Internationalized Resource Identifiers (IRIs) einen definierten Platz neben URI-orientierter Software. Die Umwandlung hängt vom Bestandteil ab: Für einen Hostnamen in Form einer Domain kann IDNA nötig sein; Unicode in Pfad oder Abfrage wird dagegen mit UTF-8 und Prozentkodierung dargestellt.
  • RFC 3987 nennt Martin J. Dürst und Michel Suignard als Autoren; Dürsts Universitäts-CV bezeichnet ihn als Hauptautor der IRI-Spezifikation. Der Standard verbindet die Schriften der Nutzer mit älterer Software, registriert aber keinen Namen, belegt keine Kontrolle über eine Domain und beweist nicht, dass ähnlich aussehende Zeichenfolgen dieselbe Ressource bezeichnen.

Eine Schnittstelle ergänzen, statt die alte still zu ändern

Man stelle sich eine Webadresse mit japanischen Zeichen im Pfad und einem in einer anderen Schrift geschriebenen Hostnamen vor. Für einen Menschen ist das eine Adresse. Ein Client muss sie dennoch in Schema, Authority, Pfad, Abfrage und gegebenenfalls Fragment zerlegen. Danach gelten für die einzelnen Teile unterschiedliche Regeln. Die lesbare Form und die Form, die eine URI-only-Komponente erhält, können zusammengehören, ohne Zeichen für Zeichen übereinzustimmen.

Genau dafür gibt es Internationalized Resource Identifiers, kurz IRIs. RFC 3986 definiert die allgemeine Syntax von Uniform Resource Identifiers (URIs), deren Zeichenrepertoire auf einen Teil von US-ASCII begrenzt ist. RFC 3987 ergänzte im Januar 2005 einen Unicode-fähigen Partner, statt die ältere URI-Definition stillschweigend zu verändern. Die Autoren begründen die neue Protokollkomponente mit klarer Abgrenzung und dem Ziel, bestehende Software nicht inkompatibel zu machen. IRI-fähige Komponenten können die breitere Zeichenfolge behalten. Akzeptiert ein Abrufpfad nur URIs, muss das IRI in die zugehörige URI-Form überführt werden.

Das war kein Versprechen, dass plötzlich jeder alte Netzwerkbaustein jede Schrift versteht. Es ist ein Interoperabilitätsentwurf: Wo Software dazu in der Lage ist, bleibt die breitere Zeichenfolge erhalten; für den Übergang zu einer engeren Schnittstelle gibt es ein definiertes Verfahren. Das ist relevant, weil ein Bezeichner gespeichert, angezeigt, kopiert oder zum Abruf einer Ressource verwendet werden kann. Diese Vorgänge müssen weder in derselben Komponente noch gleichzeitig stattfinden.

Der Host ist eine Ausnahme innerhalb derselben Adresse

Die wichtigste Trennstelle liegt nach //, im Authority-Teil einer Webadresse. Ist der Host ein DNS-artiger Domainname, sieht die in RFC 3987 beschriebene Umwandlung von 2005 die IDNA-Operation ToASCII für jedes durch Punkte getrennte Label vor. Das Ergebnis ist eine ASCII-kompatible Form für Software aus der URI-Welt. Das RFC-Beispiel wandelt den Host résumé.example.org in xn--rsum-bpad.example.org um.

Das Beispiel zeigt zugleich, was Punycode leistet und was nicht. Es kodiert ein Domain-Label in eine ASCII-kompatible Form. Es wandelt weder die gesamte URL um noch ist es das Verfahren für jeden Nicht-ASCII-Bestandteil. Auch das Präfix xn-- ist kein Gütesiegel: RFC 5890 unterscheidet ein nach IDNA gültiges A-Label von einer Zeichenfolge, die nur so aussieht. Entscheidend ist die Protokollprüfung, nicht der Augenschein.

Auch die zeitliche Abfolge der Standards zählt. RFC 3987 verweist für die Hostumwandlung auf RFC 3490, das IDNA-Protokoll von 2003. Das spätere IDNA2008-Rahmenwerk, darunter RFC 5890 und RFC 5891, änderte Terminologie und Protokollregeln. RFC 5895 ist ein informatives Dokument über mögliche Eingabeabbildungen, die eine Anwendung vor der IDNA2008-Verarbeitung einsetzen kann. Es hält fest, dass eine sinnvolle Abbildung von Sprache, Anwendung und Eingabemethode abhängen kann. Das Beispiel aus RFC 3987 ist deshalb im historischen Kontext von 2005 zu lesen – nicht als Garantie, dass jeder heutige Browser dieselbe universelle Umwandlung vornimmt.

Ein Pfad ist kein Domain-Label

Stehen dieselben Unicode-Zeichen im Pfad, gilt ein anderes Verfahren. Ein Pfadabschnitt wie /研究 lässt sich über seine UTF-8-Oktette mit Prozentkodierung als /%E7%A0%94%E7%A9%B6 in einer URI darstellen. Punycode ist nicht das Pfadverfahren. Ein Pfad kann von Webserver, Anwendungsframework, Dateispeicher oder einem eigenen Router interpretiert werden; DNS löst nicht jedes Pfadsegment auf.

Abfrage und Fragment besitzen ebenfalls eigene Semantik. Prozentzeichen, Schrägstrich, Fragezeichen oder Raute können Trennzeichen statt gewöhnlicher Daten sein; daher kommt es auf Parsing und Reihenfolge der Escapes an. RFC 3987 behält die URI-Komponentensyntax bei und erweitert zugleich die Zeichen, die direkt in einem IRI stehen dürfen. Die Regel lautet also nicht: „Jedes Unicode-Zeichen durch eine ASCII-Schreibweise ersetzen.“ Schema und Komponente bestimmen die passende Operation.

Darum empfiehlt die Norm, die Umwandlung möglichst spät vorzunehmen – erst an der Komponente, die IRIs nicht verarbeiten kann. Eine zu frühe Konvertierung kann die lesbare Form beseitigen, bevor eine andere IRI-fähige Anwendung sie erhält. Normalisiert oder dekodiert ein Server in anderer Reihenfolge, können zwei Systeme unterschiedliche Pfade annehmen. Dürsts und Suignards Entwurf behandelt damit eine Nahtstelle zwischen Systemen, nicht bloß die Anzeige nichtlateinischer Schrift in der Adresszeile.

Eine gültige Kodierung registriert keinen Namen

IDNA beantwortet eine eng umrissene Frage: Lässt sich ein Label nach den einschlägigen Regeln darstellen und validieren? RFC 5891 trennt Registrierung und DNS-Abfrage. Die Verarbeitung durch Registrare, bevor eine Anfrage den Zonenverwalter erreicht, liegt außerhalb der IDNA-Protokolldefinition; Registry oder Zonenverwalter validieren die konkret zur Registrierung eingereichte Zeichenfolge. Ein syntaktisch gültiges A-Label belegt daher weder eine erfolgte Registrierung noch eine DNS-Delegation oder die Kontrolle durch den Dienst, den ein Leser erwartet.

Diese Unterscheidung geht leicht verloren, wenn ein vertrauter Unicode-Name in ein Dokument kopiert wird. Mindestens vier verschiedene Belege sind zu unterscheiden: die eingegebenen Zeichen, die von der Benutzerschnittstelle vorgenommene Abbildung, das an DNS übermittelte Host-Label und die Antwort des Webdienstes. Registrierungsdaten und Nachweise über die Kontrolle des Dienstes sind weitere Belege, nicht bloß andere Schreibweisen derselben Zeichenfolge. Eine erfolgreiche Umwandlung weist nichts davon nach.

Das ist auch ein Sicherheitsthema. RFC 3987 warnt vor Täuschung sowohl im Host- als auch im Pfadbestandteil: ähnlich aussehende Zeichen, abweichende Normalisierungserwartungen oder unterschiedliches Verhalten von Client und Server können scheinbar gleiche Adressen auf verschiedene Ressourcen lenken. Die Norm erklärt Unicode nicht für unsicher. Sie verlangt, dass ein System weiß, auf welche Komponente und Umwandlung es sich stützt. Die Anzeige belegt eine Darstellungsform, nicht die Identität.

Dürsts Beitrag – ohne die Erzählung vom Einzelgenie

Im RFC stehen M. Dürst und M. Suignard gemeinsam als Autoren. Dürsts offizieller Lebenslauf an der Aoyama Gakuin University bezeichnet ihn als Hauptautor der IRI-Spezifikation und verzeichnet frühere Arbeiten zu Web-Internationalisierung, Unicode-Einsatz und der Normalisierung zusammengesetzter Zeichen. Er leitete außerdem einen großen Teil der Zeit, in der RFC 3987 Gestalt annahm, die W3C Internationalization Activity. Die Universität führt ihn als Professor an ihrem College of Science and Engineering.

Das belegt einen wesentlichen Beitrag, aber keine alleinige Urheberschaft. Die Bedeutung zeigt sich in der Architekturentscheidung: URI-Software muss die Bedeutung neuer Zeichen nicht erraten; IRI-fähige Software erhält eine eigene Zeichendarstellung, und der notwendige Übergang wird festgelegt. Dürsts Arbeit war Teil einer breiteren Standardisierungsarbeit, und Suignard ist Mitautor des RFC.

Die Verbindung zu Heng Lus „Recht auf genaue Register“ ist bewusst eng begrenzt. Note 72 bezieht sich auf Regionale Internet-Registries und Internet-Nummernressourcen; sie ist weder DNS-Politik noch eine Regelung für Domainnamen. Als analytische Frage bleibt nur: Beschreibt ein Register tatsächlich den Zustand, den es zu beschreiben vorgibt? Unicode-Schreibweise, A-Label, DNS-Delegation und Ressourcenschlüssel eines Webdienstes sind zusammenhängende, aber unterschiedlichen Ebenen zugeordnete Einträge. Keiner kann alle anderen ersetzen.

Quellen