Subject: Re: Correct handling of Recurrence-id

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

Doug wrote on 05/29/2003 05:18:14 PM:
> > If UID/RECURRENCE-ID is the primary key for finding an instance of a 
> > repeating meeting then how can you find it the next time its 
rescheduled 
> > (ie: SEQUENCE is rev'd) since you claimed last week that RECURRENCE-ID 

> > is changed to the new DTSTART value when the instance is 'booked'??
> 
> The key is UID/SEQUENCE/DTSTAMP/RECURENCE-ID.

NO it is NOT!!  Go re-read iTIP, Section 2.1.5 Message Sequencing!

The primary key is UID/RECURRENCE-ID.  The secondary key is SEQUENCE. When 
both the primary and secondary keys match existing data then DTSTAMP is 
used as a semi-tertiary key.  Any other ordering is incorrect!

> And the start time of any instance may be unique to that key.

DTSTART is NOT a factor in determining instance identification OR message 
sequencing and as such is not related to any kinds of keys used.  Why not 
you may think?  Simple, if you change the keys you cannot find the proper 
entry/instance...

> And the instance start time may be different per UID/SEQUENCE. That
> is 100% of all instance start times in SEQUENCE:0 may be 100% different
> in SEQUENCE:1.

Not 100% accurate.  Had you said UID/RECURRENCE-ID/SEQUENCE I would have 
agreed with the first bit though.

The UID and RECURRENCE-IDs NEVER EVER EVER EVER change no matter the other 
values because if you change the primary key to find an instance you dont 
find the same instance again! 

This is NOT a new topic; we covered it back in 1999 when Dan Hickman 
started the "Recurrence ID changes?" thread.  I suggest that folks reread 
that thread since we did NOT make RECURRENCE-ID changable back then (for 
what I consider to be quite obvious reasons...).

> So an iCalendar CANCEL object with 
UID/SEQUENCE:5/DTSTART/RECURRENCE-ID:monday
> has NO meaning if you do not already have the UID/SEQUENCE:5 object.

Lets just stay focused on the simple REQUEST/REPLY process shall we?!  We 
can look at other examples after I see the iTIP data that you think works 
for the scenario we started already.

Please show me the iTIP that makes a changing RECURRENCE-ID work for the 
missed REQUEST cases (or the general latency case).  Please!

>  > Ive shown how
> > it works in the fixed RECURRENCE-ID case last week but Ive yet to see 
> > the actual iTIP properties that would be sent in the delta case. Could 

> > you please demonstrate that??
> 
> As far as 'delta'. The ORGANIZER sends out the latest copy with a new
> SEQUENCE when any of the relevant (as defined in 2445/2446) properties 
change.
> The CUAs then REPLY. You do not need to track 'delta's.

If Tom missed SEQUENCE:1 then how could he properly recalculate the 
RECURRENCE-ID like you suggest?  He has NO way to 'backtrack' down the 
chain of different RECURRENCE-IDs that happen after each SEQUENCE change.

> If the CUA does not REPLY the ORGANIZER can re-send or ignore that fact.
> If later the SEQUENCE gets updated again, the ORGANIZER would send
> the SEQUENCE:<next> object and the CUAs REPLY.

This does not address how the CUA would match the changed RECURRENCE-ID to 
the correct instance in the set.  If the RECURRENCE-ID changed at each 
change of SEQUENCE as you claim then the CUA can only process the latest 
REQUEST if they have _all_ of the previous REQUESTs too so they can say 
"RECURRENCE-ID changes to Wednesday for SEQUENCE:1.  Now it changes to 
Thursday for SEQUENCE:2.  Finally it changes to Friday for SEQUENCE:3". If 
ANY of the REQUESTs between SEQUENCE:0 and SEQUENCE:3 are missing then its 
not possible to properly determine which Friday instance the Organizer is 
referring to.  Right?

> You never need to track deltas. A CUA saves the latest SEQUENCE
> and applies ADDs and CANCELs to that.

Please show the iTIP properties on how Toms CUA would deal with a missed 
SEQUENCE message.  Ive asked before for it and Ive waited almost 2 weeks 
for some but nothng yet.

I do agree about tracking deltas not being need in general though as each 
iTIP message is a complete snapshot (excluding REPLYs and CANCELs) of the 
entry or instances involved.  However the only way to get from 
"RECURRENCE-ID on Wednesday for SEQUENCE:1" to "RECURRENCE-ID on Friday 
for SEQUENCE:3" is to apply the missing DTSTART value from SEQUENCE:2 that 
you never got. 

I strongly suggest that anyone who thinks that RECURRENCE-IDs change go to 
the archives and search a bit on RECURRENCE-ID and check out Dan Hickmans 
thread from 1999.  There may be others but its clear that RECURRENCE-ID 
cannot change if you ever expect to be able to correctly identify 
instances when missed messages are involved.

In the mean time Ill wait for Doug to provide the iTIP examples like Ive 
already done.  Perhaps he can show how changing the primary key can 
work...

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

---

From: "Chris Olds" <[email-masked]>
Date: Thu, 12 Jun 2003 13:28:45 -0700

As a relative newcomer to the wooly world of calendar exchanges, I find that
my interpretation of iTIP is simpler than either of Bruce and Doug's (as far
as I understand them, at least).

My mental model is that an application that uses iCal objects must manage them
in a versioned manner.  Objects are identified by UIDs, and the version of an
object is identified by SEQUENCE numbers.  If I get REQUEST containing an
object (or objects, but since they must all share the same UID, I'm going to
treat them as a single object), then I look at the SEQUENCE of the object I
just got.  If it is greater than the value I have, I need to update my
schedule.  If the SEQUENCE is the same as mine, it's an update to the details
(so I may have new/more/less/different data to save, but no calendar changes)
and/or a request for a reply (via "ATTENDEE;RSVP=TRUE").  If the sequence is
less than mine, then I may discard it, since I know it is stale.  Processing
updates to the calendar (i.e., those with ANY sequence number greater than the
one I have for that UID) simply requires that I be able to (at most) find the
calendar entries generated by the object with that UID.  Since a REQUEST will
generally (always?) contain all the data for that event or entry, I could just
delete all the saved data for the old version and replace it with the new version.

Ah, you say, but what about RECURRENCE-ID?!?!

Good question.  In order for RECURRENCE-ID to be useful, it must refer to a
specific version of the object containing it, and both parties must agree on
which one.  If I've got it right, Bruce thinks that the version to use is the
first one (SEQUENCE:0), and Doug is saying that the version to use is the most
recent one.  I believe that "the most recent version" is the correct answer.
My reasoning is that while RECURRENCE-ID is, if present, part of the primary
key to use in finding an instance, it is only valid when used in relation to
the correct version of the object in question.

The problem with using the 0th version of the event to define RECURRENCE-ID is
that I then need to have that value follow along as an instance is modified. 
This has all of the problems of the 'delta' model, and is further complicated
by additions (via REQUEST or ADD) to the instance set.  

I've added my comments in-line, below.

On Thu, 12 Jun 2003 14:23:02 -0400, Bruce_Kahn wrote
> This does not address how the CUA would match the changed RECURRENCE-
> ID to the correct instance in the set.  If the RECURRENCE-ID changed 
> at each change of SEQUENCE as you claim then the CUA can only 
> process the latest REQUEST if they have _all_ of the previous 
> REQUESTs too so they can say "RECURRENCE-ID changes to Wednesday for 
> SEQUENCE:1.  Now it changes to Thursday for SEQUENCE:2.  Finally it 
> changes to Friday for SEQUENCE:3". If ANY of the REQUESTs between 
> SEQUENCE:0 and SEQUENCE:3 are missing then its not possible to 
> properly determine which Friday instance the Organizer is referring 
> to.  Right?

Wrong.  If I got SEQUENCE:0, and then SEQUENCE:3 for UID:xyzzy, I would ask
for a REFRESH of UID:xyzzy, and defer processing until I got SEQUENCE:3 (or
greater, but then the SEQUENCE:3 data would be discarded).   When I have
SEQUENCE:3, I can now use the RECURRENCE-ID (relative to that data) to
determine what I need to change.  I don't need to track the intermediate
changes, since my processing can be as simple as deleting all the data I have
for SEQUENCE:0 before I process SEQUENCE:3 (this is a little too simple to be
friendly, but the idea is sound).

> Please show the iTIP properties on how Toms CUA would deal with a 
> missed SEQUENCE message.  Ive asked before for it and Ive waited 
> almost 2 weeks for some but nothng yet.

When I notice a gap in the sequence, I either have the complete new data (no
RECURRENCE-ID in the REQUEST I got), or I can ask for complete data (by asking
for a REFRESH on the UID).

> I do agree about tracking deltas not being need in general though as 
> each iTIP message is a complete snapshot (excluding REPLYs and 
> CANCELs) of the entry or instances involved.  However the only way 
> to get from "RECURRENCE-ID on Wednesday for SEQUENCE:1" to 
> "RECURRENCE-ID on Friday for SEQUENCE:3" is to apply the missing 
> DTSTART value from SEQUENCE:2 that you never got. 

Ask for SEQUENCE:3, drop the data for SEQUENCE:1 when it comes in, then
process the RECURRENCE-ID relative to SEQUENCE:3.  If you can trace instances
from seq:1 to seq:3 (most likely because they are they haven't changed),
you're free to do so, but I don't see that it's a requrement.  When the
Organizer updates the SEQUENCE, the world is different, and she needs to let
people know.

Please help me understand if this model is broken, and if so, how.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)