Subject: Re: iMIP Interoperability Dilemma

From: "John Rose" <[email-masked]>
Date: Thu, 28 Jan 1999 17:52:00 -0800

Frank -

Thanks for your excellent description of the problem.  I think
your
proposal makes very good sense, in that it cuts a little slack
for
implementers who may not have fully understood the importance
of parsing down the MIME tree.  It's easy to misunderstand when
you're new to MIME.

Nevertheless, I also agree that the recipient UA MUST be able
to deal with multipart messages, or else interoperability will
mostly fall apart, and iMIP will be useless.  A revised version
of
RFC 2447 should absolutely REQUIRE this ability on the part of
recipient UA's.  Hopefully apps that don't already conform to
this can be brought into line as quickly as possible.

- JR

-----Original Message-----
From: <Frank_Dawson/CAM/[email-masked]>
To: <[email-masked]>
Date: Thursday, January 28, 1999 07:54 PM
Subject: iMIP Interoperability Dilemma

Folks:

We have uncovered an interesting interoperability dilemma with
at least two of
the major pending iMIP implementations. Let me know what you all
think.

Implementors are probably aware that there are a number of ways
to package or
encapsulate an iTIP message as you send it over MIME email. The
iMIP spec
addresses this with numerous examples. For example, the most
simplist way to
package an iTIP message in MIME email would be as a message
consisting of a
single MIME entity with a content-type of "text/calendar".
Certainly, if you
implement iMIP, you MUST support receiving an iMIP message in
this format.

Another form for an iMIP message would be as a MIME entity
embedded within a
"multipart" MIME message. For example, you might implement a CUA
that sends out
a "multipart/mixed" or "multipart/alternative" MIME message
consisting of one
MIME entity that is a content-type "text/plain" with a "pretty
text" equivalent
of the iTIP request. For example, "Frank Dawson has sent you an
invitation for a
meeting at 11:30 AM EST on 2/2/1999 with the categories of...".
You get the
idea, I hope. And the message would contain a second MIME entity
with the
content-type of "text/calendar" and consisting of the iTIP
request (ore reply,
or cancellation, or reschedulig, or whatever). The advantage of
this type of
message, as described in the section 2.4 of the iMIP spec, is
that it can be
interpreted by both an iTIP enabled MUA and also a legacy MUA
that only
understands basic MIME email. That is, the message on a legacy
system would
include a pretty text explanation to augment the structured iTIP
request. Not a
bad idea. In fact, the iMIP spec indicates that this SHOULD be
used by iMIP
implementations. The key word here, appears to be SHOULD.
Currently, the iMIP
specification is not granular enough to differentiate what a
conforming
"emitter" of iMIP must do, from what a conforming "recipient" of
iMIP must do.

As it turns out, our experience with the existing calendar
vendors that support
iMIP is that some of the significant players have only supported
the most
primitive iMIP message, that is a MIME message of content-type
"text/calendar".

Now, I can see that this might be the preferred form for
outbound iTIP messages.
But it would seem that conforming implementations _ought to_ be
more tolerant on
reading or receipt of iTIP messages; and MUST be able to receive
and actively
process iTIP body parts within a "multipart" message.

There are a number of scenarios that can't be directly supported
unless we all
agree to be more tolerant, on receipt, of different forms of
iTIP messages. For
example, the support of legacy, non-iTIP enabled MUAs listed
above. In addition,
there is the real-world scenario of forwarding of an invitation
that you receive
to a colleague. "Hey, I can't attend this meeting, but you need
to go". This
forwarded message would be sent as a "multipart" MIME message.
No other way to
do it. And if we don't _all_ support receipt of iMIP messages
that are of a
"multipart" type we have done a real disservice to the industry
that has been so
supportive of these Internet calendaring and scheduling
standards efforts.

*** Here is what I propose: ***

We all agree that, even if we can't support receipt of
"multipart" iTIP message
in our current version of our products, we stand up and agree
that we MUST have
support for receipt of "multipart" messages that contain an
imbedded
"text/calendar" body part (or MIME entity) in our products by
the end of 1999.

This is probably one of those lessons-learned from iMIP
interoperability testing
that we need to fold into a revision of RFC 2427.

Let us know where each of you stand.

- - Frank Dawson

---

From: Doug Royer <[email-masked]>
Date: Fri, 29 Jan 1999 12:16:47 -0800 (PST)

Frank,

I agree completely. We will be moving many customers from non-iCal
email applications to new calendaring and web based calendaring.

I think that it is essential that multipart/arternate be supported to
transision our customers. Some of which just have email. As do most
customers of ISPs.

Thanks for bringing this up!

-Doug

> From: Frank_Dawson/CAM/[email-masked]
> Date: Thu, 28 Jan 1999 19:54:22 -0500
> 
> Folks:
> 
> We have uncovered an interesting interoperability dilemma with at least two of
> the major pending iMIP implementations. Let me know what you all think.
> 
> Implementors are probably aware that there are a number of ways to package or
> encapsulate an iTIP message as you send it over MIME email. The iMIP spec
> addresses this with numerous examples. For example, the most simplist way to
> package an iTIP message in MIME email would be as a message consisting of a
> single MIME entity with a content-type of "text/calendar". Certainly, if you
> implement iMIP, you MUST support receiving an iMIP message in this format.
> 
> Another form for an iMIP message would be as a MIME entity embedded within a
> "multipart" MIME message. For example, you might implement a CUA that sends 
out
> a "multipart/mixed" or "multipart/alternative" MIME message consisting of one
> MIME entity that is a content-type "text/plain" with a "pretty text" 
equivalent
> of the iTIP request. For example, "Frank Dawson has sent you an invitation for 
a
> meeting at 11:30 AM EST on 2/2/1999 with the categories of...". You get the
> idea, I hope. And the message would contain a second MIME entity with the
> content-type of "text/calendar" and consisting of the iTIP request (ore reply,
> or cancellation, or reschedulig, or whatever). The advantage of this type of
> message, as described in the section 2.4 of the iMIP spec, is that it can be
> interpreted by both an iTIP enabled MUA and also a legacy MUA that only
> understands basic MIME email. That is, the message on a legacy system would
> include a pretty text explanation to augment the structured iTIP request. Not 
a
> bad idea. In fact, the iMIP spec indicates that this SHOULD be used by iMIP
> implementations. The key word here, appears to be SHOULD. Currently, the iMIP
> specification is not granular enough to differentiate what a conforming
> "emitter" of iMIP must do, from what a conforming "recipient" of iMIP must do.
> 
> As it turns out, our experience with the existing calendar vendors that 
support
> iMIP is that some of the significant players have only supported the most
"text/calendar".
> 
> Now, I can see that this might be the preferred form for outbound iTIP 
messages.
> But it would seem that conforming implementations _ought to_ be more tolerant 
on
> reading or receipt of iTIP messages; and MUST be able to receive and actively
> There are a number of scenarios that can't be directly supported unless we all
> agree to be more tolerant, on receipt, of different forms of iTIP messages. 
For
> example, the support of legacy, non-iTIP enabled MUAs listed above. In 
addition,
> there is the real-world scenario of forwarding of an invitation that you 
receive
> to a colleague. "Hey, I can't attend this meeting, but you need to go". This
> forwarded message would be sent as a "multipart" MIME message. No other way to
> do it. And if we don't _all_ support receipt of iMIP messages that are of a
> "multipart" type we have done a real disservice to the industry that has been 
so
> supportive of these Internet calendaring and scheduling standards efforts.
> 
> We all agree that, even if we can't support receipt of "multipart" iTIP 
message
> in our current version of our products, we stand up and agree that we MUST 
have
> support for receipt of "multipart" messages that contain an imbedded
> "text/calendar" body part (or MIME entity) in our products by the end of 1999.
> 
> This is probably one of those lessons-learned from iMIP interoperability 
testing
> Let us know where each of you stand.

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/People/Doug
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL