Possible iTIP and iMIP SPRs Found During Interop Work

["Frank Dawson" <fdawson@xxxxxxxxxxxxx>]

Folks:

At the recent IETF CALSCH WG meeting the following was presented by Steve
Mansour and Frank Dawson. These are possible "SPR" identified as a result of
the recent informal iCalendar/iTIP/iMIP interoperability testing that
various vendors have been conducting. I expect that we will find more of
these as we work with the IMC to arrange a more formal "CALCONNECT" event.

Let's discuss these and come to some "triage" and "disposition" resolution.
I would expect that these and any typos will go into a new I-D for these
documents, as a vehicle for tracking and managing these changes. Is this
approach okay?

These include the following:

1) Overloading of iTIP REQUEST
PROBLEM: Current method used for “invite”, “reschedule”, “update”, “confirm”
, “reply to REFRESH”. A “reschedule” and/or “update” are semantically
different than “confirm” or “reply to REFRESH”.
PROPOSAL: New CONFIRM method used to (a) reply to REFRESH and (b) notify
participants of any changes to ATTENDEE or ORGANIZER. All other “reschedule”
or “update” changes MUST use REQUEST method. Change iTIP text to add this
method and to align existing REQUEST method text.

2) Identify sender of iTIP COUNTER
PROBLEM: Can’t identify who COUNTER came from because all of the ATTENDEEs
will appear in the method.
PROPOSAL: (a) Only specify ORGANIZER and countering ATTENDEE in method.
CAVEAT: Can still forward or delegate a REQUEST to change participants.
However, only the ORGANIZER can remove a participant. (b) Discuss this
further on the mailing list, as there may be other solutions that do not
remove iTIP functionality.

3) Intolerant iMIP receiver
PROBLEM: iMIP specifies numerous MIME encapsulations for iCalendar/iTIP
messages. It doesn’t require that an implementation MUST be able to receive
each of them. This is leading to interoperability problems with different
CUAs.
PROPOSAL: A conforming iMIP implementation MUST be able to receive each of
the MIME encapsulations shown in the iMIP examples. Change iMIP text to
clarify this.

4) Adding/deleting ATTENDEE
PROBLEM: If ORGANIZER adds or deletes an ATTENDEE, do they really have to
send the reschedule to all of the other ATTENDEEs?
PROPOSAL: No, they can send the REQUEST with the new ATTENDEE info to just
the new ATTENDEE. It is up to the CUA. It is implementation dependent if the
SEQUENCE number needs to be incremented when you add or delete an ATTENDEE.
Change iTIP text to clarify this. Add an example to illustrate this.