On 8/10/07 4:06 PM, Paul Kyzivat wrote:
The situation seems cloudier for mixed vs parallel. I googled about
multipart/parallel and got a bunch of hits - most of them more than 10
years old. They all seem to be focused on *presentation*.
Well, that makes sense. After all, MIME is "Multipurpose Internet Mail
Extensions" -- which means that presentation is pretty important.
However, I think the practicalities of how these things ended up
implemented in mail agents is fairly irrelevant for their use in SIP --
we don't need to worry about interoperating SIP bodies with mail agents.
Consequently, it seems prudent to turn to the formal definitions of the
MIME types under discussion...
In the case of mixed apparently they are to be presented sequentially,
while in the case of parallel they may be presented concurrently. The
best example I came across was if there was both a picture and an
picture and an audio clip then with parallel they would be played
together.
In our case much of the stuff is not "presented". I don't know whether
or not we should consider the order of *processing* to be equivalent
to presentation, of if it matters.
For me, the key semantic differences between the types are summarized by
the following sets of text (from RFC 2046):
The "mixed" subtype of "multipart" is intended for use when the body
parts are independent and need to be bundled in a particular order.
...and...
This document defines a "parallel" subtype of the "multipart"
Content-Type. This type is syntactically identical to
"multipart/mixed", but the semantics are different. In particular,
in a parallel entity, the order of body parts is not significant.
In both cases, that's the full definition of the types. The parallel
type does go on to discuss the fact that most mail agents won't really
be able to render items in an unordered fashion, but this appears to be
commentary instead of definition.
So, based on these two definitions, it would appear that the sole
difference is that mixed is an ordered pile of media, while parallel is
an unordered pile of media.
Lets consider what is appropriate for some other cases:
- An invite request containing an SDP part and a QSIG part.
- An invite request containing SDP and a part referenced by
a CID URI in an Alert-Info header.
- An invite request containing two Alert-Info headers, each
with a CID URI. One references a picture, the other
references an audio clip.
None of these seem to call for multipart/related. The first two can, I
think, use either multipart/mixed or multipart/parallel. The last
might get different results using mixed and parallel.
I think that, if we were being pedantic, all of these should probably be
multipart/parallel to keep in the spirit of what RFC 2046 defines --
ordering seems unimportant for any of these cases. Note that "mixed"
does not imply "one at a time" -- it merely implies that order is
significant.
In practice, I doubt the difference between parallel and mixed makes
much difference for anything that we're working on (with the possible
exception of instant messaging, which will have nearly identical
considerations as email).
/a