Subject: Re: Correct handling of Recurrence-id (master object)

From: [email-masked]
Date: Thu, 12 Jun 2003 14:39:23 -0400

Doug wrote on 05/29/2003 06:52:55 PM:
> > Sorry to rain on your parade again but an ADD is NOT called for when 
> > inviting a new ATTENDEE.  The ADD method is defined as:
> > 
> >                  The "ADD" method allows the "Organizer" to add new
> >   instances to an existing event using a single ITIP message without
> >   redefining the entire recurring pattern.
> 
> True and the original example also did that:

Who said Doug and I never agree?...

>    "Now, Bruce wants to invite arnaud to _all _instances of the 
recurring
>     event. Arnaud has no information about this event in his CUA. So I'm
>     assuming Bruce will send him one iTIP request containing the 
"master"
>     event + the exception, right ?
> 
>     What will this request look like in your model ? "
> 
> 
> Yes - you can send them a REQUEST + ADD.

Im NOT ADDing to the repeat set!  As such an ADD method is NOT called for. 
 The text was clear but Ill requote it w/emphasis (and include one more 
tidbit):

                  The "ADD" method allows the "Organizer" to add new
   instances to an existing event using a single ITIP message without
   redefining the entire recurring pattern.
...
   The "UID" must be that of the existing event.

Arnaud is being added to the event set, NOT any new instances.  As such a 
REQUEST + ADD is not a legit set of iTIP messages to send.  Besides, if Im 
just now adding him to the event there is NO way he will have it on his 
calendar yet so that is yet another reason why ADD is not possible here.

As the Organzier I only have to send 1 REQUEST to Arnaud and from there he 
should be able to get in sync w/everyone else.

There is also the difficulty in relying on the ADD method.  When we 
created ADD we had no shipping CUAs that supported that ability.  We added 
it to iTIP because we knew we would eventually need it.  That is also why 
we put in the caveat text under 3.2.4 ADD:

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT".  If an "Attendee"
   implementation does not support the "ADD" method it should respond
   with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".

_No_ other iTIP method has that last line about not supporting it.  We 
added it because currently noone did support it and we wanted to be 
explciit in how to deal with it for interop reasons from Day 1.  If you 
rely on a method that is not widely supported yet to do a basic "Add new 
Invitee" feature then you run a big risk (ignoring the fact that ADD 
cannot be used to send the initial REQUEST, etc).

So since REQUEST + ADD is not a viable answer, could you please show us 
the iTIP that would be sent?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...