Zusammenfassung

  • RFC 1556 verteilte bidirektionale Darstellung auf drei Modelle: Im visuellen Modus ordnete das Schreibprogramm vor, im impliziten Modus berechnete der Betrachter die Reihenfolge, im expliziten Modus steuerten eingebettete Kontrollfolgen das Ergebnis.
  • MIME konnte Nicht-ASCII-Zeichen erhalten, ohne damit die beabsichtigte Lesereihenfolge beim Empfänger zu beweisen. Zeichensatz, Richtungsmodus und Darstellungsumgebung brauchten getrennte Belege.
  • Das Dokument vom Dezember 1993 war Informational und kein Internet Standard. Spätere HTML-, Unicode- und UTF-8-Mail-Regeln zeigen das Fortbestehen der Grenze, aber weder eine direkte Abstammung noch die Verbreitung der vorgeschlagenen Suffixe.

Die Prüfsumme stimmte, die Nachbarschaft der Zeichen nicht

Bei einer historischen E-Mail kann die beste Transportprüfung vollständig richtig und dennoch unzureichend sein. Die gespeicherten Bytes stimmen mit dem Ausgangsmaterial überein. MIME wird fehlerfrei dekodiert. Jedes erwartete Zeichen ist vorhanden. Trotzdem steht der lateinische Produktname in einem Lesegerät links von der Zahl und in einem anderen rechts davon; beim Kopieren wechselt auch der Punkt seine sichtbare Seite.

Die Übertragung hat ihren Vertrag erfüllt. Der Streit beginnt danach. Eine Zeichenfolge muss noch in eine Zeile verwandelt werden. Dazu gehören Grundrichtung, gegenläufige Abschnitte, neutrale Satzzeichen, Zahlen und die Stelle des Zeilenumbruchs.

Hier setzte RFC 1556, Handling of Bi-directional Texts in MIME, an. Hank Nussbacher veröffentlichte das Memo im Dezember 1993. Der Eintrag beim RFC Editor und die IETF-Akte führen es als Informational; das Dokument selbst erklärt ausdrücklich, keinen Internetstandard festzulegen.

Sein Vorschlag war schmal: eine direction-Konvention für bidirektionale MIME-Texte. Seine eigentliche Erkenntnis war breiter. Die unveränderte Repräsentation lieferte noch keine eindeutige Präsentation.

MIME hatte zuerst den Transportvertrag erweitert

RFC 1521 löste den Nachrichtenkörper aus der Beschränkung auf flaches ASCII. Ein Bodypart konnte Medientyp und Charset benennen und seine Werte mit Base64 oder Quoted-Printable durch ältere Mail-Infrastruktur schützen. Der RFC-Editor-Eintrag hält die historische Rolle dieses ersten MIME-Teils fest.

RFC 1522 brachte Nicht-ASCII-Text in bestimmte Headerfelder. Ein Composer erzeugte ein encoded-word; ein kompatibler Reader erkannte es, machte die Kodierung rückgängig und zeigte die Zeichen im bezeichneten Charset. Der zugehörige Datensatz beschreibt den Vertrag für Header Extensions.

Charset und Transfer Encoding beantworteten zwei notwendige Fragen: Welche Zeichen sind gemeint, und wie überstehen ihre Werte den vorhandenen Kanal? Für eine Zeile mit arabischem ISO-8859-6 oder hebräischem ISO-8859-8 neben lateinischem Text blieb eine dritte Frage offen. Welche sichtbare Beziehung haben diese Zeichen zueinander?

RFC 1556 war deshalb kein Gegenbeweis zum Erfolg von MIME. Es markierte die Stelle, an der ein erfolgreicher Decoder noch kein erfolgreicher Leser war.

Das hebräische Begleitdokument legte die Vorentscheidung offen

Im selben Monat erschien RFC 1555 von Nussbacher und Yehavi Bourvine über hebräische Internet-Mail mit MIME und ISO-8859-8. Auch der Informationsdatensatz stuft es als Informational ein.

Der voreingestellte Richtungsmodus war visual. Hebräisch wurde von rechts nach links eingegeben, aber das Programm ordnete und kodierte es von links nach rechts; MIME übertrug diese visuelle Folge ebenfalls von links nach rechts. Das Lesegerät musste die Inhaltsrichtung nicht kennen. Es erhielt eine bereits für den Bildschirm vorbereitete Reihe.

Diese Kompatibilität verschob die Last zum Absender. Die gespeicherte Reihenfolge hing an der Erwartung, dass ein späteres Gerät nicht noch einmal ordnen würde. Liest eine moderne Engine diese Visual-Order-Folge als Logical Order und wendet einen impliziten Algorithmus an, sortiert sie ein zweites Mal.

RFC 1555 beschrieb zudem einen konkreten Kontextverlust. Bestimmte Listserv-Einstellungen versandten verkürzte Header; Archive konnten die MIME-Information ganz weglassen. Der kodierte Inhalt blieb im Datensatz, während seine Auslegungsanleitung verschwand.

Auch vollständig transparente 8-Bit-Mail sollte nach der damaligen Prognose nur die Transferkodierung teilweise überflüssig machen. Content-Type und Directionality blieben nötig. Ein breiterer Kanal bestimmte keine Leserichtung.

Visual: Die Entscheidung war vor dem Versand gefallen

RFC 1556 setzte visual als Standard und verwendete dafür den normalen ISO-8859-Namen ohne Suffix. Die Anzeige folgte einer einzigen primären Richtung von links nach rechts und behandelte den Inhalt wie unidirektionalen Text. Das Schreibprogramm musste die Zeichen so vorbereiten, dass die gewünschte Abbildung entstand. Am Ziel gab es weder Richtungskontrollen noch einen Ordnungsalgorithmus.

Das machte einen einfachen Empfänger möglich. Ein Terminal konnte Text zeigen, dessen sprachliche Struktur es nicht verstand. Diese Einfachheit war aber ein verteilter Vertrag: Der Composer erledigte die Arbeit, der Viewer durfte sie nicht erneut erledigen.

Die Folgekosten traten beim Bearbeiten auf. Cursorbewegung, Suche, Einfügen eines lateinischen Wortes, geänderte Fensterbreite oder Kopieren operierten auf einer für eine bestimmte Bildzeile gebauten Folge statt auf einer dauerhaft logischen Satzstruktur.

Visual bedeutete also nicht Richtungsfreiheit. Es legte die Verantwortung beim Autorensystem ab und machte Unwissenheit des Anzeigesystems zu einer Voraussetzung.

Implicit: Kontext wurde zu ausführbarem Eingang

Für implicit schlug RFC 1556 ISO-8859-6-i und ISO-8859-8-i vor. Ein Algorithmus bestimmte die Darstellung aus Zeichentypen, ihren Positionen relativ zu Nachbarn und einer primären Richtung. Wegen der Komplexität verwies das Memo für Einzelheiten auf ECMA TR/53.

Der Composer konnte eine logischere Folge erhalten, doch der Empfänger übernahm neue Pflichten. Er musste den Modus erkennen, kompatible Richtungseigenschaften verwenden und Grundrichtung sowie Absatzgrenzen kennen. Zahlen, Satzzeichen und neutrale Zeichen leiten ihr Verhalten zum Teil aus der Umgebung ab; auch ein Zeilenumbruch verändert die Verarbeitungseinheit.

Ein gemeinsamer Algorithmus macht das Ergebnis reproduzierbarer, aber nicht zu einer Eigenschaft des Payload-Hashes. Zwei Anzeigen können dieselbe dekodierte Folge erhalten und wegen Regelversion, Grundrichtung, Markup-Grenzen oder Umbruch unterschiedliche Visual Orders erzeugen.

Damit brauchte die Prüfung mehr als die Nachricht. Sie musste die Entscheidungsumgebung bewahren.

Explicit: Unsichtbare Anweisungen brauchten zwei Hüter

ISO-8859-6-e und ISO-8859-8-e bezeichneten explicit. Kontrollsequenzen lagen zwischen den Textzeichen und legten Richtungszustände fest. Der Absender konnte einen Kontext eröffnen oder ändern, statt nur auf eine Ableitung aus benachbarten Zeichen zu vertrauen.

Explizit hieß nicht selbstbewahrend. Ein Filter konnte unsichtbare Funktionen entfernen, ein Konverter sie als unbekannte Daten erhalten und ein Renderer ihren Geltungsbereich falsch behandeln. Ein Vergleich nur der sichtbaren Buchstaben konnte Gleichheit melden, obwohl die Ordnungsanweisung fehlte.

Nach RFC 1556 führte ECMA TR/53 drei neue Kontrollfunktionen ein und änderte 22 bestehende Funktionen von ECMA-48. Das war mehr als ein einzelnes Rechts-nach-links-Zeichen. Richtung berührte aktive Positionen, Bewegung und die Abbildung von Datenkomponente auf Präsentationskomponente.

Der Sender musste korrekte Kontrollen setzen; der Empfänger musste sie erhalten und als Zustandsmaschine ausführen. Beide Hälften gehörten zum Beleg.

ECMA trennte Datenposition und Bildposition

Das Gerätemodell von ECMA TR/53 empfing grafische Zeichen und Kontrollfunktionen und erzeugte daraus ein für Menschen lesbares Bild nach den jeweiligen Schreibkonventionen. Es unterschied eine Datenkomponente von einer Präsentationskomponente und konnte in beiden eine aktive Position führen.

Damit wird verständlich, warum ein Font das Problem nicht löst. Der Font zeichnet einen Glyphen. Das Präsentationsmodell entscheidet, neben welchem Glyphen er steht, wie der Cursor wandert und worauf Rückschritt oder Wagenrücklauf wirken.

RFC 1556 übersetzte diese Architektur in eine MIME-seitige Modusangabe. Der Empfänger musste wissen, ob er eine fertig arrangierte visuelle Reihe, eine noch implizit aufzulösende Folge oder einen explizit gesteuerten Strom erhielt. Ging diese Auswahl verloren, konnten richtige Daten in die falsche Darstellungsmaschine gelangen.

Vier Fehler ohne einen fehlenden Buchstaben

Erstens kann Metadatenverlust ISO-8859-8-i zu ISO-8859-8 normalisieren oder Content-Type aus einem Archiv entfernen. Die Zeichen bleiben, die Moduswahl verschwindet.

Zweitens kann eine Visual-Order-Folge in eine Engine für Logical Order gelangen. Der Composer hat bereits sortiert, die Engine sortiert noch einmal. Beide handeln lokal vertragsgemäß; zusammen erzeugen sie das falsche Bild.

Drittens kann eine Sicherheitsbereinigung explizite Kontrollzeichen entfernen. Ein Vergleich druckbarer Zeichen behauptet Gleichheit, obwohl der Zustandswechsel gelöscht wurde.

Viertens können implizite Renderer bei gleicher Folge durch andere Grundrichtung, Zeilengrenze, Stilgrenze oder Algorithmusrevision abweichen. Decoded Sequence und Visual Sequence sind zwei Befunde.

Zahlen, Interpunktion und Identifikatoren machen die Folgen praktisch. Ein Zeichen kann neben dem falschen Betrag stehen. Eine Kennung kann plausibel aussehen und in anderer logischer Reihenfolge kopiert werden. Vollständigkeit der Zeichenmenge beweist nicht die Vollständigkeit ihrer Beziehungen.

Spätere Systeme bewahrten die Grenze, nicht zwingend den Mechanismus

1997 führte RFC 2070 für HTML unter anderem das Attribut DIR und das Override-Element BDO ein. Sein Informationsdatensatz gehört zu Web-Markup. Er belegt keine direkte Übernahme der RFC-1556-Suffixe.

Eine frühe Fassung des Unicode Bidirectional Algorithm unterschied logische Speicherreihenfolge und Anzeigereihenfolge und beschrieb Richtungscodes als Einfluss auf die Anzeige. Die aktuelle UAX #9 hat sich weit entwickelt und definiert auch erlaubte Eingriffe höherer Protokolle.

2012 erlaubte RFC 6532 direktes UTF-8 in Headerwerten einer Ende-zu-Ende-fähigen Mail-Umgebung. Der RFC-Editor-Eintrag hält diesen eigenständigen Vertrag fest. Der leichtere Transport eines größeren Repertoires vereinigte Speicher- und Darstellungsreihenfolge nicht.

Diese Quellen zeigen, dass dieselbe Schichtgrenze wiederkehrt. Sie beweisen weder eine Verbreitung von -i und -e noch eine einzige Abstammungslinie zu Unicode, HTML oder SMTPUTF8.

Ein Screenshot ist nur einer von drei Belegen

Der Transportbeleg enthält ursprüngliche Bytes, Hash, Transfer Encoding und dekodierte Codepoint-Folge. Er beantwortet, ob die Repräsentation unterwegs verändert wurde.

Der Interpretationsbeleg enthält Content-Type, Charset, Richtungsmodus, explizite Kontrollen, Absatzrichtung, höheres Markup und Style sowie Renderer- und Algorithmusversion. Er erklärt, welche Regeln der Empfänger anwenden wollte.

Der Präsentationsbeleg enthält Zeilensegmentierung, aufgelöste Visual Order, Screenshot und Kopier- oder Round-Trip-Ergebnis. Er zeigt, was in einer bestimmten Umgebung sichtbar wurde.

Ein Screenshot ohne Eingang belegt nur ein Bild; ein Hash ohne Ausgang nur eine Folge. Testfälle sollten Arabisch oder Hebräisch mit lateinischen Abschnitten, Zahlen, Satzzeichen, neutralen Zeichen, Verschachtelung und mehreren Breiten mischen. Bei einer Migration müssen altes und neues Ergebnis erhalten bleiben, bis die Abweichung erklärt ist.

Veröffentlichung war noch keine Betriebswirklichkeit

Heng Lus Running-Code Primacy liefert eine heutige Disziplin: Ein Dokument koordiniert, während Implementierung, Betrieb und Nutzung die operative Wirklichkeit zeigen. Die Veröffentlichung von RFC 1556 beweist die dokumentierte Konvention, nicht ihren Einsatz in Mailprogrammen.

Minimum Initial Specification, Localized Future Decision und Voluntary Adoption fragt nach minimalen, deterministischen und lokal prüfbaren gemeinsamen Regeln. Hier war die Gleichheit übertragener Zeichen als Invariante zu schwach. Modus, Kontext und Präsentationsverfahren mussten ebenfalls prüfbar sein.

Die Reality-Layers verhindern, dass ein Transportbeleg für die sichtbare Wirkung spricht. Diese spätere Sprache beweist keine Absicht Nussbachers oder ECMAs; sie begrenzt unsere eigene historische Aussage.

Entscheidend war, wer bereits gehandelt hatte

Im visuellen Modus hatte der Composer schon geordnet. Im impliziten Modus sollte der Renderer ordnen. Im expliziten Modus hatte der Sender Befehle geliefert, die der Renderer ausführen musste. Wer diese Vorgeschichte nicht kannte, konnte seine lokale Regel perfekt befolgen und die Nachricht dennoch verfälschen.

RFC 1556 erzählt daher nicht vom Versagen MIME, Hebräisch oder Arabisch zu transportieren. MIME ermöglichte die Reise. Das kurze Memo verweigerte nur, die Ankunftsbestätigung als Lesezertifikat auszugeben.

Die identische Folge belegt unversehrte Zustellung. Erhaltener Modus und Kontrollen belegen den Interpretationskontext. Ein benannter, getesteter Renderer belegt ein sichtbares Ergebnis. Erst zusammen bedeutet „richtig angekommen“ mehr als „die Bytes sind da“.

Quellen