Zusammenfassung

  • RFC 3676 führte DelSp ein, um ein bereits zwischen Wörtern vorhandenes Leerzeichen von dem Leerzeichen zu unterscheiden, das der Absender nur als Markierung für einen weichen Zeilenumbruch einfügt.
  • Der Standardwert ist no. Für die neue Umbruchmethode in Schriftsprachen, die ASCII-Leerzeichen selten oder gar nicht verwenden, muss der Absender DelSp=yes angeben, damit der Empfänger die Markierung entfernt und kein zusätzliches Zeichen in den rekonstruierten Text einfügt.

Ein Leerzeichen am Zeilenende kann zwei Geschichten erzählen. In text/plain; format=flowed zeigt es vielleicht an, dass ein Absatz in der nächsten physischen Zeile weiterläuft. Doch gehörte das Leerzeichen ursprünglich zwischen zwei Wörter, oder hat das Mailprogramm es nur als Umbruchmarkierung ergänzt? Die 2004 veröffentlichte RFC 3676 machte den Unterschied mit dem Parameter DelSp ausdrücklich. Sie löste RFC 2646 ab, behielt flowed text bei und ergänzte die Regel, nach der Empfänger einen weichen Umbruch rekonstruieren. (§§4–4.2.)

Die ältere Methode konnte nur dort umbrechen, wo zwischen Wörtern bereits ein Leerzeichen stand. Der Absender setzte CRLF hinter dieses vorhandene Leerzeichen. Beim Zusammenfügen der physischen Zeilen behielt der Empfänger das Trennzeichen. Für diese Methode empfiehlt die RFC DelSp=no: Das Leerzeichen ist ursprünglicher Inhalt und kein Layoutsignal, das gelöscht werden darf.

In Schriftsprachen und Zeichensätzen, die ASCII-Leerzeichen selten oder nicht verwenden, ist diese Methode unzureichend. Eine natürliche Wortgrenze zum Umbrechen fehlt möglicherweise. Die neuere Methode fügt am gewählten Punkt SP CRLF ein. Das Leerzeichen am Zeilenende kennzeichnet die Fortsetzung; mit DelSp=yes entfernt der Empfänger genau diese Markierung beim Zusammenfügen. Andernfalls würde die Darstellungsumformung ein Zeichen hinzufügen, das in der ursprünglichen Zeichenfolge nicht vorkam. Daher verlangt RFC 3676 bei dieser Methode DelSp=yes. Der Parameter erkennt nicht die Sprache, sondern deklariert die verwendete Kodierungsregel. (§§4.1–4.2.)

Auch der Standardwert ist festgelegt. Fehlt DelSp oder ist der Wert unbekannt, nimmt der Empfänger no an. Ohne Format=Flowed ist DelSp undefiniert; außerhalb von text/plain; format=flowed SOLLTE der Empfänger es ignorieren. Das Programm soll also nicht raten, ob ein abschließendes Leerzeichen künstlich war. Der Standardfall erhält die ältere Interpretation, kann aber eine verlorene Senderabsicht nicht wiederherstellen.

Auch die Position des Markers zählt. Wird er unmittelbar vor einem ursprünglichen Leerzeichen eingesetzt, wandert dieses Leerzeichen an den Anfang der nächsten Zeile. Flowed text schützt Zeilen, die mit Leerzeichen, > oder From beginnen, per Space-Stuffing. Eine Umbruchposition kann somit eine zusätzliche Regel auslösen. RFC 3676 empfiehlt, SP CRLF hinter das vorhandene Leerzeichen zu setzen. So bleiben Worttrenner und Umbruchmarker zwei unterschiedliche Elemente. (§§4.2, 4.4.)

Der Geltungsbereich ist bewusst eng: RFC 3676 beschreibt ein Übertragungsformat für text/plain, nicht die Speicherung lokaler Dateien. Content-Transfer-Encoding ist eine andere Ebene. Die Spezifikation erklärt auch die Reihenfolge von Textvorbereitung, Signatur oder Verschlüsselung und Reflow; die kryptografische These gehört jedoch zur gesonderten RFC-2646-Arbeit und wird hier nicht wiederholt. Die Norm belegt ebenso wenig, dass ein konkretes Mailprogramm sich so verhielt. Die Perspektive aus Lu Hengs Note 65 verlangt, geschriebene Regeln von beobachtetem laufendem Code zu trennen. Aussagen über die tatsächliche Anzeige erfordern identifizierte Programmversionen und aufgezeichnete Nachrichten.

Quellen

  • RFC 3676, insbesondere §§4.1–4.2 und Anhang A.
  • RFC 2646, die frühere Spezifikation für flowed text.
  • RFC 2046, Rahmenwerk der MIME-Medientypen.
  • RFC 2045, Kontext für Nachrichtenkörper und MIME-Transferkodierung.
  • Lu Heng, Note 65, offengelegte analytische Perspektive, kein Implementierungsnachweis.