Zusammenfassung

  • RFC 1523 begrenzte text/enriched bewusst. ASCII-nahe Rohdaten sollten auch ohne MIME erträglich bleiben; ein minimaler Reader konnte Markierungen entfernen und lesbare Prosa erzeugen.
  • Lesbarkeit bedeutete keine Gleichheit. Unbekannte Wirkungen, verborgene Parameter, lokale Satzentscheidungen und eine reichere multipart/alternative-Fassung konnten fehlen, obwohl die Wörter ankamen.

Reichweite und Ausdruck wurden getrennte Fassungen

RFC 1523 erschien im September 1993 als Informational RFC und entwickelte text/richtext aus RFC 1341 zu text/enriched weiter. Die Sprache sollte kein vollständiges Textverarbeitungssystem sein. Ihre Fähigkeiten blieben bei Effekten, die ein übliches Programm des Empfängers wahrscheinlich darstellen konnte.

Wo diese kleine Sprache nicht ausreichte, konnte ein Absender multipart/alternative verwenden: eine weit verständliche enriched-Fassung neben einer reicheren Repräsentation wie ODA. Ein leistungsfähiger Client wählte die reichere, ein anderer die kompatiblere. Beide hatten denselben mehrteiligen Gegenstand empfangen, aber nicht dieselbe Fassung gelesen.

Der ausgewählte Teil war deshalb kein nebensächliches UI-Detail. Er gehörte zur Wirklichkeit der Mitteilung. Ein Zustellbeleg allein sagte nicht, welche Information auf dem Bildschirm erschien.

Der Rückfall war in die Grammatik eingebaut

Ein Fernschreibsystem sollte Formatierungsbefehle abstreifen und verständlichen Text übrig lassen können. Bei ASCII oder einem Acht-Bit-Superset sollten sogar die Rohdaten für einen Reader ohne MIME noch hinreichend lesbar sein. Weniger Ausdruck erhöhte die Chance korrekter Anzeige.

Die ASCII-Befehle standen in spitzen Klammern, unterschieden keine Groß- und Kleinschreibung und waren höchstens 60 Zeichen lang. << bezeichnete ein wörtliches <. Öffnen und Schließen mussten ausgeglichen und korrekt verschachtelt sein.

Die Kompositionsseite trug damit mehr Last. Der Reader gewann eine einfache Stack-Logik: Zustand beim Öffnen ablegen, beim Schließen wiederherstellen. Eine vernünftige Reaktion auf fehlerhafte Verschachtelung war erwünscht, aber nicht als verlässliche Bedeutung normiert.

Auch Zeilenenden wurden rekonstruiert. Ein einzelnes CRLF wurde zum Leerzeichen, N aufeinanderfolgende CRLF zu N−1 sichtbaren Umbrüchen. Ein Transportknick musste so keinen Absatz erfinden. Rohbytes, physische Zeilen, logischer Text und Ausgabe blieben dennoch vier verschiedene Belege.

Unbekanntes blieb sichtbar, aber wirkungslos

Ein unbekannter Formatbefehl war zwingend ein no-op. Sein Text blieb, seine Wirkung nicht. X- war für private Erweiterungen vorgesehen; eine formale Erweiterung brauchte ein neues Internet-Dokument.

So scheiterte ein alter Reader nicht an zukünftiger Syntax. Er konnte aber eine Warnung oder Hierarchie still in gewöhnliche Prosa verwandeln. Parserfolg bewies Fortsetzbarkeit, nicht Bedeutungsidentität.

<param> enthielt Werte für einen Befehl. Der Interpreter durfte sie auswerten oder ignorieren, sollte sie jedoch nicht anzeigen. Ein Minimalrenderer löschte damit nicht nur Markierung, sondern auch Parameterinhalt. Eine flüssige Textfassung konnte eine für die Erweiterung wesentliche Angabe vollständig verlieren.

nofill und verbatim verlangten selbst vom einfachen Entferner Zustandswissen. Ersteres stoppte Füllung und normale CRLF-Behandlung, Letzteres zusätzlich Ausrichtung und innere Befehlsauswertung bis zum Endtoken.

Die Seite entstand erst lokal

Schriften, Zeilenbreite, Einrückung, Ausrichtung und kombinierbare Wirkungen richteten sich nach dem Empfänger. Waren Effekte nicht gleichzeitig möglich, durfte der Reader den innersten erkannten Befehl bevorzugen. Mehrere visuelle Ergebnisse konnten normgerecht sein.

Das Dokument erklärte, der Mechanismus werfe keine Sicherheitsfragen auf. Diese Aussage wird hier als Einschätzung von 1993 festgehalten, nicht als heutiger Nachweis für Erweiterungen, Parser oder umgebende MIME-Anwendungen. RFC 1563 löste RFC 1523 ab, später RFC 1896 RFC 1563. Dokumentfolge ist kein Beleg für sofortigen Austausch aller Installationen.

Der Quellenbestand nennt keinen konkreten Reader, keine Installation und keine einzelne Nachricht; er misst weder Verbreitung noch Nutzerreaktion oder das beobachtete Ergebnis einer fehlerhaften Eingabe. Belegt sind die Formatregeln und die Dokumentfolge, nicht das Verhalten einer bestimmten Implementierung.

Für eine belastbare Geschichte müssen Quellbytes und Zeichensatz, physische CRLF, Parserstack, bekannte und unbekannte Befehlsentscheidungen, verborgene Parameter, gewählte Alternative, lokale Darstellung und menschliche Deutung getrennt erhalten bleiben. Der lesbare Rückfall organisierte Verlust. Er hob ihn nicht auf.

Quellen