Subject: Re: CALSCH Action Items - - Error

From: [email-masked]
Date: Wed, 12 Apr 2000 10:28:13 -0400

Frank, let me see if I understand what you and Doug are debating.  Here's 
my example.  Say we are scheduling an interoperability test in Boston. For 
this event, I send out calendar requests to the attendees with start and 
end dates and include an attachment that is a map to the facility.  That 
now is a multipart document.  All my client cares about is that it is an 
attachment.  If I am doing this using CAP (eventually), wouldn't I want 
the transport mechanism to handle it (iTIP) instead of the mail transport 
(iMIP).   In a mail message, what handles attachments today? Is it MIME, 
the mail client, or another protocol?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

[email-masked]
Sent by: [email-masked]
04/10/00 02:52 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: CALSCH Action Items - - Error

Doug: 
The support for multipart comes in when we begin to talk about 
interoperability of the scheduling semantics over email. This is where we 
ran into the problem between Lotus Organizer and Microsoft Outlook. I was 
the one who reported it. 
At one of the IETF meetings we addressed this under the discuss of errata 
against iMIP, not iCalendar. It was decided there that a change was needed 
to the iMIP spec. 
Please change it in your "Action Items" document to an iMIP related bug. 
The iCalendar spec interoperates fine without it, but the iMIP spec 
doesn't. 
The fact that the ATTACH property and the ALTREP parameter _can_ specify a 
CID or MID URI (as specified only in examples) for the URI based value 
doesn't mandate that an iCalendar implement MUST support multipart MIME 
entities. Indeed, the MID URI for an ATTACH property could specify an 
message identifier external to the current message. The standard specifies 
that the value is either a URI (which could be other URI types than a CID 
or MID) or an inline binary value. ALTREP is a URI value. Most probably 
NOT a CID or MID URI but more likely a HTTP URI. 
In fact, an iCalendar CUA is very likely to support inlined attachments 
and HTTP type URIs for alternate representation of text content. 
It is a big jump to say that all iCalendar implementations MUST support 
multipart. In fact an implementation that is using iCalendar for 
import/export won't be doing this. The point is that many implementations 
will conform to the RFC2445 just as a content definition. 
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Apr 2000 07:19:48 -0700

[email-masked] wrote:
> 
> Frank, let me see if I understand what you and Doug are debating.
> Here's my example.  Say we are scheduling an interoperability test in
> Boston.  For this event, I send out calendar requests to the attendees
> with start and end dates and include an attachment that is a map to the
> facility.  That now is a multipart document.  All my client cares about
> is that it is an attachment.  If I am doing this using CAP (eventually),
> wouldn't I want the transport mechanism to handle it (iTIP) instead of
> the mail transport (iMIP).   In a mail message, what handles attachments
> today? Is it MIME, the mail client, or  another protocol?

Not sure of your question. If I am using CAP. Then I would use CAP.
The object is still a MIME object and it would include any
multipart attachments. You could fetch the appointment with CAP.
Any inline or multipart attachments would have to be saved and
retrieved via CAP as a multipart MIME object.

If the object (a MIME object) is transported with CAP or iMIP,
it's still the same object and it should look the same. It's
just that in one case it will be moved by store and forward RFC821
and in the other CAP.

How you display it (if that is your question) is not relevant
to the protocol.

And I agree with Bruce's email where he states that a CID or MID
is very likely be the way to include attachments to appointments.

-Doug

> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652
> 
>  [email-masked]
>  Sent by:                                          To:
>  [email-masked]           [email-masked]
>                                                    cc:
>  04/10/00 02:52 PM                                 Subject:        Re:
>                                            CALSCH Action Items - - Error
> 
> Doug:
> 
> interoperability of the scheduling semantics over email. This is where
> we ran into the problem between Lotus Organizer and Microsoft Outlook.
> I was the one who reported it.
> 
> against iMIP, not iCalendar. It was decided there that a change was
> needed to the iMIP spec.
> 
> In fact, an iCalendar CUA is very likely to support inlined attachments and
> HTTP type URIs for alternate representation of text content.
>