Re: Correct handling of Recurrence-id

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug replied on 05/28/2003 06:08:04 PM:
> At any point in time when a CUA gets an existing UID with a SEQUENCE
> number '1' more than it has, then it just processes the object.

This must be your interpretation of
iTIP.  However I see NOTHING in iTIP that expressly says "1 more
than it has" (even paraphrased)...

> At any point in time when a CUA gets an existing
UID with a SEQUENCE
> number '2' or more than it has, then it MUST do a REFRESH as there
> is no way what so ever to known what a specific RECURRENCE-ID
> means if you do not have the current SEQUENCE.

Umm, this sounds as if you need SEQUENCE
to determine RECURRENCE-ID.  At least thats how I take" to know
what a sepcific RECURRENCE-ID means if you dont have the current SEQUENCE"
because you are predicating the RECURRENCE-ID on a particular SEQUENCE
value.

Unfortunately this is contrary to iTIP
which says:

   2.  The secondary key for referencing
a component is the "SEQUENCE"
       property value.  For components where the "UID"
[and "RECURRENCE-ID" -BK] is the same, the
       component with the highest numeric value for the
"SEQUENCE"
       property obsoletes all other revisions of the component
with
       lower values.

That is, for any given UID/RECURRENCE-ID
key the CUA then uses SEQUENCE to determine if the message is old or not.
 

This does not say use UID to find an
set of instances, then the SEQUENCE to see if I can use the RECURRENCE-ID
and then RECURRENCE-ID to find the exact instance.  This UID ->
SEQUENCE -> RECURRENCE-ID behaviour also assumes that ALL instances
share the same SEQUENCE value.  That really sucks!!  That means
if I reschedule just 1 instance (thus reving SEQUENCE one higher) I MUST
ignore all REPLYs (& COUNTERs) I get for _all other instances_
because the SEQUENCE value changed even though the instances in question
did NOT change!  Ugh!!!  Talk about workflow thrashing/nightmares!

>              
                     
               For all the ATTENDEE/CUA
> knows all of the original instances were canceled in the missing SEQUENCE
> object. You MUST do a REFRESH 100% of the time when your SEQUENCE
number
> is more than '1' out of sync.

ONLY IF YOU SUBSCRIBE TO THE "DELTA"
MODEL!   Yet even doing a REFRESH 100% of the time does NOT SOLVE
the problem.  Here's why:

1: I invite Doug, George, Tom and Ki
to SEQUENCE:0 to 3 Mondays in a row.
2: I then reschedule to 3 Wednesdays
in a row and send a SEQUENCE:1 REQUEST to them.
3: I reschedule again to 3 Thursdays
in a row and send a SEQUENCE:2 REQUEST to them.
4: I reschedule again to 3 Fridays in
a row and send a SEQUENCE:3 REQUEST to them.

There are at least 2 problems with this
situation which are unrecoverable:

A: If the REQUEST from Step 4 arrives
before the REQUESTs from Steps 2&3 then Doug is going to have to send
a REFRESH to me.  I get it and send a new REQUEST at SEQUENCE:3.  However
if he gets this before the others arrive (or after only 1 other arrives)
then what can he do with it?  Nothing!  He MUST send another
REFRESH request.  This will in turn cause another unusable (by Doug)
REQUEST to be resent and the pattern keeps looping.

B: If any single entry in the chain
of reschedules NEVER arrives then there is NO way to recover it using a
REFRESH.  The REFRESH will cause my CUA to send a REQUEST that reflects
the current view of the entry, NOT one that reflects any
missing REQUEST.  As such, NO MATTER HOW MANY REFRESHes get sent by
Doug in response to missing SEQUENCE:2 (or 1), there is NO way to send
the information Dougs CUA would need to rebuild the missing SEQUENCE (and
thus missed RECURRENCE-ID) entry.

iTIP clearly says how a REFRESH works:

               
               The "REFRESH"
method must specify the
   "UID" property of the event to update. A recurrence instance
of an
   event may be requested by specifying the "RECURRENCE-ID"
property
   corresponding to the associated event. The
"Organizer" responds with
   the latest description and version of the event.

[Emphasis mine]  So if Doug missed
SEQUENCE:2 (or 1) then he would send a REFRESH using the UID and RECURRENCE-ID
from the SEQUENCE:3 REQUEST.  I would in turn send back a REQUEST
with the exact same UID/RECURRENCE-ID/SEQUENCE values (since I didnt reschedule
it yet again).  So, Doug now has 2 REQUESTs.  However NEITHER
are usable because there is missing SEQUENCE:2 (or 1) information.

This is precisely why we decided that
each iTIP object would be a full snapshot of the instance in question and
why the key values of UID & RECURRENCE-ID MUST NOT change.  There
is no known way to recover!  REFRESHes will NOT do it...  

This is also why we put the text in bullet #2 in 2.1.5 about higher SEQUENCE
values for the same UID / RECURRENCE-ID pair "obsoletes all other
revisions of the component with lower values.".  So what if you
missed 3 interim messages?  The SEQUENCE:5 data for a given UID /
RECURRENCE-ID is more recent than any of the prior SEQUENCE values!  

Since UID never changes for an entry
or a repeat set and RECURRENCE-ID never changes for an instance in a set
you can ALWAYS just discard ANY prior SEQUENCE entries and be happy!  ALWAYS!

> No tracking of history required at all by the
ATTENDEE.

For a delta model it absolutely is!
 Otherwise you yave no chance to rewrite the RECURRENCE-IDs as the
SEQUENCE value changes so you can properly identify the instance in question.

Also, what good is a REFRESH if its
the 'latest' and you missed 2 or more REQUESTs?? (Your claim at top, not
my misquoting of you...)

> The ORGANIZERs CUA must keep track of who send
REPLY objects
> for each SEQUENCE in both models.

And what good is that??  You were
just saying that a REFRESH object was required when > 1 is missing.
Reread that bit from REFRESH I highlighted above.  Factor in that
a REFRESH has NO SEQUENCE property in it and as such the Organzier would
have no way to even know what SEQUENCE caused the Invitee to need a REFRESH!
 Now please explain to me what good it does my CUA to keep track of
that info in this model.

So the Organzier for some unclear reason
keeps track of responses at each SEQUENCE level but I fail to see what
use that is to know that Ki said hed come to SEQUENCE:0 and SEQUENCE:2.
 Im at SEQUENCE:3 now so whop-de-doo!  ANY workflow from SEQUENCE
values under 3 are stale and should be ignored!  Your CUA could keep
them around not every one finds bloating that useful.  I may want
to know that Ki did respond but to an older version but responses per old
SEQUENCE??  Whatever floats your boat.

Still, that had nothing to do with the
workflow recovers in the model you espouse.  Can you please show me
how a REFRESH magically solves the case of a missed (or purposely deleted
by the CU) entry in the chain?  Perhaps George can chime back in and
rephrse what Doug's said so that its clear.  Or if someone else out
there can show how everything gets resync'd properly when RECURRENCE-IDs
change per SEQUENCE Im all eyes!  Anyone??!!

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