Subject: Re: MIME encapsulation of multipart responses

From: "Graham Gilmore" <[email-masked]>
Date: Tue, 10 Sep 2002 15:51:49 -0400

Doug Royer wrote:
> John Stracke wrote:
> > They use multipart for iMIP.  An iMIP message will never be presented
> > directly to a CAP CS.
>
> Why not? Its a valid iCalendar object.
>
> > Instead, an MUA will accept the multipart,
> > extract the text/calendar body part, and submit it to the CS via CAP.
>
> Why? They are valid iCalendar objects.

    No, iMIP messages are MIME envelopes with specific characteristics.
iCalendar objects are the contents of those envelopes, being text in the
format defined by RFC 2445.  Just because iCalendar defines some specifics
as to how it should be enclosed in a MIME message (by specifying the MIME
type as "text/calendar", for example) doesn't make MIME part of iCalendar.
iCalendar says
*nothing* about external references (even within the same MIME envelope)
being considered part of the iCalendar object.

Doug Royer also wrote:
> Mark Davidson wrote:
> >
> > If we allow multipart/related with URIs pointing to attachments, then
> > how do we get the data back out of the CS. If I do a search, then I
> > just get objects and properties.
>
> SELECT * FROM VEVENT where UID = 'a-id'
>
> If it has inline attachments, they will be included. Where in
> CAP did it say that we only allow for some valid iCalendar objects?
> If your CUA could not support multipart, then you could not have
> put it into the CS. If your CUA can not support multipart and
> you contact a CS that is not yours, and the CS replies with
> a multipart message, then the CU has two choices, live with the
> error, or get another CUA.
>
> ATTACHMENTS are part of iCalendar as is ALTREP. If a CUA/CS does
> not wish to fully implement iCalendar - fine. But we can not
> mandate that no CUA or CS can fully implement iCalendar.

    Nowhere does it say that an CS must extract the contents referenced (for
example) by a cid: URI in an ATTACH property or a property with an ALTREP
parameter and store it along with the iCalendar data.
    As an illustration, RFC 2447 gives an interesting example:

4.1 Single Component With An ATTACH Property

   This minimal message shows how an iCalendar object references an
   attachment. The attachment is accessible via its URL.

   From: [email-masked]
   To: [email-masked]
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:[email-masked]
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[email-masked]
   ATTENDEE;RSVP=YES:mailto:[email-masked]
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SUMMARY:Phone Conference
   DESCRIPTION:Please review the attached document.
   UID:calsvr.example.com-873970198738777
   ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

    Does this mean that to be a iCalendar-conformant CS, the CS must also
know how to retrieve files via FTP and store them?

    Specifying an ATTACH or ALTREP with a cid: is PERFECTLY VALID iCalendar,
I agree 100%.  However, expecting the CS to store & re-deliver to you at a
later time anything other than the URI that was in the original iCalendar is
ludicrous.  It is the CUA that must resolve the URI.  If you MUST have your
ATTACH stored in the CS, put it inline using the VALUE=BINARY parameter and
base64 encoding.
    Otherwise, not only do you have to store the iCalendar, but you have to
store all the MIME envelopes for all CAP messages as well just in case
someone decides to include a cid: URI to the ATTACH they included with a
meeting 6 years ago (oh, did your CS clean up that old data already?  oops!)

    Graham

---

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

Graham Gilmore wrote:
> format defined by RFC 2445.

Which include ALTREP and ATTACH.

> ...

---

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

> parameter and store it along with the iCalendar data.

Again - some iMIP implementations can only process text/calendar
as the only  body part. That does not mean that we must restrict
CAP to those implementations.

> Does this mean that to be a iCalendar-conformant CS, the CS
> must also know how to retrieve files via FTP and store them?

No. Not unless it is in the same MIME object (and FTP is not).

>  Specifying an ATTACH or ALTREP with a cid: is PERFECTLY VALID
> iCalendar, I agree 100%.  However, expecting the CS to store &
> re-deliver to you at a later time anything other than the URI that
> was in the original iCalendar is ludicrous.  It is the CUA that must
> resolve the URI.  If you MUST have your ATTACH stored in the CS, put
> it inline using the VALUE=BINARY parameter and base64 encoding.

What if the URI is a CID to a body part in the same
MIME object ? - What then do you expect it to retrieve?
Nothing? Again, not all CSs or CUAs need implement the
storage for all of the iCalendar object. Some implementations
can't do recurrence rules - you get an error.

> Otherwise, not only do you have to store the iCalendar, but you have
> to store all the MIME envelopes for all CAP messages as well just in
> case someone decides to include a cid: URI to the ATTACH they included
> with a meeting 6 years ago (oh, did your CS clean up that old data
> already?  oops!)

If you still have the component and the attachment was sent to
you inline - what do you expect to do? How will you decide
to clean those up? It is the same issue. We are NOT mandating
how the CS stores data. We are NOT mandating any cleanup.

We have provided commands so the CU/CUA can decide what to
and when to delete. The CU/CUA can delete components, or
properties from components, or paramaters from properties.
The policy is up to the CU/CUA.

---

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

Doug Royer wrote:

>as the only  body part.
Those are not iMIP implementations.  An iMIP implementation must be a 
MIME MUA, and a MIME MUA must support multipart.

But a CAP CUA is not a MIME MUA.

>No. Not unless it is in the same MIME object (and FTP is not).
So why is MIME privileged? Why must a CUA support cid: and not ftp:? 
There's nothing in iCalendar to require it.

-- 
/=============================================================\
|John Stracke      [email-masked]                    |
|Principal Engineer|http://www.centivinc.com                  |
|Centiv            |My opinions are my own.                   |
|=============================================================|
|"The Elliot 903 was the first portable I ever used, though it|
|needed a furniture van to *make* it portable." --Will Rose   |
\=============================================================/

---

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

>Which include ALTREP and ATTACH.
Requiring that the CS store ALTREP and ATTACH does not mean requiring it 
to store what they point to.

---

From: "Graham Gilmore" <[email-masked]>
Date: Tue, 10 Sep 2002 18:04:08 -0400

> CAP to those implementations.

    (a) CAP derives from iTIP, not iMIP.

    (b) While we have precedent for having different levels of capability
with CAP-QL, the assumption is that full support is a superset of CAP-MIN
(or whatever it's called), whereas it's not clear here in this discussion
that a CS or CUA that supports generating multipart MIME messages ("full"
support) must also support not doing so ("minimum" support) as determined by
the capabilities reported by the other party (in fact, someone mentioned an
example where a CS/CUA reports, in essence, "I support *only* multipart
MIME").

> can't do recurrence rules - you get an error.

    I would expect that the generator of the message with the CID would make
the referenced message publicly available so that it could be accessed
externally; otherwise, it should not generate such a message (unless both
parties agree that it is acceptable, via capabilities).
    The analogy with iCalendar implementations without RRULEs is flawed.
RRULE is not an optional part of iCalendar, and such an implementation is
incomplete; whereas I seem to see people saying that CAP should have the
multipart thing as a MAY.

> how the CS stores data. We are NOT mandating any cleanup.

    My point is not that stuff may be cleaned up improperly, but more
broadly that this feature will require a full-featured CAP server to also be
a MIME message repository, by creating new interdependencies between
iCalendar data and the MIME envelope it was transported in (which otherwise
the CS could simply discard).  This complicates the implementation of all
sorts of things, such as cleanup, due to the new dependencies.
    While a CID referring a different part inside the same message is, in
actuality, not a *huge* problem (having the iCalendar parsing code actually
drive the MIME parsing code rather than simply using them as pipeline stages
would allow the extraction of an ATTACH or ALTREP from the MIME envelope;
ugly & doable, although this means that one would no longer be able to take
off-the-shelf MIME and iCalendar libraries and throw them together with a
bit of chewing gum, which is really unfortunate), the scary part is John's
mentions of CIDs (or MIDs) referring to *other* messages, as one can no
longer simply toss the MIME away anymore.
    It also raises the question, just what exactly does iCalendar consist of
then?  Is it purely the textual format specified in RFC 2445, or is does it
more broadly include all other MIME parts referenced by that text that might
be inside the same MIME envelope, but are not necessarily "text/calendar"?
Doug seems to be saying that ignoring the other MIME parts is akin to
ignoring RRULEs inside a VEVENT.  To me, it's quite a different beast.
iCalendar already has a mechanism for including things inline (if you must);
it's called base64 encoding.  Why not simply use that?

    Graham

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 18:01:23 -0600

>     (a) CAP derives from iTIP, not iMIP.

CAP and iMIP are both derived from iTIP. iMIP adds no iCalendar
functionality. iMIP is only a transport just as CAP is a
transport (plus storage access).

And from iMIP implementations we can tell that adding attachments
and using ALTREP is used in implementations. I could iMIP you,
and your CUA could not store it? That is the reason I relate iMIP
to CAP.

> support) must also support not doing so ("minimum" support) as determined
> by the capabilities reported by the other party (in fact, someone
> mentioned an example where a CS/CUA reports, in essence, "I support
> *only* multipart MIME").

I did propose the MULTIPART capability reply where each side
in the capability exchange specifies if it can support multipart
or not. I would suspect that if a CS has a multipart object
and the CUA can not handle that, it gets an error instead
of the object. Or would it only get the text/calendar body
part and not be able to resolve the CIDs and MIDs?

> parties agree that it is acceptable, via capabilities).

That is not practical. Most users can not export public files
from inside their firewall. That would break ATTACH and ALTREP.

In fact many users do not know how to export a file inside
their firewalls. However ATTACH works for them.

> multipart thing as a MAY.

You need to re-read the iTIP restriction tables, RRULE is optional
in an implementation.

And I agree multipart should be a MAY. However if your CUA and CS
supports multipart and you deposit a multipart object, I think we
have to say that a non-multipart CUA can't read it or is unable
to resolve the CIDs and MIDs.

> broadly that this feature will require a full-featured CAP server
> to also be a MIME message repository, by creating new interdependencies
> between iCalendar data and the MIME envelope it was transported in
> (which otherwise the CS could simply discard).  This complicates the
> implementation of all sorts of things, such as cleanup, due to the
> new dependencies.

I think that we agree on that point.

> actuality, not a *huge* problem (having the iCalendar parsing code
> actually drive the MIME parsing code rather than simply using them
> as pipeline stages would allow the extraction of an ATTACH or ALTREP
> from the MIME envelope; ugly & doable, although this means that one
> would no longer be able to take off-the-shelf MIME and iCalendar
> libraries and throw them together with a bit of chewing gum, which is
> really unfortunate), the scary part is John's mentions of CIDs (or MIDs)
> referring to *other* messages, as one can no longer simply toss the MIME
> away anymore.

Yes - it complicates things.

There are off the shelf MIME parsers that can handle
CIDs and MIDs. And I have no idea if there is an off the shelf
iCalendar parser that supports CIDs and MIDs.

> then?  Is it purely the textual format specified in RFC 2445, or is does
> it more broadly include all other MIME parts referenced by that text
> that might be inside the same MIME envelope, but are not necessarily
> "text/calendar"?

As long as I have been on this mailing list (many years), when
people talk about calendaring, they are also talking about being
able to use alternate representations (you don't have iCal, so I'll
also send you text - multipart/alternate?) and attachments as viewed
by the user in all(?) GUI mailers. 

> iCalendar already has a mechanism for including things inline (if you
> must); it's called base64 encoding.  Why not simply use that?

Because iCalendar also allows for external attachments.
And because iCalendar also allows for external ALTREP.

---

From: Gary Frederick <[email-masked]>
Date: Wed, 11 Sep 2002 06:24:31 -0500

Doug said 'CAP is a transport (plus storage access).'  Yes - a short statement.

I consider that statement key to any conversation we are having. If CAP does not support full featured CS and minimal CS implementations, it's uhhh... less useful.

I want to be able to use CAP to connect servers and clients. What I want to communicate is calendar info. If part of the info requires multipart whatever and CAP doesn't support the communication, 'In My Opinion' CAP is not doing a good job.

If a full featured CAP CS can not transport multipart calendar info and can not access it from it's store, is it providing what we want CAP to provide?

Gary

Doug Royer wrote:
>>>>example) by a cid: URI in an ATTACH property or a property with an
>>>
>>ALTREP
>>
trim

---

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

>parties agree that it is acceptable, via capabilities).
No, that's not necessary.  If I send you a multipart MIME message 
containing an iMIP text/calendar that uses a cid: to point to a 
different part of that message, then your MUA has the entire message 
that's being referenced, and can store it, and dereference the cid: for 
your CUA on demand.  It is not necessary for the body part to be stored 
in the CS.

This type of MUA/CUA integration is out of scope for CAP proper, though 
it might be considered to be implied when one builds an iMIP endpoint 
that uses CAP to store its calendar.

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/

---

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

Doug Royer wrote:

>also send you text - multipart/alternate?)
>
But, by definition, things that are done to support people who don't 
have iCalendar are out of scope for iCalendar.

You're talking about how people with MIME MUAs communicate; that's 
useful for MUA implementers to know, but it's not part of iCalendar.  It 
is entirely clear from 2445 that iCalendar is not tied to MIME.

---

From: Doug Royer <[email-masked]>
Date: Wed, 11 Sep 2002 10:22:25 -0600

> is entirely clear from 2445 that iCalendar is not tied to MIME.

No, I am talking about making a CUA as useful as a modern MUA.