Subject: iTIP updates

From: [email-masked] (Steve Mansour)
Date: Tue, 31 Oct 2000 08:42:41 -0800

Hi All,

Here are the list of iTIP updates.  Somebody made a suggestion for #2
(I think it was George Babics) about an additional use for the
ATTCOUNTER parameter -- there was some other situation where we needed
to determine who was doing an action -- I think it had to do with
delegation.  But I didn't add it to this list. Whoever it was please
reply so we can review it and put it in if it makes sense.

Also, if you are aware of any other problems in iTIP/iMIP, now is a real
good time to send them to the group or to me.  I'll have an updated
draft submitted in time for the San Diego meeting.

-Steve
  ------------------------------------------------------------------------

1. Overloading iTIP REQUEST:

     Problem: Currently, the REQUEST method is used for invite,
     reschedule, update, confirm, reply to refresh. A reschedule
     and/or update are semantically different than a confirm or a
     reply to REFRESH.

     Proposal: Add a new method: CONFIRM. It would be used to (a)
     reply to a REFRESH and (b) notify participants of any changes
     to ATTENDEE or ORGANIZER. All other "reschedule" or "update"
     changes MUST use REQUEST method.

2. Identify sender of iTIP COUNTER:

     Problem: You can't identify which Attendee a COUNTER message
     came from because all of the Attendees will appear in the
     component.

     Proposal 1: Restrict the COUNTER message so that it can only
     specify the ORGANIZER and countering ATTENDEE.

     Note: You can still forward (party crashing, remember? :-) or
     delegate a REQUEST to change participants. However, only the
     ORGANIZER can remove a participant. The down side to this
     approach is that you can't change the Attendees. This removes
     functionality. The up side is that it requires no changes to
     iCalendar.

     Proposal 2: Add a new parameter to the ATTENDEE property:
     ATTCOUNTER. It can only be specified (a) when the component
     method is COUNTER and (b) for the one Attendee who issued the
     COUNTER.

     Note: The good news is that no functionality is lost -- you
     can suggest a different attendee list. The down side is that
     we have to update iCalendar with a new parameter.

     The group concensus for solving this problem is Proposal 2.

3. Adding/deleting ATTENDEEs

     Problem: If the Organizer adds or deletes an ATTENDEE, do they
     really have to send the reschedule to all of the other
     ATTENDEEs? The iTIP specification is not clear on this point.

     Proposal: No, the Organizer can send the REQUEST w/the new
     ATTENDEE info to just the new ATTENDEE. It is up to the CUA.
     It is an implementation dependent issue if the SEQUENCE number
     needs to be incremented when you add/delete an ATTENDEE.
     iCalendar does not require an updated SEQUENCE number if a new
     ATTENDEE is added so this won't break iCalendar as it stands
     today.

4. Intolerant iMIP receivers.

     Problem: MIP specifies numerous MIME encapsulations for
     iCal/iTIP msgs. It doesn't require that an implementation MUST
     be able to receive each of them. This is leading to interop
     problems.

     Proposal: A conforming iMIP implementation MUST be able to
     receive each of the MIME encapsulations shown in the iMIP
     examples. It does not have to GENERATE them, but it must be
     able to RECEIVE them.

5. Garbage Text

     Problem:  The text "Error! Bookmark not defined." was found as
     a standalone line in a couple of the examples.

     Proposal:  Remove these lines.