Re: Fw: Correct handling of Recurrence-id

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug claimed on 05/30/2003 04:53:56 PM:
> So if SEQUENCE:1 changes 100% of all instances.
> Then SEQUENCE:2 trying to cancel one of the new (SEQUENCE:1 instances.
> 
> You can't becaues you would have no idea what was being canceled
> if the RECURRENCE-ID refer to the SEQUENCE:0 instances.

You can easily if the RECURRENCE-ID
never changes.  

The CANCEL for UID/RECURRENCE-ID has
a higher SEQUENCE value so it obsoletes the previous SEQUENCE data for
that instance.  Even if you never got SEQUENCE:1 you can properly
identify the SEQUENCE:0 instance and mark it CANCELed.  If the SEQUENCE:1
comes in later then its already been obsoleted (by iTIP Section 2.1.5,
Rule #2) and can be safely ignored.

If however you expect to rewrite the
RECURRENCE-ID value for every new SEQUENCE then you run into the same kinds
of problems you do if you miss a SEQUENCE.  Its not possible to recover
NOR can you act on SEQUENCE:2 until you get SEQUENCE:1.  Or more generally,
you cannot act on SEQUENCE:x unless you are currently at SEQUENCE:x-1 and
since a REFRESH is always guaranteed to be at the latest SEQUENCE (x in
this case). 

This topic is going nowhere since this
has been discussed before (July 1999, "Recurrence ID changes?")
and there has been no attempt to demonstrate how it could possibly work
using actual iTIP data. 

Unless Doug or George can demonstate
how to resync, etc using a delta model I suggest we make a strong WG note
to remove the misleading text from the next revision of 2445 and move on.

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