Zusammenfassung
- RFC 2130 unterschied den codierten Zeichensatz (CCS), das Zeichencodierungsschema (CES) und die Transfersyntax (TES) von Sprache, Locale, Kultur und Layout. Das erste Trio beschreibt gewöhnlich den Weg über die Leitung; die übrigen Fragen verschwinden dadurch nicht.
- Registrierte MIME-Bezeichnungen sowie ISO 10646 und UTF-8 als Empfehlungen für neue Protokolle sollten Klarheit schaffen, nicht alte Standards stillschweigend ersetzen. Der Bericht war Informational und belegt weder ein neues Leitungsprotokoll noch flächendeckende Einführung.
Der Befehl und die Fehlermeldung
Ein SMTP-Server verarbeitet MAIL FROM als Befehl. Eine Fehlermeldung über denselben Vorgang richtet sich an einen Menschen. Beide bestehen aus Zeichen, aber sie haben verschiedene Änderungsrechte. RFC 2130 warnte davor, die Protokollmechanik etwa durch einen übersetzten Befehl zu verändern. Die menschliche Mitteilung könnte dagegen über eine ausdrücklich definierte Erweiterung lokalisiert werden. Ein Parser, der die bisherige Grammatik erwartet, profitiert nicht davon, dass eine neue Zeichenfolge sprachlich freundlicher wirkt.
Der vom IAB veranstaltete Workshop fand am 29. Februar und 1. März 1996 statt; der Bericht erschien im April 1997. Er war eine Orientierung für die Internet-Gemeinschaft und kein Internet-Standard. In E-Mail, Verzeichnissen und im Web hatten sich verschiedene Techniken für internationale Texte entwickelt. Bevor man einen gemeinsamen Zeichensatz als Lösung ausrief, musste man klären, welcher Teil eines Textes von welchem Mechanismus bestimmt wird.
Zahlen, Oktette, Transfer
Ein CCS bildet abstrakte Zeichen auf Ganzzahlen ab. Ein CES bildet solche Werte auf Oktette ab. Eine TES verändert die codierten Daten für Anforderungen des Transportwegs. ISO 10646, UTF-8 und Base64 illustrieren die drei verschiedenen Aufgaben. Wer einen Fehler untersuchen will, muss wissen, ob ein falsches Zeichen gewählt, sein Wert falsch in Bytes umgesetzt oder eine Transferhülle falsch behandelt wurde. MIME benennt CCS und CES oft gemeinsam mit charset; Content-Transfer-Encoding bezeichnet die Transportumsetzung. Bereits registrierte MIME-Charsets deckten die konzeptionellen Schichten nicht immer sauber ab, weshalb der Bericht eine genauere Beschreibung künftiger Einträge verlangte.
Das Modell umfasst sieben Schichten. Zu den drei Übertragungsschichten kommen Sprache, Locale mit etwa Datums- und Währungsformen, kulturelle Präferenzen und Layout mit Schrift und Zeilenumbruch. Viele Fragen der Benutzeroberfläche blieben ausdrücklich außerhalb des Workshop-Auftrags. Dennoch konnte ein Sprachhinweis etwa für die Auswahl von Han-Glyphen und die Suche in mehrsprachigen Dokumenten wichtig sein. Korrekt decodierte Zeichen sind keine Garantie für eine geeignete Schrift oder eine verständliche Darstellung.
Wie erfährt der Empfänger überhaupt, welche Werte gelten? Eine Spezifikation kann sie festlegen, eine Hülle oder ein Datenstrom kann sie signalisieren, Parteien können sie zuvor vereinbaren oder im Protokoll aushandeln. Aus dem Herkunftsland eines Textes zu raten war unzuverlässig. Der Workshop empfahl registrierte MIME-Werte für Zeichensätze und Sprachen, sofern nicht ein bestehender, nicht auf Raten beruhender Mechanismus die nötigen Angaben liefert. Die richtige Bezeichnung muss zudem die tatsächlich gesendeten Bytes treffen.
Öffentliche und lokale Namen
Protokollbefehle, Kennungen und Inhalte wurden getrennt betrachtet. Unter Berufung auf RFC 1958 sollte ein weithin sichtbarer öffentlicher Name, etwa ein DNS-Name, in groß-/kleinschreibungsunabhängigem ASCII bleiben. Ein nur lokal benutzter Ordnername im Postfach lag anders. Wollte ein bisheriges ASCII-Protokoll UTF-8 nutzen, musste es Version oder Zeichensatz aushandeln und einen ASCII-kompatiblen Rückweg vorsehen. Inhalte wie E-Mail-Text, Datenbanken und HTML-Seiten brauchten dagegen Unterstützung verschiedener Zeichensätze und Anwendungsinformationen.
ISO 10646 als CCS und UTF-8 als CES waren sinnvolle Vorgaben für neue textorientierte Protokolle. Ein rückwärtskompatibles Protokoll konnte seinen bisherigen Standardwert behalten; ein Sieben-Bit-Transport erforderte womöglich eine besondere Transfersyntax. Für TES gab es keinen allgemeinen Standardwert. Andere Zeichensätze waren nicht verboten. RFC 2044 behandelt UTF-8-Bytes, RFC 2066 die Telnet-Aushandlung, RFC 2070 die HTML-Decodierung und RFC 2152 den Sieben-Bit-Mailtransport. Die eigenständige Frage von RFC 2130 ist, welche Behauptung jede dieser Entscheidungen tatsächlich trägt.
Quellen und Grenzen
- RFC 2130, Bericht des IAB-Zeichensatz-Workshops, besonders Abschnitte 0, 2, 3 und 8.
- RFC-Editor-Eintrag für Datum und Status.
- RFC 1958 für den im Bericht zitierten Grundsatz zu öffentlichen Namen.
Lu Hengs spätere Überlegungen zu tatsächlichem Betrieb und überprüfbarer Wirklichkeit dienen als redaktionelle Perspektive, nicht als Beweis für Absichten des Workshops. Die Quellen liefern keine Statistik zur Verbreitung oder zur Lesbarkeit in konkreten Anwendungen.
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

