Peter J. Holzer
2007-06-29 20:51:33 UTC
[Das wird jetzt hier ziemlich off-topic, daher Fup2 nach
at.usenet.sonstiges (scheint mir die passendste Gruppe innerhalb von
at.* zu sein, nach de.* mag ich nicht crossposten]
im Usenet eine blöde Idee ist? In beiden Fällen: Warum?
Format-flawed ist prinzipiell eine blöde Idee[tm]. Pi hat da mal ein
<http://piology.org/SeaMonkey/format-flawed.html>
Der gute Pi mischt da ein wenig prinzipielle Probleme von format=flowed,
Bugs von Mozilla und seine Ansichten zusammen.
Aber der Reihe nach:
| Eigentlich wäre dieses Verfahren damit ein Content-Transfer-Encoding.
| Statt dessen wird es jedoch als Content-Type (genauer: Subtype von
| text/plain) deklariert.
Das ist falsch. Ein Content-Transfer-Encoding darf die Semantik nicht
ändern. Das ist aber bei ff der Fall: Gegenüber text/plain führt es die
Konzepte des Absatzes und der Quote ein. FF kann daher kein
Content-Transfer-Encoding sein. Man kann darüber streiten, ob es
text/plain ähnlich genug ist, um nur durch einen Parameter unterschieden
zu werden, oder ob man einen eigenen Content-Type (z.B. text/flowed)
hätte nehmen sollen. Die Gründe für diese Entscheidung sind im RFC
ausreichend dargelegt. If you want text/html, you know where to find it.
| * Zeilen, die mit dem Quotezeichen (>) beginnen, werden auch eingerückt.
| Dies sieht man vor allem, wenn jemand eine gequotete Zeile in zwei
| Teile zerlegt und vor den zweiten Teil dann (was ja auch richtig ist!)
| ein Quotezeichen händisch einfügt. Durch diesen Effekt erscheint die
| Zeile beim Empfänger dann nicht als gequotet.
Das ist eim Bug im Editor. Ein FF-fähiger Editor muss in der Lage sein,
Quotes als solche zu erkennen und auch dann nicht zu verstümmeln, wenn
der User in der Mitte einer zitierten Zeile was einfügt. Der User darf
in diesem Fall kein Quotezeichen händisch einfügen, das hat der Editor
zu erledigen.
| * Zeilen, die schon vorher ein Leerzeichen am Ende hatten, werden derer
| beraubt, was digitale Signaturen zerstört.
Da war die Signatur an der falschen Stelle. Natürlich muss man zuerst
ff-kodieren und dann erst signieren, nicht umgekehrt (tatsächlich muss
man in MIME sogar auch noch das Content-Transfer-Encoding vor der
Signatur durchführen, und es ist MTAs explizit verboten am
Content-Transfer-Encoding von multipart/signed-Teilen was zu ändern).
| Der wesentliche Bruch, der durch Format flawed entsteht, ist, dass eine
| Grundannahme von Mail und News verletzt wird, nämlich, dass der
| abgeschickte Text auch so aussieht, wie er abgeschickt wurde (WYSIWYG).
Dieser Bruch ist allerdings schon dadurch eingetreten, dass viele MUAs
und NUAs text/plain per default in einer Proportionalschrift darstellen.
Das mag dem Pi und Dir und mir nicht gefallen, aber wir müssen damit
leben, dass ASCII-Graphiken, Tabellen und Unterstreichungen mit einer
gewissen Wahrscheinlichkeit beim Empfänger eben nicht so dargestellt
werden, wie wir sie gedacht haben.
FF erlaubt es aber, Zeilen als "fixed" zu markieren. Ein guter FF-Editor
würde dem Schreiber ermöglichen, zwischen Absätzen, die umgebrochen
werden dürfen, und Inhalten, die nicht umgebrochen werden dürfen, zu
unterscheiden. Ein guter FF-Viewer könnte Zeilen, die nicht umgebrochen
werden dürfen, mit einem Fixed-Width-Font darstellen.
| Je nach Implementation von format=flowed (z.B. in der von SeaMonkey),
| bekommt er aber noch ein anderes Problem. Die Absätze werden nämlich als
| eine lange Zeile dargestellt, die erst am Fensterrand umbrochen wird;
| dies ist regelmäßig eine Zeilenlänge weit jenseits dessen, was gut
| lesbar ist.
Wie Pi hier richtig feststellt, ist das ein Problem einer spezifischen
Implementation. Nichts hindert einen FF-Viewer daran, nach einer
sinnvollen Breite (z.B. ca. 40 em) umzubrechen, auch wenn das Fenster
breiter ist. Die Unterscheidung zwischen Absätzen und fixed lines sorgt
dafür, dass tatsächlich nur Absätze umgebrochen werden und nicht z.B.
Tabellen oder ASCII-Art (die breiter sein können).
| Spezifische Probleme von SeaMonkey (und damit Netscape oder Thunderbird)
Diese Zwischenüberschrift impliziert, dass alle vorher geschilderten
Probleme prinzipielle Probleme von FF seien. Das ist aber - wie ich
versucht habe zu zeigen - nicht der Fall.
hp
at.usenet.sonstiges (scheint mir die passendste Gruppe innerhalb von
at.* zu sein, nach de.* mag ich nicht crossposten]
Format=flowed ist AFAIK eine blöde Idee
Meinst Du, dass format=flowed an sich eine blöde Idee ist oder dass esim Usenet eine blöde Idee ist? In beiden Fällen: Warum?
<http://piology.org/SeaMonkey/format-flawed.html>
Bugs von Mozilla und seine Ansichten zusammen.
Aber der Reihe nach:
| Eigentlich wäre dieses Verfahren damit ein Content-Transfer-Encoding.
| Statt dessen wird es jedoch als Content-Type (genauer: Subtype von
| text/plain) deklariert.
Das ist falsch. Ein Content-Transfer-Encoding darf die Semantik nicht
ändern. Das ist aber bei ff der Fall: Gegenüber text/plain führt es die
Konzepte des Absatzes und der Quote ein. FF kann daher kein
Content-Transfer-Encoding sein. Man kann darüber streiten, ob es
text/plain ähnlich genug ist, um nur durch einen Parameter unterschieden
zu werden, oder ob man einen eigenen Content-Type (z.B. text/flowed)
hätte nehmen sollen. Die Gründe für diese Entscheidung sind im RFC
ausreichend dargelegt. If you want text/html, you know where to find it.
| * Zeilen, die mit dem Quotezeichen (>) beginnen, werden auch eingerückt.
| Dies sieht man vor allem, wenn jemand eine gequotete Zeile in zwei
| Teile zerlegt und vor den zweiten Teil dann (was ja auch richtig ist!)
| ein Quotezeichen händisch einfügt. Durch diesen Effekt erscheint die
| Zeile beim Empfänger dann nicht als gequotet.
Das ist eim Bug im Editor. Ein FF-fähiger Editor muss in der Lage sein,
Quotes als solche zu erkennen und auch dann nicht zu verstümmeln, wenn
der User in der Mitte einer zitierten Zeile was einfügt. Der User darf
in diesem Fall kein Quotezeichen händisch einfügen, das hat der Editor
zu erledigen.
| * Zeilen, die schon vorher ein Leerzeichen am Ende hatten, werden derer
| beraubt, was digitale Signaturen zerstört.
Da war die Signatur an der falschen Stelle. Natürlich muss man zuerst
ff-kodieren und dann erst signieren, nicht umgekehrt (tatsächlich muss
man in MIME sogar auch noch das Content-Transfer-Encoding vor der
Signatur durchführen, und es ist MTAs explizit verboten am
Content-Transfer-Encoding von multipart/signed-Teilen was zu ändern).
| Der wesentliche Bruch, der durch Format flawed entsteht, ist, dass eine
| Grundannahme von Mail und News verletzt wird, nämlich, dass der
| abgeschickte Text auch so aussieht, wie er abgeschickt wurde (WYSIWYG).
Dieser Bruch ist allerdings schon dadurch eingetreten, dass viele MUAs
und NUAs text/plain per default in einer Proportionalschrift darstellen.
Das mag dem Pi und Dir und mir nicht gefallen, aber wir müssen damit
leben, dass ASCII-Graphiken, Tabellen und Unterstreichungen mit einer
gewissen Wahrscheinlichkeit beim Empfänger eben nicht so dargestellt
werden, wie wir sie gedacht haben.
FF erlaubt es aber, Zeilen als "fixed" zu markieren. Ein guter FF-Editor
würde dem Schreiber ermöglichen, zwischen Absätzen, die umgebrochen
werden dürfen, und Inhalten, die nicht umgebrochen werden dürfen, zu
unterscheiden. Ein guter FF-Viewer könnte Zeilen, die nicht umgebrochen
werden dürfen, mit einem Fixed-Width-Font darstellen.
| Je nach Implementation von format=flowed (z.B. in der von SeaMonkey),
| bekommt er aber noch ein anderes Problem. Die Absätze werden nämlich als
| eine lange Zeile dargestellt, die erst am Fensterrand umbrochen wird;
| dies ist regelmäßig eine Zeilenlänge weit jenseits dessen, was gut
| lesbar ist.
Wie Pi hier richtig feststellt, ist das ein Problem einer spezifischen
Implementation. Nichts hindert einen FF-Viewer daran, nach einer
sinnvollen Breite (z.B. ca. 40 em) umzubrechen, auch wenn das Fenster
breiter ist. Die Unterscheidung zwischen Absätzen und fixed lines sorgt
dafür, dass tatsächlich nur Absätze umgebrochen werden und nicht z.B.
Tabellen oder ASCII-Art (die breiter sein können).
| Spezifische Probleme von SeaMonkey (und damit Netscape oder Thunderbird)
Diese Zwischenüberschrift impliziert, dass alle vorher geschilderten
Probleme prinzipielle Probleme von FF seien. Das ist aber - wie ich
versucht habe zu zeigen - nicht der Fall.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | ***@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | ***@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"