Re: MIME implementation documentation

[Pete Resnick <[e-mail]>]

Jamie, we can take this off list (or perhaps over to mailext) if it turns
out to generate a lot of back and forth discussion between the two of us.

On 8/18/96 at 12:22 AM -0500, Jamie Zawinski wrote:

>(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.)

Yes, I'd forgotten about this one. Of course anyone who generates stuff
with appledouble is generating nested multipart, but again this is a
"special case" kind of processing. Does this count, Harald?

>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.)

This is not a good thing. From section 7.1.5 of
<draft-ietf-822ext-mime-imt-05.txt>:

        Note: Though it is possible to specify a Content-Type value
        for a body part in a digest which is other than
        "message/rfc822", such as a "text/plain" part containing a
        description of the material in the digest, actually doing so
        is undesireble. The "multipart/digest" Content-Type is
        intended to be used to send collections of messages. If a
        "text/plain" part is needed, it should be included as a
        seperate part of a "multipart/mixed" message.

If Eudora gets a digest with a text/plain part, we make a "dummy" message
in the mailbox which represents the digest and put the text/plain part in
there. It's much better to put the text/plain part as the first part of a
multipart/mixed where the second part is the digest:

multipart/mixed
        text/plain
        multipart/digest
                message/rfc822
                message/rfc822
                message/rfc822

It makes much more sense in this form.

>(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...)

I think this is a reasonable thing to do. Even though walking the parts
backwards is probably the optimal thing to do, it can be a pain in the
butt, and what you're doing should get a reasonable result to the user.

pr

--
Pete Resnick <mailto:[e-mail]>
QUALCOMM Incorporated
Work: [phone] / Fax: [phone]