From RFC1342:
When displaying a particular header field" (in the RFC 822 sense)
containing one or more encoded-words, an unencoded SPACE character
that immediately follows the encoded-word is not displayed. A
newline that immediately follows an encoded-word is not displayed
unless the encoded-word is the last token in that "field". (This is
to allow the use of multiple encoded-words to represent long strings
of unencoded text, without having to separate encoded-words where
spaces occur in the unencoded text.)
Then in the Examples section:
From: =?US-ASCII?Q?Keith_Moore?= <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld(_at_)dkuug(_dot_)dk>
CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard
<PIRARD(_at_)vm1(_dot_)ulg(_dot_)ac(_dot_)be>
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
Note the subject field has a continuation line. Following the above
discussion, one is only required to ignore the newline. Nothing is mentioned
about the following whitespace character. But in fact, this example was
intended to be concatenated together with no intervening whitespace.
The reason this is an issue is become some compose agents fold the
subject line at a whitespace character, inserting a linefeed, and using the
existing whitespace character _as_ the continuation LWSP-char. For this reason,
many MUA's leave the LWSP-char intact; even if they unfold the lines.
This presents the dilemna of stripping the space, and making the
RFC1342 appear "correct" -- BUT with perhaps a concatenation of existing
"words" from non-1342 sources; OR to leave the space and "break up" the
resultant decoded text.
I have a workaround, which is that I only apply LWSP stripping on
RFC1342 encodings. So the display would be essentially correct "most" of the
time. But "mostly" isn't a good way to define something, and 1342 implemented
to the letter doesn't correctly display the example given.
Anybody else tackled this one?
mike