Re: MIME encapsulation of multipart responses

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote:
> > There isn't one.  But multipart/related has a single bodypart,
the root, 
> > which coordinates the others--as in the case of an HTML email
message 
> > which contains both the HTML page (the root) and the images it
uses. 
> > Maybe you mean multipart/mixed?
> 
> It has been a while so maybe it is multipart/mixed that I mean.

As I just noted in a reponse to John
I think that multipart/related is probably the way to go and that we dont
really care what the 'root' element is (it will default to the 1st element
in the stream if we dont expressly declare one).  Given in RFC 2046
multipart/mixed is defined by:

5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended
for use when the body
   parts are independent and need to be bundled in a particular order.

I dont think that it really applys (at
least the 'need to be bundled in a particular order' bit).  Since
RFC 2387 clearly defines the role of multipart/related as:

   The Multipart/Related content-type addresses
the MIME representation
   of compound objects.  The object is categorized by a "type"
   parameter.  Additional parameters are provided to indicate
a specific
   starting body part or root and auxiliary information which may
be
   required when unpacking or processing the object.

Id say that we should use multipart/related
over multipart/mixed.  We are after all representing a VAGNEDA which
is a compound object built up of several VEVENTs, VTODOs, VJOURNALs, VTIMEZONEs,
etc.

> Is multipart/related when you have the first part that can
> contain CID's or MID's?

Actually any MIME part can contain a
MID (although in an application/octet-stream its probably not the same
as in a text/html) and any body part can contain a CID if its inside a
multipart message (ie: MHTML is text/html and it contains the CID in it
for the embeded message thats in a separate image/png body part).

> So multipart/<something> must be valid.

Correct.

> I remember this list talking about multipart/<whatever>
pre CAP
> and just after the first cal-connect. Some implementations
> used it, others disallowed it. I think the consensus was that
> we can not mandate it, and can not disallow it. It was a MAY.
> 
> It is not that hard to implement multilpart/<whatever>.

I find references to this as far back
as April 2000 under the thread " CALSCH Action Items - - Error".
 Back then we all seemed to agree on this.

I agree, that building a multipart savy
UA is not nuclear science any more (unless you've never read any MIME RFCs
and you take the Microsoft Entourage approach).

I did find a note from Frank along this
vein that is relevant so Im partally including it below to save you archive
digging time:

iCalendar, RFC 2445, just defines a MIME type. This
is NOT the place to specify how you encapsulate the MIME type. We just
define here a text/calendar MIME content type. 
It is iMIP, RFC 2447, that defines how you send an
iCalendar object in email. That email could be as a singleton, text/calendar
MIME object or as a multipart object, such as multipart/mixed or such.
This is where the requirement is absent. I suggest that we all go back
and read the RFC 2447 spec.

In any case I think we all seem to agree
that multipart support is necessary (if not implicitly mandated), we just
need to pick the proper subtype based on their definitions and get on to
the real work.

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

..