Subject: Re: MIME encapsulation of multipart responses

From: [email-masked]
Date: Mon, 9 Sep 2002 11:51:08 -0400

John 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?

Multipart/related may be the proper one given the definition of 
mulitpart/mixed in RFC 2387:

   The Multipart/Related content-type addresses the MIME representation
   of compound objects. 
[Snip, snip]
   Responsibility for the display or processing of a Multipart/Related's
   constituent entities rests with the application that handles the
   compound object.

The intended use of multipart/mixed is:

3.  Intended usage

   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.  The content-type
   of the Multipart/Related object is specified by the type parameter.

which seems to be what we are trying to achieve here.  In this case we are 
trying to represent the VAGENDA by lots of smaller blobs of data.  WRT to 
the 'root' element, it is defined by:

3.2.  The Start Parameter

   The start parameter, if given, is the content-ID of the compound
   object's "root".  If not present the "root" is the first body part in
   the Multipart/Related entity.  The "root" is the element the
   applications processes first.

Unlike MHTML where we need to process the HTML before we can properly 
render the images in the right way, I dont think that it applys to 
iCalendar VAGENDAs since we dont need to have the data in a particular 
order to render it.  (So bascially we do not need a 'root' element but 
specifiying one does not seem to be any real issue either.)

If you check RFC 24046 you will find in Section 5.1.3 Mixed Subtype the 
following definition for its use:

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

In the VAGENDA case I dont think we have a need for data in a particular 
order.  It could be argued that the returned entries are 'independent' in 
the calendar and thus meet that criteria but if they are being used to 
rebuild a larger VAGNEDA then I dont think thats true any more.

So it looks on my first pass as if multipart/related is the proper MIME 
type to use over multipart/mixed.

> >The one multipart/related huge blob can arrive now - per iCal.
> >Correct?
> >
> Uh...no.  The term "multipart/related" does not appear in RFC-2445.  Nor 

> is it a requirement for basic MIME processing.

There is no explicit mention of multipart at all in 2445 but its there in 
stuff like ATTACH, ALTREP, etc.  As for the last bit, actually its 
addressed in RFC 2049 (and partly in RFC 2046) which is part of the 'base' 
MIME set.  If you look at RFC 2049 you will see:

   A mail user agent that is MIME-conformant MUST:
[Snip]
    (6)   Explicitly handle the following media type values, to
          at least the following extents:
[Snip, snip]
          Multipart:

            -- Recognize the mixed subtype.  Display all relevant
            information on the message level and the body part
            header level and then display or offer to display
            each of the body parts individually.

            -- Recognize the "alternative" subtype, and avoid
            showing the user redundant parts of
            multipart/alternative mail.

            -- Recognize the "multipart/digest" subtype,
            specifically using "message/rfc822" rather than
            "text/plain" as the default media type for body parts
            inside "multipart/digest" entities.

            -- Treat any unrecognized subtypes as if they were
            "mixed".

so no there is no explicit multipart/related compliance mandated (since 
its not part of the base MIME RFCs) but there is a mandate for dealing 
with 'unknown' subtypes (and you could call 'related' unknown if you have 
an old engine that is pre ~1995 when multipart/related was first specd). 
However we are now coding a new generation of client that should be able 
to deal with multipart/related just fine.  Unless there is someone who 
coded up a BEEP/CAP CUA pre-mulitpart/related I dont think that 
mulitpart/related 'conformance' is a real issue or reason to pick an 
unsuitable MIME subtype.

And I do believe that Doug was correct in his question...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Mon, 09 Sep 2002 12:23:00 -0400

[email-masked] wrote:

> In this case we are trying to represent the VAGENDA by lots of smaller 
> blobs of data.

I'm not sure that's true.  We're trying to represent the answer to a 
query such as "what objects are in the VAGENDA?".  That answer is not 
the VAGENDA itself.

> If you look at RFC 2049 you will see:
>

I'll say it again: a CAP CUA is not necessarily an MUA.  This means that 
RFC-2049 does not apply to CAP.  It applies to iMIP only because iMIP 
runs over email, and so an iMIP implementation is necessarily an MUA.

-- 
/============================================================\
|John Stracke      [email-masked]                   |
|Principal Engineer|http://www.centivinc.com                 |
|Centiv            |My opinions are my own.                  |
|============================================================|
|"I lost an 7-foot boa constrictor once in our house." --Gary|
|Larson on his youth                                         |
\============================================================/

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 09:37:50 -0600

> query such as "what objects are in the VAGENDA?".  That answer is not

However one of the query replies can be get me everything
in a VAGENDA. And part of CAP we agreed to allow synchronization.
And synchronization is going to require that we allow fetching
and setting full VAGENDAs.