Zusammenfassung
- RFC 3454 schrieb die Reihenfolge Abbilden, Normalisieren, Verbieten und Bidi-Prüfen vor; jedes nutzende Protokoll musste dennoch ein vollständiges Profil festlegen.
- Gleiche Ausgabe bedeutete nur Gleichheit unter diesem Profil und dieser Unicode-Version, nicht gleiche Schreibweise, Darstellung, Absicht, Kontokontrolle, Berechtigung oder Person.
Vergleich war noch keine Identifizierung
Unicode öffnete Protokolle weit über ASCII hinaus, doch gleiche wahrgenommene Texte konnten aus anderen Codepunktfolgen, Kompatibilitätszeichen, Groß-/Kleinschreibung oder unsichtbaren Marken bestehen. Der im Dezember 2002 veröffentlichte RFC 3454 definierte stringprep zur Vorbereitung vor Speicherung oder Vergleich.
Das Ziel blieb vorsichtig: Zwei Menschen, die ihrer Ansicht nach dasselbe eingaben, sollten möglichst dieselbe Ausgabe erhalten. Nicht jede alternative Schreibweise aller Sprachen konnte erfasst werden. Klartext, RFC-Editor-Eintrag, Datatracker, Historie, Referenzen, spätere Zitationen und Errata belegen die Norm, nicht Nutzerabsicht oder Kontoeigentum.
Das Profil trug die tatsächliche Politik
Stringprep war keine alleinstehende Regel. Das nutzende Protokoll musste Anwendung, Repertoire, Abbildungstabellen, Normalisierung, verbotene Ausgabe, Bidi-Test und Zusätze benennen. Verschiedene Profile durften dieselbe Eingabe verschieden behandeln.
Abbildung konnte Zeichen entfernen, ersetzen oder vervielfachen; neu erzeugte Zeichen wurden in derselben Stufe nicht erneut geprüft. Wählte ein Profil Normalisierung, war NFKC aus Unicode Standard Annex #15 vorgeschrieben. Mehr Formen konvergierten, ohne in jeder Schriftart gleich auszusehen oder in jeder Sprache dasselbe zu bedeuten.
Die Reihenfolge war Teil des Vertrags
Abbilden, Normalisieren, Verbieten, Bidi-Prüfen musste genau so ablaufen. Die Verbotsstufe lieferte Zeichenfolge oder Fehler, nie beides. Steuerzeichen, private Nutzung, Nichtzeichen, Surrogate und Markierungen konnten ausgeschlossen werden. Bidi stabilisierte Grenzen rechtsläufiger Schrift, authentisierte aber den Eingebenden nicht.
Unicode Technical Report #36 vertiefte später visuelle Verwechslungen. Korrekte Normalisierung beseitigt nicht alle Doppelgänger; gleiche Ausgabe beweist keinen gemeinsamen Eigentümer.
Die Version gehörte zum Beleg
RFC 3454 band Tabellen an Unicode 3.2 und verweigerte automatische Anwendung auf spätere Versionen. So blieb das Ergebnis reproduzierbar, doch „gültig“ war ohne Profil und Version unvollständig.
Nicht zugewiesene Codepunkte zeigten das Problem. Gespeicherte Zeichenfolgen durften sie nicht enthalten, weil spätere Zuweisung Eigenschaften ändern konnte; Abfragen durften sie toleranter behandeln, damit neue Clients alte Speicher durchsuchen konnten. Eine Eingabe konnte beim Anlegen scheitern und beim Suchen durchgehen. Die Operation gehörte zum Urteil.
Wer nur das Endergebnis speicherte, verlor Eingabe, Tabellen, Transformationen und die Unterscheidung zwischen Speichern und Abfragen. Nach einem Update ließ sich Nutzeränderung nicht mehr von Softwareänderung trennen.
Nameprep zeigte Nutzen und Aktualisierungsschuld
RFC 3491 machte Nameprep zum Profil des ursprünglichen IDNA, RFC 3490 band es ein. RFC 4690 dokumentierte spätere Schwierigkeiten; das IDNA2008-Vokabular in RFC 5890 verzichtete auf stringprep.
Vergleich blieb nötig, aber das versionsgebundene System alterte. RFC 6885 formulierte PRECIS, RFC 7564 ersetzte RFC 3454, RFC 8264 ersetzte den ersten PRECIS-Rahmen. Das belegt Reparatur, nicht die plötzliche Bedeutungsänderung aller vorhandenen Kennungen.
Heng Lus Realitätsschichten trennen Eingabe, Profil, Tabellen, Stufen, Ausgabe oder Fehler, Vergleich, Kontobindung und Berechtigung. Der Vorrang laufenden Codes lässt das Programm seine Rechnung beweisen, nicht einen Eigentümer ernennen. Die minimale Anfangsspezifikation erklärt, warum Identität und Macht beim nutzenden Protokoll blieben. Das ist eine spätere redaktionelle Lesart.
RFC 3454 machte Normalisierung innerhalb einer genannten Grenze stark. Deterministischer Vergleich blieb etwas anderes als Identität.
Quellen
- RFC 3454
- RFC-3454-Text
- RFC-Editor-Eintrag
- IETF Datatracker
- Dokumenthistorie
- Referenzen
- Zitiert von
- Errata
- RFC 7564
- RFC 8264
- RFC 6885
- RFC 4690
- RFC 3490
- RFC 3491
- RFC 5890
- Unicode Standard Annex #15
- Unicode Technical Report #36
- Heng Lu — Realitätsschichten
- Heng Lu — Vorrang laufenden Codes
- Heng Lu — minimale Anfangsspezifikation
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
