Re: MIME encapsulation of multipart responses

[Doug Royer <Doug@xxxxxxxxx>]

> 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.

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.

> As an illustration, RFC 2447 gives an interesting example:
> ...
> 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.

begin:vcard 
n:Royer;Doug
tel;pager:pager@xxxxxxxxx
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A.
version:2.1
email;internet:Doug@xxxxxxxxx
title:Chief Executive Manager
x-mozilla-cpt:;12704
fn:Doug Royer
end:vcard