Zusammenfassung

  • RFC 1766 machte die Teile eines Sprach-Tags sichtbar, wies Anwendungen aber an, den vollständigen Wert als ein Token zu behandeln; Subtags dienten der Verwaltung, nicht als Menü.
  • ISO-Codes, IANA-Registrierungen und der private Namensraum belegten unterschiedliche Stellen der Syntax. Den Bezug des Tags zum Informationsobjekt sollte die Spezifikation des jeweiligen Kontexts festlegen.
  • Spätere Fassungen ergänzten ausdrücklich definierte Abgleichsoperationen. Sie machten nicht jeden Bindestrich der Grammatik von 1995 zu einem Navigationspfad.

Der Bindestrich sah wie ein Brotkrumenpfad aus

Im März 1995 stellte RFC 1766 eine kompakte Kennzeichnung für die Sprache eines Informationsobjekts vor. Die Form konnte an einen Baum erinnern: auf ein Haupt-Tag folgten optionale, mit Bindestrichen verbundene Teile. en-US wirkte vertraut; az-arabic und az-cyrillic hatten denselben Anfang. Der RFC zog dieser Lesart eine klare Grenze: Anwendungen sollten das vollständige Sprach-Tag als ein einzelnes Token behandeln. Die Aufteilung in Haupt-Tag und Subtags war ein Verwaltungsmechanismus, keine Navigationshilfe.

Das war wichtig, weil eine lesbare Zeichenfolge noch keine Hierarchie von Befehlen ist. Das Haupt-Tag durfte ein bis acht Buchstaben lang sein; für jedes Subtag galt dieselbe Grenze. Leerzeichen waren innerhalb des Tags unzulässig. Groß- und Kleinschreibung änderten den Wert nicht. Es gab Konventionen, Länderkennungen groß und Sprachkennungen klein zu schreiben, doch RFC 1766 erklärte, dass diese Schreibweisen selbst keine Bedeutung trugen.

Der Namensraum hatte feste Grenzen. Zweibuchstabige Haupt-Tags folgten ISO 639. i war für von IANA definierte Registrierungen reserviert; x kennzeichnete private Nutzung, deren Subtags IANA nicht registrieren würde. Andere Hauptwerte blieben einer Überarbeitung des Standards vorbehalten. Im ersten Subtag folgten zweibuchstabige Codes ISO 3166 alpha-2; Werte mit drei bis acht Buchstaben konnten bei IANA registriert werden. Auch spätere Subtags waren registrierbar.

Die Struktur erfüllte zwei Aufgaben, die leicht verwechselt werden: Sie machte die Zeichenfolge in Teilen lesbar und bot eine administrative Ordnung für den Namensraum. Sie verlangte jedoch nicht, die Teile wie Verzeichnisse zu durchlaufen. Ebenso wenig wies sie jedem Segment in allen Anwendungen dieselbe Bedeutung zu. Die Spezifikation des jeweiligen Einsatzkontexts sollte den Zusammenhang zwischen Tag und Informationsobjekt definieren.

Registrierung machte Werte öffentlich prüfbar

Die Beispiele in RFC 1766 umfassten eine Länderkennung (en-US), Dialekt oder Variante (no-nynorsk, en-cockney), eine von IANA registrierte Sprache (i-cherokee) und Schriftvarianten (az-arabic, az-cyrillic). Der Text fügte eine wichtige Einschränkung hinzu: Keines der gezeigten Subtags war tatsächlich zugewiesen. Die Beispiele erläuterten die Syntax; sie waren kein Verzeichnis verfügbarer Werte.

Wer einen Wert außerhalb der vorgegebenen ISO-Zuordnungen einführen wollte, füllte ein Formular aus, das Sprachname, Eigenname, eine veröffentlichte Beschreibung und weitere Angaben verlangte. Der Antrag wurde zwei Wochen lang auf einer offenen Mailingliste geprüft. Ein vom IETF Applications Area Director ernannter Prüfer konnte ihn an IANA weiterleiten oder nach erheblichen Einwänden ablehnen; gegen die Entscheidung ließ sich beim IESG Einspruch einlegen. Eine gemeinsame Schreibweise wurde durch einen öffentlichen Eintrag überprüfbar, nicht allein dadurch, dass jemand nach einem Bindestrich ein weiteres Suffix anfügte.

Auch der Zweck des Verfahrens war begrenzt: Es registrierte Kennungen und Verweise, keine universelle Benutzeroberfläche. Ein Tag sagte einem Protokoll nicht von selbst, ob es eine Darstellung auswählen, eine Bibliothek filtern, eine Route öffnen oder ein Sprachmenü anzeigen sollte. Dieses Verhalten gehörte zum jeweiligen Einsatzkontext.

Ein Header konnte Sprachen aufzählen, aber keinen Auswahlmechanismus festlegen

RFC 1766 definierte außerdem Content-Language, das mehrere vollständige Tags auflisten konnte. Für MIME multipart/alternative führte der RFC den Parameter Differences ein, mit dem sich kennzeichnen ließ, dass sich die Alternativen in der Inhaltssprache unterschieden. Der Text erläuterte, warum ein Reader diese Information nutzen könnte, ließ den Auswahlmechanismus für den anzuzeigenden Teil aber ausdrücklich außerhalb seines Umfangs.

So blieben drei Fragen getrennt: Welche Zeichenfolge identifiziert die Sprache eines Objekts, welches Protokollelement transportiert sie, und was tut die empfangende Anwendung damit? Ein Tag konnte in einem Content-Header stehen; ein Container konnte auf sprachliche Alternativen hinweisen; der Reader brauchte dennoch sein eigenes Auswahlverhalten. Der RFC lieferte eine gemeinsame Kennzeichnung und einen Ort für ihre Übertragung, aber keine universelle Navigation.

Die späteren Dokumente schärfen diese Unterscheidung. RFC 3066 von 2001 erlaubte Ziffern in Subtags und führte language-range ein. Ein Bereich konnte einem vollständigen Tag oder einem Präfix entsprechen, das an einer Bindestrichgrenze endete. Das war eine definierte Abgleichsoperation. RFC 3282 legte anschließend die Header Content-Language und Accept-Language fest, einschließlich bevorzugter Sprachbereiche und optionaler Qualitätswerte. Diese Ergänzungen schufen ausdrückliche Protokollregeln rund um Tags; sie machten den ursprünglichen Bindestrich nicht zu einem allgemeinen Pfad.

RFC 4646 von 2006 und RFC 5646 von 2009 führten die Überarbeitung von BCP 47 fort. Diese Folge zeigt, dass sich Grammatik und Register weiterentwickelten. Sie belegt weder, dass jeder Client jeden Wert richtig verarbeitete, noch dass ein Tag automatisch eine Seite, Übersetzung oder Darstellung auswählte. Die historische Aussage von RFC 1766 ist enger: Ein strukturierter Bezeichner kann für die Anwendung ein unteilbarer Wert bleiben, während seine Segmente Verwaltungskonventionen dienen.

Quellen und Grenzen

Die zentrale Spezifikation ist RFC 1766. Die begrenzte Revisionsfolge ist in RFC 3066, RFC 3282, RFC 4646 und RFC 5646 dokumentiert. Die Texte belegen Grammatik, Registrierungen und spätere Protokolländerungen, aber keine universelle Implementierung oder Verbreitung.