Frank_Dawson@xxxxxxxxx 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, 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.
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:<part3.msg.970415T083000@xxxxxxxx>":Project
XYZ Review Meeting will include the following agenda items: (a)
Market Overview, (b) Finances, (c) Project Management
...
ATTACH:CID:jsmith.part3.960817T083000.xyzMail@xxxxxxxxx
...
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=<part3.msg970930T083000SILVER@xxxxxxxx>":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
> 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.
>
> -- FrankAttachment:
smime.p7s
Description: S/MIME Cryptographic Signature