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

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Aug 2007 16:46:18 +0300

During the last IETF meeting there was a comment with respect the 
relation of SDP bodies and icon bodies.

When the two bodies appear together, the draft says they need to be 
wrapped in a MIME multipart/mixed container. Adam commented that it 
should be multipart/related instead.

RFC 2387 defines the multipart/related MIME wrapper:

    The Multipart/Related media type is intended for compound objects
    consisting of several inter-related body parts.  For a
    Multipart/Related object, proper display cannot be achieved by
    individually displaying the constituent body parts.

RFC 2046 defines the multipart/mixed MIME wrapper:

    The "mixed" subtype of "multipart" is intended for use when the body
    parts are independent and need to be bundled in a particular order.
    Any "multipart" subtypes that an implementation does not recognize
    must be treated as being of subtype "mixed".

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.

The multipart/mixed definition speaks about "independent parts that need 
to be bundled in a particular order", which is probably true, because 
although the SDP and the icon are independent, the SDP should be read first.

While I don't have a strong opinion, I would suggest to leave the draft 
with the current indication of multipart/mixed.

Comments?

/Migel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Aug 2007 12:41:49 -0400

> the icon is also meaningful isolated, although it is not linked to any 

I agree that in this case the parts don't seem to be related.

> although the SDP and the icon are independent, the SDP should be read 

I don't see any ordering requirement here. There are certainly other 
cases where mixed seems to be the thing to use where ordering definitely 
isn't important.

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.

> with the current indication of multipart/mixed.

I agree unless there is a choice better than mixed or related.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Aug 2007 14:03:07 -0500

Comments inline.

On 8/10/07 8:46 AM, Miguel Garcia wrote:
> 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.

The canonical use case today for mutipart/related in email 
communications is a multipart/related document which contains an HTML 
document as its root, and dependencies (such as images) as the remaining 
parts. Section 5.2 of RFC 2387 provides an example of such a set up. The 
key idea in multipart/related is that the root document provides a 
semantic context for the remaining parts. (I presume you read enough to 
2387 to understand the "root document" concept, right?)

In this use case, the HTML will typically be meaningful in the absence 
of the images (for example, I use Thunderbird, which automatically 
blocks images in HTML mail until you specifically unblock them; for 
about 90% of the HTML mail I get, I never bother to load the images, 
because the HTML is sufficiently meaningful without them). By the same 
token, the images are also as meaningful in isolation as the icons you 
discuss above. These properties are not sufficient to counter-indicate 
the use of multipart/related, as you imply.

So, in both of these respects, it appears that the SDP/icon setup you're 
describing in the draft is congruent with the examples given in RFC 2387.

> The multipart/mixed definition speaks about "independent parts that 
> need to be bundled in a particular order", which is probably true, 
> because although the SDP and the icon are independent, the SDP should 
> be read first.

This simply means that the SDP is the root document -- it's the part 
that gives context to the other parts.

For example: consider the case in which you are putting together an SDP 
that is requesting the transfer of two files, both with icons. The root 
document -- the actual SDP -- is what provides the information that 
relates the icons to the appropriate files. The definition of 
"multipart/mixed" doesn't provide this necessary correlation property.

> While I don't have a strong opinion, I would suggest to leave the 
> draft with the current indication of multipart/mixed.

I _do_ have a strong opinion, and I am really rather certain that 
multipart/mixed is _inappropriate_ for the usage this draft proposes. I 
encourage you to seek the guidance of someone better versed in MIME 
before you make a final decision. I would suggest starting with Eric 
Burger <[email-masked]> or Chris Newman <[email-masked]>.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Aug 2007 14:11:58 -0500

On 8/10/07 11:41 AM, Paul Kyzivat wrote:
>> 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.
>

But they are -- the SDP contains a CID URI that indicates the related 
part that corresponds to a specific MSRP m= line.

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Aug 2007 17:06:43 -0400

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Aug 2007 17:32:52 -0500

On 8/10/07 4:06 PM, Paul Kyzivat wrote:
> 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.
>
> 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):

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

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Aug 2007 19:06:12 -0400

OK Adam. I can't find anything to argue with in your response.

Practically speaking, I suspect that there are more implementations of 
mixed than parallel out there. If parallel isn't understood, then it is 
supposed to be processed as mixed, so the mixed implementations out 
there should deal with it. (Will be interesting to see what actually 
happens.)

I guess the bottom line is what (if anything) we should *recommend* for 
use in the common cases such as SDP + QSIG.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Aug 2007 23:53:42 -0500

Paul Kyzivat wrote:
> mixed than parallel out there. If parallel isn't understood, then it 
> is supposed to be processed as mixed, so the mixed implementations out 
> I guess the bottom line is what (if anything) we should *recommend* 
> for use in the common cases such as SDP + QSIG.
I still contend that the technically correct answer would be 
multipart/parallel -- however, we did this wrong in RFC 3398 (I'm one of 
the guilty parties), and I don't think there's any way of getting that 
particular cat back into this particular bag.

Future extensions would do well to use mixed only if ordering is 
important, and parallel otherwise -- but it can only *hurt* 
interoperability to try to change what's specified for the stuff that's 
already published, implemented and deployed.

/a

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 13 Aug 2007 09:48:54 +0300

After reading the email thread, I don't have a problem to change the 
MIME wrapper to multipart/related. I will ask Eric and Chris to confirm 
our discussion.

/Miguel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Aug 2007 12:26:25 +0100

QSIG over SIP implementations I am aware of use multipart/mixed.

John 

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: 11 August 2007 05:54
> To: Paul Kyzivat
> Cc: Garcia, Miguel (NSN - FI/Espoo); mmusic
> Subject: Re: Estoterica regarding multipart MIME (was Re: 
> [MMUSIC] Filetransfer issue 49: multipart/mixed or multipart/related)
> 
> Paul Kyzivat wrote:

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 14 Aug 2007 10:14:01 +0300

I got a reply from Chris indicating that multipart/related makes more 
sense than multipart/mixed. So I will proceed with the change.

/Miguel

Miguel Garcia wrote:
>> document as its root, and dependencies (such as images) as the 
>> remaining parts. Section 5.2 of RFC 2387 provides an example of such a 
>> set up. The key idea in multipart/related is that the root document 
>> provides a semantic context for the remaining parts. (I presume you 
>> read enough to 2387 to understand the "root document" concept, right?)
>>
>> So, in both of these respects, it appears that the SDP/icon setup 
>> you're describing in the draft is congruent with the examples given in 
>> RFC 2387.
>>
>> For example: consider the case in which you are putting together an 
>> SDP that is requesting the transfer of two files, both with icons. The 
>> root document -- the actual SDP -- is what provides the information 
>> that relates the icons to the appropriate files. The definition of 
>> multipart/mixed is _inappropriate_ for the usage this draft proposes. 
>> I encourage you to seek the guidance of someone better versed in MIME