Re: MIME implementation documentation

[Jamie Zawinski <[e-mail]>]

Pete Resnick wrote:
> 
> On 8/17/96 at 2:36 AM -0500, [e-mail] wrote:
> 
> >Are Nested Body Parts widely implemented?
> 
> I have one example from Macintosh Eudora 3.0, but it is sort of a special
> cased example: Mac Eudora 3.0 handles (and in fact expects) reception of
> nested multiparts when it comes to multipart/digest. If someone sends a
> multipart/mixed where the first part is a text/plain (or text/*) and the
> second part is a multipart/digest, Eudora will create a mail message in the
> In-box with the text/* part and an icon for an attached mailbox. When the
> attachment is opened, inside are the contents of the multipart/digest, each
> as a seperate mailbox entry, and those can themselves be any sort of
> message, including multipart messages which are handled recursively.

Netscape 2.0 and newer handle arbitrary nesting of parts, but will only
generate "deep" messages if a document is attached which is itself a
MIME object (forwarding a message which has a multipart inside of it,
for example.)

(Oh, if a dual-forked Mac file is attached, it will be sent as
multipart/appledouble, and that will probably itself end up within a
multipart/mixed.)

We normally generate multipart/mixed when there are attachments, but
will generate multipart/digest if all of the attachments (that is, all
parts but the first) are messages. (So we might generate digests with
only messages in them, or we might generate digests where the very first
part is text/plain and all the rest are messages.)

We don't handle receipt of multipart/digest any differently than
multipart/mixed (except for the rule about what the default part-type
is.)

Netscape 3.0 handles multipart/alternative (receipt, not generation) but
has slightly lenient rules for what the "best" part is.  RFC1521 says
that, when a multipart/mixed is within a multipart/alternative, it would
be reasonable to descend into it to see if all sub-parts are
displayable, but we don't do that.  Instead, we display the first part
of the multipart/alternative which is of a type which we can display
inline.  (The types we can display inline are text/plain, text/richtext,
text/enriched, text/html, image/gif, image/jpeg, image/xbm, certain
subtypes of message/external-body, and multipart/*.) 

(Actually, we don't display the first part that is displayable inline,
we move forward in it until we reach a part that is *not* displayable
inline, and then we display the part before that.  So if we got
text/plain, text/enriched, text/xxx, and text/html, we would display the
text/enriched rather than the text/html.  I'm not 100% convinced that
this is the right thing...)

> >Are External Body Parts widely implemented?

3.0 converts these to clickable URLs when it can (types ftp, anon-ftp,
local-file, mail-server, and url.)  (afs is treated like local-file if
running on Unix and "/afs/." is stat()able; mail-server is turned into a
mailto: URL, which will cause a filled-in mail composition window to
come up.  But if there is a body, it's not filled in automatically.) 
Others are presented by basically just pretty-printing the header
parameters.

-- 
Jamie Zawinski    [e-mail]   http://www.netscape.com/people/jwz/
``A signature isn't a return address, it is the ASCII equivalent of a
  black velvet clown painting; it's a rectangle of carets surrounding
  a quote from a literary giant of weeniedom like Heinlein or Dr. Who.''
                                                         -- Chris Maeda