text/plain; format=flowed (was: Thunderbird und "format=flowed")

[Helmut Waitzmann]

r...@zedat.fu-berlin.de (Stefan Ram):
> =?UTF-8?Q?J=c3=b6rg_Knobloch?= <jo...@jorgk.com> writes:

Vorbemerkung:  Diesen Beitrag habe ich im Fließformat verfasst, mit
konsequentem space‐stuffing.  Das bedeutet, dass Leser mit
Newsreadern, die das Fließformat nicht unterstützen, in ausnahmslos
jeder Zeile außer den ganz leeren Zeilen und den Zeilen, die nur
Zitatzeichen enthalten, am Zeilenanfang bzw. nach den Zitatzeichen
genau ein Leerzeichen zu viel vorfinden werden, während Leser mit
Newsreadern, die das Fließformat verstehen, die zusätzlichen
Leerzeichen nicht zu Gesicht bekommen.  Damit sollte der Inhalt
auch für Leser von nicht‐fließformat‐fähigen Newsreadern
einigermaßen nachvollziehbar sein.

>> Genau, das heißt "space stuffing" (und wird hier auch getestet:
>
> Dieses "space-stuffing" (nicht "space stuffing")
> wird mit zwei Zielen begründet: 1.) Es sollten Zeilen möglich
> sein, die mit ">" beginnen, aber keine Zitate sind. 2.) Es soll
> verhindert werden, daß Systeme, die Nachrichen weiterleiten,
> "From" am Anfang einer Zeile mit ">From" ersetzen.

Es gibt noch einen dritten Grund, und der ist eigentlich der
nullte:  Das space‐stuffing ermöglicht es dem Absender, den
Newsreader des Lesers ausdrücklich das Neuumbrechen des Textes nach
Wunsch des Lesers zu empfehlen, und zwar so, dass Zweideutigkeiten
vermieden werden.

>
> |In order to allow for unquoted lines which start with ">", and to
> |protect against systems which "From-munge" in-transit messages
> |(modifying any line which starts with "From " to ">From "),
> |Format=Flowed provides for space-stuffing.
> RFC 2046

Den Text gibt es dort nicht.


>
> Beide Probleme habe ich noch nie gesehen.

Ich habe sie schon gesehen – und die Autoren von RFC 3676 auch. 
Sonst hätten sie ihn nicht verfasst.  Und den nullten, von dir
nicht erwähnten Grund, habe ich auch schon oft in freier Wildbahn
gesehen.

> Daher erscheint mir die "Lösung" hier als schlimmer als die
> Probleme, welche sie angeblich lösen soll.

Nimm im folgenden Beispiel einer Nachricht an, die Nachricht soll
auf einem Smartphone angezeigt werden, und der Leser hat nicht mehr
sehr gute Augen, braucht also große Schrift.  Deshalb hat er nur
Platz für 45 Zeichen je Zeile.

Nimm weiter an, dass er beispielsweise den folgenden Satz angezeigt
bekommen soll:

«An arithmetischen Vergleichsoperatoren gibt es in
Programmiersprachen oft die folgenden: =, <>, <, >, <= und >=.»

Wenn der Absender nicht das Fließformat benutzt, der Leser aber
seinen Newsreader anweist, den Text auf 45 Zeichen je Zeile neu zu
umbrechen, kann es – je nachdem, wo beim Neuumbrechen ein
Zeilenwechsel passiert – durchaus sein, dass er das
Größer‐als‐Zeichen als Zitatzeichen präsentiert bekommt,
beispielsweise als farbigen senkrechten Balken.  Je nach
Anwendungsfall kann das dazu führen, dass der präsentierte Text
unverständlich oder missverständlich wird.

Sein Newsreader kann da ohne Nutzung des Fließformats nur raten –
und es kann sein, dass er in diesem Fall falsch rät.


Hätte der Absender der Nachricht dagegen das Fließformat benutzt,
gäbe es keine Zweideutigkeiten, und die Rohform des Textes sähe
dann beispielsweise so aus:

| An arithmetischen Vergleichsoperatoren gibt es in |
| Programmiersprachen oft die folgenden: =, <>, <, >, <= und >=.|

Die senkrechten Striche markieren die Zeilenanfänge und ‐enden. 
Man sieht das space‐stuffing am Zeilenanfang und das Leerzeichen am
Ende der ersten Zeile, das anzeigt, dass der Absatz in der nächsten
Zeile fortgesetzt wird.


Der Newsreader des Lesers würde dann beispielsweise folgendes
anzeigen.  Vom space‐stuffing ist nichts mehr zu sehen:

+---------------------------------------------+
|An arithmetischen Vergleichsoperatoren gibt |
|es in Programmiersprachen oft die folgenden: |
|=, <>, <, >, <= und >=. |
+---------------------------------------------+

Die senkrechten Striche zeigen den Fensterrand an.




Hätte der Absender das Größer‐als‐Zeichen als Zitatkennzeichen
verstanden haben wollen, müsste die Rohform des Textes
beispielsweise so aussehen:

| An arithmetischen Vergleichsoperatoren gibt es in |
| Programmiersprachen oft die folgenden: =, <>, <,|
|> , <= und >=.|

Das Größer‐als‐Zeichen muss als Zitatzeichen am Zeilenanfang noch
vor dem space‐stuffing sein.  Das space‐stuffing folgt unmittelbar
danach vor dem Komma.  Dass die mittlere Zeile am Ende kein
Leerzeichen hat, zeigt an, dass dort der Absatz endet.


Der Newsreader des Lesers würde dann beispielsweise folgendes
anzeigen.  Das «#»‐Zeichen steht für den farbigen senkrechten
Balken als Zitatmarkierung.  Vom space‐stuffing ist nichts mehr zu
sehen:

+---------------------------------------------+
|An arithmetischen Vergleichsoperatoren gibt |
|es in Programmiersprachen oft die folgenden: |
|=, <>, <, |
|#, <= und >=. |
+---------------------------------------------+

=> Der Newsreader auf dem Smartphone ist beim Neuumbrechen des
Textes in der Lage, das arithmetische Zeichen vom Zitatzeichen zu
unterscheiden, denn das space‐stuffing lässt keinen
Interpretationsspielraum.

>
> Wenn ich Zeilen haben will, die mit ">" beginnen, schütze
> ich alles mit "|", das ich sowieso aus einem anderen Grund
> einsetze, nämlich um ein Zitat zu kennzeichnen. Beispiel:

Und du vergisst dabei, dass es Fälle gibt, die weder Zitate sind
noch ASCII‐Grafik einsetzen (s. o.).

Und vor allem übersiehst du, dass «|» noch weniger als «>» unter
Newsreadern allgemein als Zitatzeichen, das beim Neuumbrechen
sonderbehandelt werden müsste, anerkannt ist.  Stell dir
beispielsweise vor, der anzuzeigende Text will nichts über
Arithmetik in Programmiersprachen sondern über Ein‐ und
Ausgabeumlenkungsoperatoren im POSIX‐Shell erzählen:  Bei denen
gibt es die Operatoren «<», «>», «>>», «>|» und «|».

=> Das Problem des Größer‐als‐Zeichens wird nur verlagert auf ein
anderes Zeichen, für das nicht einmal das Fließformat mehr eine
Lösung hat:  «|» kann im Fließformat kein Zitatzeichen sein.

>
> . Ein "From" am Anfang einer Zeile ist in Usenet-Nachrichten
> ohne weiteres erlaubt. Es gibt keine Grund, es beim Transport
> irgendwie zu schützen. Hier mal ein Test: Eine Zeile, die nur
> "From" enthält:
>
> From
>

Ich habe schon eine Nachricht (aus einer Mailingliste) erhalten,
die genau das Problem hatte:  Da begann der erste Satz eines
Absatzes mit dem Wort «From» – ich erhielt «>From».

Vielleicht weißt du das nicht:  Es gibt
E‐Mail‐to‐News‐Zweirichtungs‐Gateways, bei denen
Mailinglistenbetreiber ihre Liste anmelden können, damit ihre
Listenteilnehmer mit dem Newsreader kommunizieren können.

> . Die Idee, dies mit "space-stuffing" lösen zu wollen, heißt:
> "Fehlerhafte Systeme fügen Zeichen ein, die der Absender nicht
> in seine Nachricht geschrieben hat. Deshalb laßt uns jetzt noch
> mehr Zeichen einfügen!".

Du hast RFC 3676 nicht vollständig verstanden.  Ehe du das nicht
nachholst, kommen wir nicht weiter.

Mein Vorschlag dafür wäre die Gruppe «de.comp.text.misc», denn die
Diskussion des Textformats «text/plain; format=flowed» hat weder
mit dem Thunderbird noch direkt mit den Protokollen Netnews oder
E‐Mail zu tun.

Crosspost & Followup-To: de.comp.text.misc