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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug said on 05/28/2003 05:59:27 PM:
> It can be done with EXDATE/EXRULE or additional RRULE or RDATE
> properties. The METHOD:ADD can be used in a separate VCALENDAR
> object when details about the meetings (or whatever) can not
> be described in one object.

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.

In the case of adding a totally new
ATTENDEE, they do not have the "existing event" so ADD would
be the WRONG method to use.  In fact iTIP clearly rules that out:

   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". 

(I think the 'must' in line 1 should
have been 'MUST' but thats just me...)

> Also, there is no requrement that all ATTENDEEs
see the exact same object. 

They do however need to see the same
instance information such as DTSTART, DTEND, RDATE, RRULE, etc.  Otherwise
they are all using different repeating set definitions and thats BAD!  They
do not need to share the same ATTENDEE, COMMENT, etc properties though.

> That is you could send each ATTENDEE an object
that only contains them
> in the ATTENDEE list. 

Yep.  (Who says Doug and I never
agree??...)

>              
        You could also send them an object that only
> contains the instances that they will be attendending or are invited
> to attend. 

Absolutely.  There is NEVER a case
in iTIP when we defined a case where REQUEST is used to inform an ATTENDEE
about an event they are NOT invited to (party crashing aside).  

But Arnaud was asking about what iTIP
object(s) would be sent to him to invite him to the entire set...  


>             It
can be done with RRULE, RDATE, EXRULE and EXDATE. Only
> the ORGANIZER CUA would need to know when different objects are sent
> to various ATTENDEEs.

The Organzier CUA doesn't have to know
anything about what was sent; just what to generate.  It does not
need to track the different iTIP objects that get sent out as they are
supposed to be representative of the current view of the instance(s) involved.
 Once sent, the CUA has no need to keep track of the actual messages
contents as it can easily rebuild it and resend it as necessary...

If a CUA keeps copies of all iTIP messages
sent to all ATTENDEEs in a repeating event then Id be more than a bit concerned
about the bloating that would occur as rescheduling happens.

I have yet to see any answers to my
previous questions about what exact iTIP properties get sent to do resyncing
in the model Doug advocates.  Did I miss them?

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...