"Charles Lindsey" <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> writes:
All this means is that we have to say format=flowed MUST
NOT be used with inline-signed messages, otherwise there is no guarantee
that an arbitrary recipient will be able to verify it.
But I still think that MUST is too strong. It is going to happen whether
you like it or not, so you have to warn of the dangers and give the aware
clients a mechanism to get around it.
What mechanism? All mechanisms that has been proposed so far are
flawed in one way or another, as far as I can tell. Suggesting one of
them doesn't do much good. Although I lean towards MUST NOT, a SHOULD
NOT would work. The main point is that the document don't say
implementations SHOULD use a known broken mechanism.
I just tried it using Opera (which is the only client I have which offers
format-flowed). When doing Copy/Paste from the compose window, it showed up
as one long line, but after it had been posted and read (it was a local news
article rather than an email), it behaved like a new format=flowed object.
I.e. at the point where it wrapped in the viewing window, the pasted
version showed a line end with a trailing SP (but it was longer than 76
characters, though). Is that the behaviour we typically expect?
No, Opera's format=flowed handling is broken. Look at the raw
messages and you will probably find that each format=flowed
"paragraph" is just one long (>76 octets) line with a terminating SPC.
Perhaps it has been fixed in later releases.