On Tue, 7 May 2002, Charles Lindsey
<chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk> wrote:
In <200205061846(_dot_)47029(_at_)sendmail(_dot_)mutz(_dot_)com> Marc Mutz
<mutz(_at_)kde(_dot_)org> writes:
On Monday 06 May 2002 10:05, Simon Josefsson wrote:
<snip>
You can use MIME parts for this as well, mark the parts as inline and make
sure you don't add newlines during encoding. The processing rules
describes fairly well how to decode it back together.
<snip>
Euhm? Where did you read this? The only rfc I know of that defines
presentation of mails is rfc2183, defining the C-D header (plus others that
add new C-D values). RFC2183 basically interprets "inline" as "non-iconic" or
"expanded". In HTML speak this means <div>, not <span>.
Well Turnpike can do this trick, and they swear blind that the behaviour
in question is mandated by the MIME standards.
The MIME specs are clear that the CRLF preceding a boundary belongs to
the boundary, therefore it is possible to meet in the wild consecutive
inline text entities where the first part does _not_ have a final CRLF.
The MIME specs _don't_ mandate how such material should be displayed
(and we have never said that they do). Turnpike does not generate such
messages.
However, if Turnpike comes across such a message, and it is capable of
displaying the character sets of both parts, it will not introduce extra
vertical white space that is not in the message source. That is,
Turnpike would combine the text parts with no extra CRLF. Such an
interpretation for display seems (to me) "natural" given the MIME specs,
but _not_ mandated.
--
Ian Bell T U R N P I K E