In article
<199910181553(_dot_)QAA16006(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>,
Charles Lindsey
<chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk> writes
Currently, there seems no consensus on what you display when you receive a
Mime
multipart where all the Content-Types are text (or other inline-able types)
but
there are no Content-Dispositon headers to guide you. RFC 2183 is silent as
regards a defaults for Content-Dispositon.
Currently, there seem three schools of thought:
1. You display the first part inline, and consider all the subsequent
ones to be "attachments".
Failing to display text/plain to the user just because it is not the
first part seems perverse and unnecessarily restrictive.
It prevents having a series of "real attachments" interspersed with
explanatory text.
It causes problems such as personal signatures not being displayed just
because the sender placed it, naturally enough, at the end of the
message - after a real attachment.
2. You display all the parts inline, with some separator between them,
such as a ruled line across the page.
3. You display all the parts inline, with no visible separator. With
care, you can even arrange to change parts within a single line (perhaps
to intrpoduce a new character set or languauge) and have the result
displayed seemlessly.
We implemented 3 rather than 2 because in RFC2046 p20 it says:
NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break).
So when displaying a part we respect the sender's wishes, if they don't
put in a final line break then we don't either.
AFAIK, the only agent to provide #3 is Turnpike, and they seem to be
especially proud of their achievement :-).
We believed (and believe) that we were simply following the
specification, both in spirit and letter.
Regards
--
Paul Overell T U R N P I K E Ltd