I'm going to go out on a limb here (start sawing!!) and claim that
multipart/parallel was put in to the spec because somebody wanted the cute
effect of seeing a picture and having the audio play at the same time (parallel
presentation). This is known as poor-man's synchronization. It has about zero
worth - anybody really doing presentation-style stuff needs much more
sophisticated synchronization mechanisms.
The claim that /mixed and /parallel are effectively "ordered" and "unordered"
collections is a post-facto interpretation. Frankly, I don't see the worth
of the distinction for MIME, but I'm certainly aware I could be missing a key
use (but as Neil has said, better to make this explicit or people will use
the mechanism for different and possibly incompatible uses).
On the attachment issue, I think it is clearly a presentation hint on an object
by object basis. The approach of using a multipart subtype is basically saying
- we need to attach additional information to this object, so we'll place
some structure around it and add a label to that structure. I think this is
wrong-headed, because you're really not specifying structure. An additional
Content-* header seems like the simplest way to go and the most direct.
Am I wrong, or is the critical distinction between an attachment and an
embedded object simply how it is presented to the user? Who says all
attachments have to go at the end of the document? In Slate, I would presume
that if someone indicates something is an attachment, I'd represent it in a
small iconic form (but it would show up whereever they had put it in the
document). The additional structure information would be useless to me.
(The parallel information is also useless - I treat parallel the same as
mixed). Nathaniel - how does Andrew distinguish /mixed and parallel subtypes
when presenting the document to the user?
Terry Crowley