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:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980