Re: Correct handling of Recurrence-id

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 05/22/2003 01:13:33 PM:
> If SEQUENCE:1 has an instance of MONDAY      <-
ORIGINAL
> And you say yes (book it).
> 
> If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE
'1'
> And you say yes (book it)
> 
> If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY  <- UPDATE
'2'
>   Nothing matches - the sending CUA is busted.
> 
> UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
> instance (currently booked entry), not the original.

In spending some time fuming in traffic
last night I realized that Doug / George have reinvented the abominable
"Delta" model of workflow for repeating meetings!  That
is, in order for ANY new iTIP message to be properly interpreted the recipient
MUST have ALL of the previous messages and treat each one
as a delta change to be applied to the previous one(s) in order to arrive
at the right value(s).  

This "delta" model was quashed
and banished when we first encountered the myriad problems that this introduces
into workflow, etc.  Thats why we declared that all iCalendar objects
be full and complete snapshots of the entrys they represent so that they
can be processed w/o requiring all kinds of extra gyrations or jumping
thru flaming hoops or disembowling of feathered animals on keyboards.

So lets take an couple minutes to analyze
why the "delta" model is the wrong approach to take:

1: We cannot guarantee that every previous
message has arrived at the recipients address.  As such, if any message
_ever_ is lost then the entire workflow breaks down.  Also,
data can arrive delayed and out of order making it impossible for workflow
to be performed accurately (I often get Dougs replys to my notes waayy
before I get my own postings via the IMC list server which gives my threading
agents fits!)

2: We cannot prevent users from deleting
'old' messages nor should we require that _all_ previous messages
be preserved in case we need to perform some new scheduling action.

3: There is no reliable way for a CUA
to tell when the 'last' message in the delta chain has arrived and that
workflow can safely be performed.  There is no magic indicator property
nor can one be safely added.  Otherwise an UPDATE 3 (for above) would
also have it and thus any CUA would mistake UPDATE 2 as the last one rather
than UPDATE 3.  Its a chicken and egg type of problem recognizing
"the last" or actual message to take workflow actions on.

4: The WG burned lots of gray cells
recognizing the fact that the only way to keep workflow functioning was
to make each message a full and complete snapshot for that entry/instance.
 

I strongly believe that after we made
the design choice to make messages full and complete by themselves that
we left in some artifacts of the delta model and that the text that George
cited is one such artifact.  If anyone can show how using a
"delta" model actually will work w/o making workflow seem like
alchemy I would love to read it.  In the mean time I will stand quite
firm in my claim that "Delta is bad!".

As I said before (but it may not have
sunk in so Ill say it again): The RECURRENCE-ID is akin to the UID in its
function.  The UID is fixed and unchanging from the initial assignment
of it and is used to uniquely identify the non-repeating entry or a repeating
instance set.  The RECURRENCE-ID performs the same function but within
the repeat set.  The RECURRENCE-ID is fixed and unchanging from the
initial assigment of it and is used to uniquely identify the repeating
entry no matter where it has been rescheduled to.

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