Re: CALSCH Action Items - - Error

[Doug Royer <Doug.Royer@xxxxxxxxxxxx>]

pregen@xxxxxxxxxxxxxxxxxx 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
> 
>  Frank_Dawson@xxxxxxxxx
>  Sent by:                                          To:
>  owner-ietf-calendar@xxxxxxxxxxxx           ietf-calendar@xxxxxxx
>                                                    cc:
>  04/10/00 02:52 PM                                 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