Zusammenfassung

  • RFC 3536 unterschied codierte Oktette, abstrakte Zeichen, Schriftsysteme, Sprachen und die vom Renderer gewählten Glyphen; ein erfolgreicher Schritt belegt nicht automatisch den nächsten.
  • Das Glossar von 2003 war informativ, nicht normativ und ausdrücklich unvollständig; RFC 6365 löste es 2011 ab. Seine bleibende Lehre lautet: Eine plausible Form ist ein Darstellungsbeleg, kein Sprach- oder Bedeutungsbeweis.

Auf einem Flughafen erscheint ein Passagiername sauber auf dem Bildschirm. Keine Kästchen, keine sichtbaren Ersatzzeichen. Für den Betrieb wirkt die Textkette intakt. Dasselbe Bild könnte jedoch nach einem falschen Charset-Etikett, einer stillen Normalisierung oder einem Font-Fallback entstanden sein. Der Bildschirm bescheinigt eine gefundene Form. Er rekonstruiert nicht die Herkunft des Textes.

RFC 3536 erschien im Mai 2003 als Terminology Used in Internationalization in the IETF. Es war weder Zeichencodierung noch Konformitätsprofil, sondern ein Informational-Glossar für technische Debatten, in denen ähnliche Wörter verschiedene Ebenen bezeichneten. Die Autoren erklärten, die Definitionen seien nicht normativ, die Liste sei unvollständig und besonders beim Begriff „Sprache“ bestehe Uneinigkeit. Die eingefrorene Errata-Seite nennt keinen Eintrag; das macht die Terminologie nicht endgültig.

Die Leitung liefert Bits und Oktette. Ein Charset ordnet Oktette abstrakten Zeichen zu: RFC 3536 beschreibt es als Verbindung von codiertem Zeichensatz und Codierungsschema unter einem bei IANA registrierten Namen. UTF-8 nach RFC 3629 löst diese Decodierfrage. Sein Etikett sagt nicht, ob der Text Deutsch, Arabisch oder Japanisch ist, ob er grammatisch stimmt oder verstanden wurde.

Auch das Zeichen ist nicht seine Zeichnung. Es ist ein abstraktes Element mit Namen und Eigenschaften; die Glyphe ist eine gerenderte Form. Schriftart, Kontext und Formungsregeln bestimmen die Auswahl. Ein Zeichen kann mehrere Glyphen besitzen, verschiedene Sequenzen können gleich wirken. „Sieht richtig aus“ beschreibt den Ausgang und erlaubt keine eindeutige Rückrechnung auf die eingegangenen Oktette.

Schrift und Sprache stehen ebenfalls nicht eins zu eins zueinander. Ein Schriftsystem dient mehreren Sprachen, eine Sprache kann mehrere Schriften verwenden. Script-Erkennung hilft beim Formen, benennt aber keine Sprache. RFC 3066 und später RFC 5646 definieren Sprach-Tags als getrennte Metadaten. Selbst ein syntaktisch gültiger Tag kann geraten oder falsch sein und beweist weder idiomatische Qualität noch Verständnis.

RFC 2277 stellte den Menschen in den Mittelpunkt: Protokolle selbst sprechen keine natürliche Sprache, ihre Textketten werden aber von Menschen genutzt. Nicht-ASCII-Oktette zu akzeptieren ist daher nur der Anfang. Eingabe, Speicherung, Vergleich, Suche, Sortierung, visuelle, hörbare und taktile Ausgabe sowie tatsächliche Nutzbarkeit sind eigene Übergänge.

Normalisierung zeigt die Schwäche des Augenscheins. Unicode erlaubt verschiedene, kanonisch äquivalente Codepoint-Folgen. Unicode Standard Annex #15 definiert Normalformen; RFC 5198 ergänzte später ein Format für Netzaustausch. RFC 3536 verlangt vor allem, dass ein Protokoll den Ort der Normalisierung benennt. Entscheiden Eingang, Datenbank und Vergleich unabhängig, können gleich aussehende Ketten verschiedene Schlüssel sein oder unterschiedliche Datensätze ohne Spur verschmelzen.

Diese Grenze wiederholt nicht den vorhandenen Artikel zu RFC 5137. Dort geht es um Unicode-Escapes, normalisierte Bezeichner und Kontenverwechslung. Hier geht es um die allgemeinere Darstellungskette: Oktette werden Zeichen, erhalten Schrift- und Sprachkontext und werden als Glyphe gezeichnet. Bezeichnerregeln sind nur eine Anwendung davon.

Auch Kollation ist eine eigene Entscheidung. Die von Menschen erwartete Reihenfolge hängt von Sprache und Konvention ab und entspricht gewöhnlich nicht numerischer Codepoint-Sortierung. Gemeinschaften mit derselben Schrift können unterschiedliche Wörterbuchordnungen erwarten. Eine Datenbank kann fehlerfrei sortieren und dennoch den falschen Index liefern. „Sortierung beendet“ belegt nicht die sprachliche Angemessenheit.

Bidirektionaler Text trennt Speicher- und Anzeigeordnung. Ein Bildschirmfoto verrät nicht zwingend die Quellfolge; Cursor, Kopie oder Sprachausgabe können eine verborgene Struktur zeigen. Rendering ist bei RFC 3536 zudem visuell, hörbar oder taktil. Eine richtige Bildschirmglyphe kann mit falscher Aussprache oder unbrauchbarer Brailleausgabe zusammenfallen.

Der historische Rang muss präzise bleiben. RFC 3536 war nie Internet Standard. Im September 2011 erschien RFC 6365 nach IETF-Konsens und öffentlicher Prüfung als BCP 166 und erklärte RFC 3536 ausdrücklich für obsolet. RFC 7997 änderte später den Umgang mit Nicht-ASCII-Zeichen in RFCs. Diese Entwicklung macht die Definitionen von 2003 nicht rückwirkend normativ.

Im Sicherheitsabschnitt von RFC 3536 steht, Sicherheit werde nicht behandelt. Ein modernes Bedrohungsmodell darf dem Glossar nicht zugeschrieben werden. Heute lassen sich Risiken aus Codierung, Richtung und verwechselbarer Darstellung analysieren. Die sichere historische Aussage ist enger: Wer codierte Daten, abstrakten Text, Sprache und Ausgabe in einem Status zusammenlegt, verliert Prüfbarkeit.

Eine belastbare Beweiskette bewahrt Oktette und Charset, protokolliert Decodierung und Validierung, nennt Normalform und Ausführungsort, erhält Sprach-Tag und Herkunft, erkennt Schrift- und Richtungssegmente, zeichnet Shaping-Engine, gewünschten und tatsächlichen Font auf, prüft visuelle, hörbare und taktile Ausgabe, benennt die Kollation und testet mit der vorgesehenen Leserschaft. Die leuchtende Glyphe schließt nur einen Übergang.

Quellen