Subject: Re: MIME encapsulation of multipart responses

From: [email-masked]
Date: Mon, 9 Sep 2002 12:22:27 -0400

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: 
[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:53:07 -0400

[email-masked] wrote:

> necessary (if not implicitly mandated),

No, we do not.  The thread you cite was an related to iMIP, which 
inherits MUA-based requirements from MIME.  It does *not* mean that 
every iCalendar-based application must support multipart.

-- 
/============================================================\
|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: Mark Davidson <[email-masked]>
Date: Tue, 10 Sep 2002 10:38:04 +0100

> every iCalendar-based application must support multipart.

I agree with John. I see no reason why a CUA needs to use multipart anything when talking to a CAP 
server. It just adds another wrapping of the data that adds nothing and making parsing harder.

Mark Davidson

---

From: Andrea Campi <[email-masked]>
Date: Tue, 10 Sep 2002 12:21:04 +0200

On Tue, Sep 10, 2002 at 10:38:04AM +0100, Mark Davidson wrote:
> I agree with John. I see no reason why a CUA needs to use multipart 
> anything when talking to a CAP server. It just adds another wrapping of the 
> data that adds nothing and making parsing harder.
> 

I agree that we don't HAVE to support multipart. Now, if there was
a compelling reason, or a real advantage, then we can decided
whether to make it mandatory or optional.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Tue, 10 Sep 2002 10:37:13 -0400

Mark  wrote on 09/10/2002 05:38:04 AM:
> anything when talking to a CAP 

Then how do you expect the ATTACHments and other related kinds of data is 
going to get to the server?  Does the server magically regenerate the 
richer HTML rendering of DESCRIPTION from thin air or by some heuristic? 
That data has to get to the server somehow.  I have yet to read any 
commands or other ways for the CUA to get that kind of data to the CS. Did 
I miss it?

If not then the CS and CUAs are going to need to be multipart savy. 

Also, you need to be clearer about which parser you are talking about too: 
BEEP, iCalendar, CAP or some mix thereof.  The BEEP engine does not need 
to be parsing the multipart data and any iCalendar parser you have has to 
be at least a little bit savy (to handle ALTREPs and ATTACHments).  I 
suspect you meant the CAP server engine that has to 'unbundle' the 
multipart and feed just the iCalendar to the iCalendar engine but I dont 
want to make any assumptions.

Bruce

---

From: [email-masked]
Date: Tue, 10 Sep 2002 10:58:04 -0400

> whether to make it mandatory or optional.

Part of the confusion as to _if_ we need multipart comes from Johns 
mention of iMIP (per my citation).  While the citation came from an iMIP 
thread it does apply to CAP indirectly.  Since CAP essentially 
encapsulates iRIP (the 'real time' binding of iTIP) it needs to have the 
same abilities we have already covered and agreed on.  Ill try to take a 
better approach to get WG clarification and agreement (if not more lively 
discussion).

I will ask the same question again so that I hear the answer from those 
that think multipart support is NOT necessary in CAP: How do you expect to 
deal with ATTACHments and richer content renderings (ie: ALTREPs) if you 
do NOT have multipart support in the protocol/engine?  (Will they 
magically appear in my local CUA or will it have to download them using 
some undocumented CAP command or OOB mechanism??)

Im not claiming that me must mandate multipart support (I wont force you 
to support common iCalendar/iTIP features like ATTACHments and HTML but my 
users will!). 

Im claiming that w/o clearly defining how multipart support is to be used 
and supported in CAP then you're wasting everyones time now and going to 
cause untold hassles in the future (if not outright rejection of it). 

Look at the issues we have now in iMIP w/multipart support.  Some CUAs 
don't support it at all (ie: no ATTACHments, etc)  Some CUAs take one 
approach that may be contrary to the multipart semantics.  Some CUAs take 
a 'hybrid' approach to multipart in order to be 'richer' and to support 
workflow w/the other CUAs.  Its a big hodgepodge that makes interop 
testing less that seamless.  As a big user of C&S I really like seamless. 
Maybe its just me and most users want to have lots of limitations or hoops 
to jump thru....  Do we want to go thru this exact same morass with CAP as 
CAP clients start to develop??

After all, if I can send a simple iMIP meeting invite w/an attached agenda 
or related document NOW, why cant I use my "newer and improved" CAP CUA to 
read it from the newer CAP server when I could do it using POP3 or IMAP 
now?

As for compelling reason:  Removing features that users have now is NOT a 
step forward, its a total regression of functionality that I know people 
will balk at loosing.  Would you 'upgrade' to a newer client product if 
you knew you were losing features you already have and use?

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Tue, 10 Sep 2002 17:21:53 +0200

> do NOT have multipart support in the protocol/engine?  (Will they 

You are right, and I agree with you that for ATTACHments to work we
do need to support multipart. I was really focusing more on the
protocol than the bigger picture.

However, I still think my original objection stands, so let me
reformulate my question.

What if we mandated that the reply to a SEARCH command (just to
pick the most complex example) is contained in one or more VCALENDAR
objects in the MIME root, and additional MIME parts can be sent
for referenced ATTACHments? Would this break any functionality?
Would this be against any RFC?

Bye,
	Andrea

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 11:40:49 -0400

[email-masked] wrote:

> Then how do you expect the ATTACHments and other related kinds of data 
> is going to get to the server?  Does the server magically regenerate 
> the richer HTML rendering of DESCRIPTION from thin air or by some 
> heuristic?  That data has to get to the server somehow.

Wrong.  A CAP server will not store HTML, or other non-iCalendar data. 
 Notes can do it, but that's because Notes is a generic MIME store, 
which is not a viable approach for a scalable CS.

A CAP CS which received an iCalendar containing an ATTACH would have to 
reject it.

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|You buttered your bread, now lie in it.    |
\===========================================/

---

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

> every iCalendar-based application must support multipart.

Nor did Bruce say it was mandated. There are implementations
that use multipart - we can not just decide they have to break.

---

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

> whether to make it mandatory or optional.

No one is saying that all CUA's must support multipart.
We are saying that CUA's and CS's MAY support multipart.

We are also saying that some 244[567] implementations
already support multipart. Removing that support is not
in our charter. If you implement a CUA that can not support
attachments - that's fine.

---

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

[email-masked] wrote:
>....
> approach that may be contrary to the multipart semantics.  Some CUAs
> take a 'hybrid' approach to multipart in order to be 'richer' and to
> support workflow w/the other CUAs.  Its a big hodgepodge that makes
> interop testing less that seamless.  As a big user of C&S I really
> like seamless.  Maybe its just me and most users want to have lots of
> limitations or hoops to jump thru....  Do we want to go thru this
> exact same morass with CAP as CAP clients start to develop??

We went through this debate before. (Yes with iMIP, because
iMIP was the only transport). We do not have to mandate that
all CUAs and CSs ->generate<- multipart.

Currently we allow a status reply to indicate that a CS can
not support recurrence rules. Do we want to add one that
says - sorry, I threw away your attachments?

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:07:09 -0400

>that use multipart - we can not just decide they have to break.
They use multipart for iMIP.  An iMIP message will never be presented 
directly to a CAP CS.  Instead, an MUA will accept the multipart, 
extract the text/calendar body part, and submit it to the CS via CAP.

-- 
/=====================================================\
|John Stracke      [email-masked]            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:03:48 -0400

John Stracke wrote:

> A CAP CS which received an iCalendar containing an ATTACH would have 
> to reject it.
>
Correction: an ATTACH with a URI which referenced an external entity 
would be fine.

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 10:15:44 -0600

John Stracke wrote:
>...

A CAP server needs to store ALL valid iCalendar data, including
any included attachments. No place in CAP did we say that ATTACH
is invalid.

> which is not a viable approach for a scalable CS.

"Notes" can do more than a CS. Included attachments are part
of iCalendar.

> A CAP CS which received an iCalendar containing an ATTACH would have to

No. A CS that does not support ATTACH would have to reject it.
However a CS that does support ATTACH would not reject it.

We have never been chartered to reduce the 2445 specification.
We have never had any debate or agreement to disallow some valid
iCalendar objects. In fact the entire purpose of CAP is to
allow for the storage of iCalendar objects - not just some
of them.

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:36:05 -0400

Doug Royer wrote:

>Do we want to add one that
No, we want an error message that says, "your request was not of type 
text/calendar; go away".

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:37:00 -0400

>We are saying that CUA's and CS's MAY support multipart.
But MAYs and SHOULDs are a nightmare; they make interop incredibly hard, 
and should be used only when totally unavoidable.

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:25:56 -0400

[email-masked] wrote:

> mention of iMIP (per my citation).  While the citation came from an 
> iMIP thread it does apply to CAP indirectly.  Since CAP essentially 
> encapsulates iRIP (the 'real time' binding of iTIP) it needs to have 
> the same abilities we have already covered and agreed on.

(a) How can you argue based on iRIP requirements when iRIP has been 
abandoned for at least 3 years?

(b) The argument that iMIP required multipart did not apply to iRIP, 
because an iRIP implementation would not have been an MUA, either.

> After all, if I can send a simple iMIP meeting invite w/an attached 
> agenda or related document NOW, why cant I use my "newer and improved" 
> CAP CUA to read it from the newer CAP server when I could do it using 
> POP3 or IMAP now?

Because a sensible CAP server will be backed by a relational database, 
and should not be required to store blobs.

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 10:39:47 -0600

John Stracke wrote:
> directly to a CAP CS. 

Why not? Its a valid iCalendar object.

> Instead, an MUA will accept the multipart,

Why? They are valid iCalendar objects.

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 13:13:19 -0400

Doug Royer wrote:

>John Stracke wrote:
>  
>
>>An iMIP message will never be presented
>>directly to a CAP CS. 
>>    
>>
>
No, it is a MIME message which *contains* an iCalendar object.  If it 
also contains an image/gif, then that image/gif must not go up to the CS.

-- 
/==========================================================\
|John Stracke      [email-masked]                 |
|Principal Engineer|http://www.centivinc.com               |
|Centiv            |My opinions are my own.                |
|==========================================================|
|"Where's your sense of adventure?" "Hiding under the bed."|
\==========================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 13:16:11 -0400

>allow for the storage of iCalendar objects - not just some
But an HTML body part is not an iCalendar object.

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 11:39:29 -0600

> and should be used only when totally unavoidable.

This debate has been going on for years. I think
it is time to declare it unavoidable.

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 11:34:19 -0600

> abandoned for at least 3 years?

It was abandoned because we agreed to incorporate its features into CAP.

> because an iRIP implementation would not have been an MUA, either.

However ATTACH and ALTREP is part of iCalendar and iTIP as well
being part of iMIP and CAP and were also part of iRIP.

> and should not be required to store blobs.

I do not see the correlation. If the iCalendar object contains
an inline attachment - are your going to throw it away?

---

From: [email-masked]
Date: Tue, 10 Sep 2002 14:00:31 -0400

Andrea replied on 09/10/2002 11:21:53 AM:
> do need to support multipart. 

What about ALTREPs??

> for referenced ATTACHments? 

If the VCALENDAR (ie: text/calendar) entity _is_ the "MIME root" then you 
cannot have multiple MIME body parts in the same stream.  If the VCALENDAR 
entity _is_in_ the MIME root then sounds how iMIP requests are currently 
formulated (in the simplest format).  That is:

multipart/related
        text/calendar
        application/octet-stream

or possibly:

multipart/related
        multipart/alternative
                text/plain
                text/calendar
        application/octet-stream

(and so on).  In the 1st case the text/calendar is what some call the 
'root' entity.  In the 2nd case the multipart/alternative is the 'root' 
entity and the text/calendar is part of that entity. 

One thing to note is that only multipart/related (RFC 2387) actually 
defines the concept of a 'root' element; its not part of the base MIME 
RFCs where the other multipart subtypes are defined.  As such using the 
term 'MIME root' is only relevant w/in the scope of multipart/related 
discussions.

>                              Would this break any functionality?

I dont think so.

> Would this be against any RFC?

It would only against the RFCs if we violated the semantic meaning of the 
subtype really.  Ive yet to hear any suggestion that we misuse the 
subtypes but Im behind on my WG traffic.

So, if someone were to propose we send back data formatted like:

text/calendar
application/octet-stream

then Id say yes its a violation because we typed the top level MIME stream 
as text/calendar and followed it by an application /octet-stream.  This 
kind of data should have been enclosed in a multipart MIME wrapper.  As 
for which subtype Id say related over mixed or alternative given the 
semantics of each subtype.  From 2046:

5.1.3.  Mixed Subtype

and since the parts are NOT independent this is not a proper choice. Also 
from 2046:

5.1.4.  Alternative Subtype

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.

and since the iCalendar and attachment are NOT alternatives of each other 
this subtype is not the proper choice.  From 2387:

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. 

so this seems to be the proper choice to use.  As we add alternative 
renderings (ie: ALTREPs) we have to increase the complexity of the MIME 
wrappering but the basic adherence to the intended usage of "related" is 
still adhered to.

Bruce

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 14:28:24 -0400

>it is time to declare it unavoidable.
No.  It is time to stop throwing in extra options that add nothing.

|If you're omniscient, how do you know?     |

---

From: Andrea Campi <[email-masked]>
Date: Wed, 11 Sep 2002 09:33:45 +0200

> formulated (in the simplest format).  That is:

Uhm, I feel some context is being lost here.

I didn't object to the formats you show, I was objecting about the
possibility of getting:

multipart/related
         text/calendar
		BEGIN:VCALENDAR
		TARGET:aaa
		END:VCALENDAR
         text/calendar
		BEGIN:VCALENDAR
		TARGET:bbb
		END:VCALENDAR
         text/calendar
		BEGIN:VCALENDAR
		TARGET:ccc
		END:VCALENDAR
         text/calendar
		BEGIN:VCALENDAR
		TARGET:ddd
		END:VCALENDAR

as answer to a SEARCH with four targets. This is what I judge
unneeded, unnecessarily complicated and ambiguous. Compare this
with:

multipart/related
         text/calendar
		BEGIN:VCALENDAR
		TARGET:aaa
		END:VCALENDAR
		BEGIN:VCALENDAR
		TARGET:bbb
		END:VCALENDAR
		BEGIN:VCALENDAR
		TARGET:ccc
		END:VCALENDAR
		BEGIN:VCALENDAR
		TARGET:ddd
		END:VCALENDAR

Admittedly, I wasn't clear in my initial posts because I wasn't
thinking about ALTREPs and all, but still I can't see why you can't
add additional parts as easily in the second form as in the first
form.

Bye,
	Andrea

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Sep 2002 09:03:57 -0400

>an inline attachment - are your going to throw it away?
Uh.  This is a good point.  However, I think it's not conclusive, since 
the inline attachments are typically much smaller than the type of 
attachments that people send around in email.  A CS could usefully 
implement inline attachments, with a length limit, for a much lower cost 
than arbitrary MIME attachments.

|Brought to you by the letter Q.            |