Subject: iMIP Interoperability Dilemma

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
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: John Stracke <[email-masked]>
Date: Fri, 29 Jan 1999 02:13:35 +0000

Frank_Dawson/CAM/[email-masked] wrote:

> Currently, the iMIP

I think that's is the key point: the constraints on a recipient are greater than
the constraints on a sender.  (Standard IETF folk wisdom: be conservative in what
you send, liberal in what you accept.) The spec should probably be updated
(eventually) to say that implementations MUST accept incoming multiparts.

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
[email-masked]|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/