In Artikel <[EMAIL PROTECTED]>
schrieb Wilfried Kramer <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] schrieb:
>>
>> Habe die Referenz vergessen: RFC 2646
>> <ftp://ftp.isi.edu/in-notes/rfc2646.txt>.
>
> Hast Du auch vergessen, da� ein Followup-to: in eine Gruppe gehen
> sollte, und nicht in mehrere?
[Dann setze ich das einfach mal.]
> Und zu dem Vorteil bzw. dem strittigen Punkt: Was passiert denn mit
> User-Agents, die das nicht unterst�tzen?
Die sollten, wenn sie Standardkonform sind, damit keinerlei Probleme
haben.
Was den zus�tzlichen Paramter im Content-Type Header betrifft, so sagt
RFC 2045:
| Parameters are modifiers of the media subtype, and as such do not
| fundamentally affect the nature of the content. [...] MIME
| implementations must ignore any parameters whose names they do not
| recognize.
Was den Body betrifft: Ich habe gerade erst mal RFC 2646 �berflogen.
Wenn ich keinen schweren Fu�angeln �bersehen habe, dann ist dieses
Format so definiert, da� folgende Aussage aus RFC 2646 tats�chlich
zutrifft:
| Because flowed lines are all-but-indistinguishable from fixed lines,
| currently deployed software treats flowed lines as normal Text/Plain
| (which is what they are). Thus, no interoperability problems are
| expected.
D.h. "Content-Type: text/plain; format=flowed" scheint tats�chlich
vollkommen korrekt formatierter Plaintext zu sein und sollte von jedem
Reader, der dieses Format nicht unterst�tzt, vollkommen korrekt als
Plaintext mit festen Zeilenumbr�chen und vern�nftiger Zeilenl�nge
dargestellt werden, weil es n�mlich genau das auch ist.
--
Rolf Krahl <[EMAIL PROTECTED]>
