[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Comments inline.

On 8/10/07 8:46 AM, Miguel Garcia wrote:
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 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 <eburger at bea.com> or Chris Newman <chris.newman at sun.com>.

/a

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