Re: Correct handling of Recurrence-id

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug replied on 05/21/2003 05:10:51 PM:
> > Don't even reference DTSTART.
> > The values for RECURRANCE-ID in any future reschedule/update
or counter 
> > must be the dates rolled from the chairs Original meeting invitation
> > RRULE/RDATE/EXRULE/EXDATE.
> 
> Yes, and I assume by 'original' you mean currently booked version
of
> the object, as the 'original' may be of date (updated already).

NO NO NO!  That wont work!!  

Doesnt anyone here think this stuff
thru on paper or on a marker board anymore??!!  Sheesh, I raised this
issue over a year ago and so did someone else but I guess some folks have
short memories.

The RFCs are in conflict in some parts.
 ALL text that says that RECURRENCE-ID changes on reschedules,
etc is WRONG!  IT WONT WORK!  IT 100% BREAKS WORKFLOW IN JUST
3 SIMPLE STEPS!!!!

(Think Im mad, Im not.  Im livid
that some folks are NOT thinking a scenario thru and seeing that this is
broken!  All except Tom and Ki and maybe Andrea if hes lurking still...
 Ok, deep breath... Again... Continuing...)

Lets see if I can demonstrate that _any_
reassigning of RECURRENCE-ID breaks workflow!

I want to invite Doug, George, Tom and
Ki to a repeating meeting that starts on 09-Jun-03 from  9AM EDT thru
10AM EDT and it repeats for 2 more Mondays (16-Jun-03 & 23-Jun-03).
 The relevant property values in the REQUEST are:

M 09-Jun-03:
        DTSTART:20030609T140000Z
        DTEND:20030609T150000Z
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:0

M 16-Jun-03:
        DTSTART:20030616T140000Z
        DTEND:20030616T150000Z
        RECURRENCE-ID:20030616T140000Z
        SEQUENCE:0

M 23-Jun-03:
        DTSTART:20030623T140000Z
        DTEND:20030623T150000Z
        RECURRENCE-ID:20030623T140000Z
        SEQUENCE:0

I send the invitations to everyone and
wait for responses.  I then find out that Tom and George both have
conflicts so I decide to move the set to Wednesdays (11-Jun-03, 18-Jun-03,
25-Jun-03) and send out a reschedule notice.  The relevant property
values in the reschedule REQUEST should be (in my own, Toms and Kis view):

W 11-Jun-03:
        DTSTART:20030611T140000Z
        DTEND:20030611T150000Z
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:1

W 18-Jun-03:
        DTSTART:20030618T140000Z
        DTEND:20030618T150000Z
        RECURRENCE-ID:20030616T140000Z
        SEQUENCE:1

W 25-Jun-03:
        DTSTART:20030625T140000Z
        DTEND:20030625T150000Z
        RECURRENCE-ID:20030625T140000Z
        SEQUENCE:1

From what Ive read it sounds as if Doug
and George would agree with this EXCEPT that once received by each ATTENDEE
the RECURRENCE-ID value would be changed to match the DTSTART value.  If
thats the case then any further updates CANNOT BE MATCHED to the ATTENDEEs
view of the meetings.  

That is, if Tom did not recieve the
reschedule before accepting my initial request then his REPLY accepting
just the first instance would look like:

        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:0

How can I as the Organizer match this
RECURRENCE-ID to any in my current set (20030611T140000Z, 20030618T140000Z
& 20030625T140000Z according to Doug/George)??  There is no match
nor can I rely on the SEQUENCE values either since there is no match.  Perhaps
Doug/George think that the Organizer MUST keep track of ALL possible RECURRENCE-IDs
as each instances gets rescheduled...?? Ugh!!)  So just how can I
correctly tell which instance Tom was accepting?

The more reschedules that have occured
the worse this 'reassign the RECURRENCE-ID to the new DTSTART' bit gets
and makes iMIP workflow (and CAP workflow too) that much more impossible
to keep in sync!

BUT it gets WORSE!  (Yes Virginia,
its true...)

If I had ADDed a new Monday instance
to the repeat set after I rescheduled to Wednesdays (wait for it...) then
I can easily mismatch Toms REPLY to an instance he may not have been invited
to and may not even know about!  The new Monday instance would by
2445 rules be:

M 09-Jun-03:
        DTSTART:20030609T140000Z
        DTEND:20030609T150000Z
        RECURRENCE-ID:20030609T140000Z
        SEQUENCE:2

so I would mistakenly think that Tom
accepted the ADDed entry and has not responded to the Wednesday instances
at all although his SEQUENCE value was less than my current value and thus
Id have to send a new REQUEST to him with the latest Monday info.  This
can be bad, very very bad!

If however the RECURRENCE-ID NEVER EVER
EVER changed once it was instanciated no matter where the instance got
rescheduled to then I can easily match Toms reply to the proper intance
(and know to send him the proper new snapshot of it in a new REQUEST).
 

By now Im sure Doug is replying wth
"Well do you have a proposal" and the answer is yes I do.  Ive
had one for some time but its not fully typed into MSWord and then reformatted
into draft form for the WG (Pat just gave me the converter program a couple
weeks ago).  I am feverishly working on it to fully flesh it out so
that it clearly details the problem with repeating meetings and then describes
the solution.  I expect to post it to the WG sometime next week (I
hate MSWord but I dont have LaTEX on my Win2K box...)

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...
Warning: Dates in Calendar are closer than they appear.