Recently I had occasion to send a message consisting of
introductory text plus two pages of content in two formats
(text/plain and application/pdf). The obvious MIME structure
would be
multipart/mixed
text/plain (introductory text)
multipart/alternative
multipart/related
text/plain (page 1 text)
text/plain (page 2 text)
multipart/related
application/pdf (page 1)
application/pdf (page 2)
Sadly, many of the MUAs currently on the market fail to display
such a message properly. Of course, non-MIME text-only UAs will
display the message body. Kmail 1.4.3 seems to do a reasonable
job of displaying the message correctly. But Netscape/Mozilla,
MS Outlook [Express], Eudora, and probably others do not. Most
of these display only the introductory text.
A sample message has been submitted with Mozilla bug report
#184869, viewable at http://bugzilla.mozilla.org/show_bug.cgi?id=184869
It appears in most cases that it is the nested MIME multipart
structure that is not being correctly parsed; changing individual
media types seems to have little or no effect.
I suspect that part of the problem is what RFC 2822 has remedied
w.r.t. non-MIME messages, viz. the standards are spread out over
multiple documents, which makes it difficult for developers to
refer to *the* standard. Worse, there are errors in some of the
documents, and the errata page at www.rfc-editor.org is not
exactly well-publicized (IMO, it should be mentioned in
every RFC). Still worse, some of the RFCs contradict others (e.g.
while RFC 2046 states that the domain of an entity in the absence
of a Content-Transfer-Encoding header defaults to 7bit, RFC
2425 [5.5] claims that it is 8bit. 2822 also clarified the syntax
relative to 822.
It would be nice if the MIME documents were similarly brought up to
date with current ABNF, retrieval of the text which has been lost
in troff-comment-land these many years, and consolidation into a
small set of consistent documents.