Subject: Re: CALSCH Action Items - - Error

From: [email-masked]
Date: Mon, 10 Apr 2000 14:15:22 -0400

Doug:
At the IETF meeting (may in Chicago as you suggest, but I think it was 
Oslo) we discussed errors to iCalendar/iTIP/iMIP. This error was in iMIP.
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. This is the one that specifies how you need to package the 
text/calendar object. This is where it currently only REQUIRES support for 
text/calendar and needs to also specify that you MUST be able to receive 
the text/calendar within a multipart/mixed.
I strongly disagree that this needs to be added as a requirement in 
iCalendar, which is only the specification of a C&S content-type.
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Mon, 10 Apr 2000 10:35:27 -0700

[email-masked] wrote:
> 
> Doug:
> 
> At the IETF meeting (may in Chicago as you suggest, but I think it was Oslo)
> we discussed errors to iCalendar/iTIP/iMIP. This error was in iMIP.
> 

iCalendar specifically supports CID's and MID's, from RFC2445:
If iCal specifies CID's, then iCal MUST mandate multipart/* ?
And it did not.

I do understand that it was iMIP interop testing. That is the
only current interoperability protocol. However the CID/MID
issue is an iCalendar issue, below are excerpts from RFC2445.

>From various parts of RFC2445:

     DESCRIPTION;ALTREP="CID:<[email-masked]>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management

	...

     ATTACH:CID:[email-masked]

	...

   Description: Specific venues such as conference or meeting rooms may
   be explicitly specified using this property. An alternate
   representation may be specified that is a URI that points to
   directory information with more structured specification of the
   location. For example, the alternate representation may specify
   either an LDAP URI pointing to an LDAP server entry or a CID URI
   pointing to a MIME body part containing a vCard [RFC 2426] for the
   location.

	...

   The following is an example of this property with an alternate
   representation of a MIME body part containing the contact
   information, such as a vCard [RFC 2426] embedded in a [MIME-DIR]
   content-type:

     CONTACT;ALTREP="CID=<[email-masked]>":Jim
       Dolittle\, ABC Industries, +1-919-555-1234

> 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
> text/calendar and needs to also specify that you MUST be able to receive the
> text/calendar within a multipart/mixed.
>