Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related

[Paul Kyzivat <pkyzivat at cisco.com>]

Adam,

First, I have to say that I know next to nothing about this, so I defer 
to the experts.

I think you now have me convinced re multipart/related for the example 
at hand.

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

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.

	Thanks,
	Paul

Adam Roach wrote:
> On 8/10/07 11:41 AM, Paul Kyzivat wrote:
> > > The difference between both is subtle, in my opinion. The 
> > > multipart/related definition says that "proper display cannot be 
> > > achieved by individually displayign the constituent body parts", 
> > > which is not entirely true: SDP will be meaningful in the absence of 
> > > an icon; the icon is also meaningful isolated, although it is not 
> > > linked to any file descriptor.
> >
> > I agree that in this case the parts don't seem to be related.
>
> But they are -- the SDP contains a CID URI that indicates the related 
> part that corresponds to a specific MSRP m= line.
>
> > Is there another multipart subtype that is like mixed except without 
> > ordering? (multipart/unordered?) I've not heard of such a thing. If 
> > not it seems that mixed must be used even when ordering isn't important.
>
> You're describing multipart/parallel, which would be appropriate if the 
> parts actually _were_ unrelated and unordered. However, in this case, 
> they *are* related (one part containing a CID indicating another part is 
> sort of the dictionary definition of being related) so 
> multipart/parallel is also inappropriate.
>
> /a

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic