Re: DTSTART for recurrence instances

Doug wrote on 12/09/2003 08:33:39 PM:
> Is there any disagreement that these are -also- a valid ways to change 
> the 2nd instance:

I disagree that the semantics of the examples included are NOT instance 
reschedules.  Rather they all are a recreation of the set of instances in 
a recipients calendar.

There is a semantic difference between a reschedule of a particluar 
instance and recreating the entire set of instances. 

The end result of your examples MAY result in the same but it may not be 
for various reasons including:

1: The state of the 1st and 3rd instances are negotiatble separately.  So 
if there was ANYTHING done to them such as changing PARTSTAT (ie: the CU 
DECLINED it) then that information will be lost when the CU recreates the 
instance set using any of the included methods.

2: Given that workflow for instances can occur independently, using any of 
the alternate methods will result in all participation info being reset on 
ALL OTHER instances.  For example, if instance 1 was uncontested by 
everyone and they all ACCEPTed before the Organzier sent any of the 
alternatives reschedules then the iTIP message would result in a higher 
SEQUENCE value for ALL instances, NOT just the second instance.  This has 
2 big drawbacks:

        A) Workflow already done for that instance MUST be redone all over 
again.  That is, although instance 1 was not being rescheduled the invitee 
MUST reACCEPT the new version at a higher SEQUENCE value.
        B) This need to renegotiate applys to ALL other instances in the 
set potentially!  Imagine trying to deal with this resetting of PARSTAT 
while rescheduling 2 separate instances, not just 1.  Users would wind up 
reACCEPTing or reDECLINEing the same instance multiple times for apparent 
reason as _other_ instances are rescheduled instead of the one you 
ACCEPTed or DECLINEd.

3: The RECURRENCE-ID value for the new second instance is NOT the same as 
its original incarination.  It is a new instance as seen by its different 
value.  For example, Method A would create a second instance whose 
RECURRENCE-ID is 2-dec-2003 at 2pm (for those implementations that support 
ADD) and would destroy the original second instance whose RECURRENCE-ID 
was 2-dec-2003 at noon.  This means that there is an effective disjoin 
because:

        A) For those implementations that do not support ADD, there is no 
longer a RECURRENCE-ID:2-dec-2003 at noon; only a 2 instance set for 
UID:XXX.  This means their picture of the repeating set is different from 
the Organziers.  This disjoin may not be readily visible in workflow 
messages so recovery is non-trivial at best.

        B) If one compares the per instance info the RECURRENCE-ID 
property for the second instance of the set will be different (assuming 
ADD was supported).  In the original case, the RECURRENCE-ID stayed at 
2-dec-2003 at noon but in the alternative cases all the RECURRENCE-IDs 
were changed to 2-dec-2003 at 2pm.  Clearly this means the end results are 
NOT equivalent.

> Method A:  Now later ORGANIZER sends iTIP updates to move the second 
> instance
>  from  noon->1pm  and have it at 2pm->3:30pm:

Again, technically speaking this example and the others that follow are 
NOT moving the second instance.  It was recreating the set as 2 instances 
and then adding an instance in between to get back to 3 instances.  That 
is not the same as moving an existing entry.

> Do you agree that these are also valid objects to tell the ATTENDEE of 
> the single instance change?

Again, they do not change the second instance but rather they remove it 
and create a new one.  As show above, this does not always result in the 
equivalent data or view of the set by all parties.  The end result may be 
a 3 instance repeat set on both sides but its not equivalent in that other 
instances are also impacted needlessly.

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