Zusammenfassung

  • RFC 2277 verlangte von IETF-Spezifikationen die Trennung von Protokollelementen und Text, eine Charset-Angabe, UTF-8-Fähigkeit und einen definierten Weg für Sprachinformation.
  • Diese Pflichten dokumentierten eine Standardsentscheidung. Sie belegten weder Unterstützung beim Empfänger noch ein angenommenes Aushandlungsergebnis, passende Locale-Regeln, korrekte Darstellung oder menschliches Verständnis.

RFC 2277 erschien im Januar 1998 als BCP 18. Das Dokument erfand keine neue Zeichenkodierung. Es beschrieb die Politik, die der IESG auf Protokolle im IETF-Standardsprozess anwandte. Die damalige IESG-Mitteilung fasste die Schwelle zusammen: Textprotokolle mussten UTF-8 verwenden können und Sprachkennzeichnungen transportieren; Abweichungen brauchten ein förmliches Verfahren und eine belastbare Begründung.

Adressat der normativen Wörter war die Spezifikation. Sie musste klären, welche scheinbaren Wörter maschinenlesbare Protokollzeichen und welche Texte für Menschen waren. Wenn eine andere Schicht die Internationalisierung übernehmen sollte, musste die Arbeitsgruppe sicherstellen, dass dort ein bewusster Verantwortlicher existierte. Für Namen war ebenfalls zu beschreiben, ob sie internationalisiert oder US-ASCII waren.

Damit entstand ein Prüfbeleg für das Design. Ein solcher Beleg macht Entscheidungen und Ausnahmen sichtbar. Er testet aber keine installierte Software und keinen Leser.

Unter charset verstand RFC 2277 Regeln, die eine Folge von Oktetten in eine Folge von Zeichen abbilden. Zeichendaten mussten ihren Charset erkennen lassen; Textprotokolle mussten UTF-8 ermöglichen. Bestehende Protokolle und Datenbestände durften andere Vorgaben benötigen, und zusätzliche Charsets sollten registrierte Namen verwenden.

Die Kennzeichnung bestimmt also die vorgesehene Dekodierregel. Sie beweist nicht, dass die Oktette gültig sind, der Empfänger die Regel implementiert oder die nötigen Glyphen besitzt. Ein formal korrektes, aber inhaltlich falsches Label kann sogar eine präzise falsche Dekodierung auslösen.

Auch der Auswahlweg blieb wichtig. Bei direkter Kommunikation kann ein HTTP-ähnlicher Austausch einen Charset aushandeln. E-Mail und gespeicherte Daten treffen ihren späteren Empfänger häufig nicht in einer Sitzung; dort bleibt eine klare Bindung von Label und Daten. Aushandlung belegt Angebot und Auswahl, ein gespeichertes Label eine Behauptung. Keines davon ist eine Quittung für erfolgreiche Darstellung.

Sprachinformation löste eine andere Aufgabe. Das Protokoll musste sie transportieren können, ohne dass jedes Element tatsächlich eine Angabe tragen musste. RFC 2277 empfahl damals RFC 1766 und trennte Sprache von der POSIX-Locale. Eine Locale kann Sortierung, Datum und Währung umfassen; der Empfänger darf den Vorschlag des Senders annehmen oder ignorieren.

Darum bescheinigt de keinem bestimmten Menschen Verständnis. Accept-Language in RFC 2068 drückte Präferenzen aus und warnte zugleich, dass Verständlichkeit von der einzelnen Person abhängt. Präfixvergleich bedeutete nicht, dass jede speziellere Variante verstanden wird. RFC 1766 begrenzte den Anspruch zusätzlich: Ein Sprach-Tag kann die richtige Charset-Darstellung nicht in allen Mischtexten entscheiden.

RFC 2277 empfahl einen Abschnitt „Internationalization Considerations“ neben den Sicherheitsbetrachtungen. Dort sollten Textflächen, Charsets, Sprache, Aushandlung und Schichtverantwortung zusammenkommen. Der Abschnitt ist ein Designbeleg für Prüfer und Implementierer. Er ist kein Beleg, dass Code, Übersetzungen und Betrieb den Vertrag später einhalten.

Das Dokument nannte selbst die Folge: Eine fremdsprachige Sicherheitswarnung kann falsches Verhalten auslösen, und Sprachfassungen können inkonsistent sein. Die historische Leistung bestand folglich nicht in einer Verständlichkeitsgarantie, sondern in einer Politik gegen unsichtbare Annahmen. Erklärung, Fähigkeit, Auswahl, Dekodierung, Darstellung und Verständnis blieben getrennte Nachweise.

Quellen und Grenzen

Die Quellen belegen die Politik von 1998, ihren Ursprung in RFC 2130, damalige MIME-, HTTP- und Sprachmechanismen sowie die formale UTF-8-Entwicklung. Sie messen keine heutige Verbreitung und keinen konkreten Nutzererfolg.