Re: Fw: Correct handling of Recurrence-id

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Arnaud wrote on 06/20/2003 08:34:28 PM:
> Maybe there is some misunderstanding here.  My guess is that
Doug means 
> "Do a REFRESH with just the UID" when you seem to think
"REFRESH with 
> UID/RECURRENCE-ID".

My examples have been how do I resync
a particular UID/RECURRENCE-ID all along.  Thats what "If Im
only invited to an instance (or subset of instances) then would you send
me the entire set now in response to my REFRESH?" means.  

As I noted in my last posting, if Doug
sends me a REQUEST for the entire sequence then all of a sudden Im invited
to all instances and not just 1.  Thats NOT the proper action to take
clearly is it??

Sending a REFRESH that describes the
entire UID does not work for someone whose only coming to a particular
instance or a subset of the entire set.  Cant no matter how ya slice
it.  

> Of course then, what does a REFRESH with just
the UID mean ?

2446 is not vague on this at least to
me.  It says:

   The "REFRESH" method in a "VEVENT"
calendar component is used by
   "Attendees" of an existing event to request an updated
description
   from the event "Organizer". 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.

It means a refresh to either a non-repeating
entry or the entire set defined by the UID.  This should not be ambiguous.
 Ive already responded how it works in the absolute model (that was
~3 weeks ago) but it seems that Doug thinks that a REFRESH w/o any RECURRECE-ID
info it in response to my UID/RECURRENCE-ID REFRESH requst will solve the
problem.  It cant for those not invited to the entire set; unless
you want to now include them on all the instances... %^|

> Do we all agree that, in the case of a recurring
event, it means: "Send 
> me back the whole object: master object with any existing exceptions"
?

2446 says:

               
                     
 The "Organizer" responds with
   the latest description and version of the event.

The discrepancy is what the "master
object" is or perhaps its unclear to some that if the REFRESH is for
a particular UID/RECURRENCE-ID then the REQUEST that is expected back should
be for that RECURRENCE-ID.  This also does not cover the orphaning
of the earlier RECURRENCE-ID either if it changes for each reschedule per
Dougs suggestion.  

This has gone on for way too long and
I think Doug and others are forgetting several important points so Ill
try to get us refocused:

1: We _had_ this kind of disucssion
back in ~July 1999 and we all agreed then that RECURRENCE-ID does NOT change!
 Go check the archives and look for Dan Hickmans thread.

2: Dougs/Georges entire design philosphy
is based on _1_ paragraph in 2445 that contradicts _several_
others in 2445 and 2446.  The paragraph that they seem to be fixated
on for justifying changing RECURRENCE-IDs is one that was left in from
the initial model where we did have a delta model.  After we (the
WG) took a hard look at how workflow was effected and impacted by trying
to recover from missed messages we found we COULD NOT use a delta model.
 Go ask the original authors of 2445/2446 if you dont believe me!

3: The 3rd paragraph under the 4.8.4.4
Recurrence ID Description on p. 108 contradicts the 4th (which I claim
is residual to the delta model) in that it says that RECURRENCE-ID does
not change.  However it is in total agreement with 2446's Section
2.1.5 Message Sequencing where it describes using UID/RECURRENCE-ID as
the primary key to find the instance in question (so you can THEN use SEQUENCE
to determine if the message is older or newer).  It is also in total
agreement with the text under 2446's Section 3.2.2 REQUEST where it describes
how to determine if this is a new invitation or an update (2nd paragraph
after the bulleted list).  So are all these _other_ paragraphs WRONG
too?  Its just common sense that if the primary key changes (ie: RECURRENCE-ID)
then you are NOT referring to the same instance.  Doug keeps talking
about using SEQUENCE to check the RECURRENCE-ID value but no matter what
he wants thats BACKWARDS from the clear and unambiguious steps defined
in 2.1.5 for message sequencing.

4: The authors of the original RFCs
have already implemented and interop tested their products (several products
really) along with anyone else who has done an engine so far.  Did
we all get the model wrong or is someone new just trying to change it now
based on a bit of residual prose?  The standards are ~255 pages combined
so its not unlikely that 1 paragraph could get overlooked in the change
from delta to absolute that we did.  Other mistakes happened and this
is just one more.

5: It can easily be demonstrated that
its not possible to resync a single instance or subset of instances if
the RECURRENCE-ID changes and a single reschedule was missed.  No
delta model solution exists to cover this and thats just one reason why
we long ago changed the underlying model from delta to absolute.

This entire discussion has merely pointed
out that we need to remove the 4th paragraph under the Detailed Description
of RECURRENCE-ID in 2445 so that its totally unambiguous that RECURRENCE-ID
never changes. 

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