Subject: RE: Correct handling of Recurrence-id

From: kiwong <[email-masked]>
Date: Tue, 20 May 2003 17:17:51 -0700

I agree with Bob. I don’t see how recurrence-id will work for “out of
band” iTIP messages if it doesn’t have the original date.

I tested out the Outlook/Exchange and they use the original date as the
RECURRENCE-ID. I assume Notes is using it the same way. For iTIP
interoperability, is it more beneficial to have RECURRENCE-ID as the
original date?

ki

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Monday, May 19, 2003 11:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Correct handling of Recurrence-id

I disagree, the recurrence-id must always refer to the original date. 
 
of the meeting.  Lets say i had a 5 day repeating meeting. However I
invited you to just Monday Tuesday to start with, but for some reason you
have not received the mail yet. 
I now reschedule Thursday Friday to a later time in the day and add you to
the invitee list.   
You now get a sequence 2 invite for Thursday Friday 
Later you finally receive the meeting for Monday Tuesday with sequence of
1. 
If I allow recurrence dates to reset on a reschedule, I can not tell if
the Monday Tuesday invitee was rescheduled to Thursday Friday or if this
is a separate invite. 
_____________________
Note: new email address

[email-masked]

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 May 2003 12:00:07 -0600

I think the terms 'the same' and 'original' are the cause of the
confusion. Two different question were asked.

kiwong wrote:
> 
> 
> I agree with Bob. I don?t see how recurrence-id will work for ?out of 
> band? iTIP messages if it doesn?t have the original date.

The RECURRANCE-ID value is the same as the DTSTART value for that specific
instance in the booked object. It is not always equal to the DTSTART
value of the original object:

   A 1 hour meeting starts on monday at 1pm for 5 days:

     DTSTART: ...monday

   To specify a specific instance the RECURRANCE-ID value
   may be set to a value of ...tuesday.

   So they are NOT the same as the original instance except when
   the instance in the iTIP object refers to the 1st booked instance.

And the DTSTART and RECURRANCE-ID values are not always the same in a
specific iTIP object. It depends on the METHOD value. If you are
METHOD:CANCEL-ing an  instance - yes they must be the same in the
iTIP object.

If you are updating the DTSTART value of an existing (booked) object.
And you are altering the DTSTART value of a specific instance of that
booked object. And you are NOT updating the 1st instance of that
booked object:

    Then the RECURRANCE-ID in an update iTIP object would have
    different values for the RECURRANCE-ID and its DTSTART value.
    The DTSTART value has the NEW instance value.
    The RECURRANCE-ID value has the OLD instance value.

So it IS always the same as the 'booked' object instance.
It is NOT always the same as the DTSTART value in the 'booked' object.
It is NOT always the same in a specific iTIP object.

> RECURRENCE-ID.

Using what 'METHOD:' value?

 > I assume Notes is using it the same way. For iTIP

Only when referring to the 1st instance of a booked object or
using specifc METHOD values.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Wed, 21 May 2003 16:01:59 -0400

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.
_____________________
Note: new email address

Doug Royer <[email-masked]> 
Sent by: [email-masked]
05/21/2003 02:00 PM
Please respond to
"[email-masked]" <[email-masked]>

To
"[email-masked]" <[email-masked]>
cc

Subject
Re: Correct handling of Recurrence-id

     DTSTART: ...monday

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 May 2003 15:10:51 -0600

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

--

---

From: George Babics <[email-masked]>
Date: Wed, 21 May 2003 17:20:08 -0400

According to RFC 2445 an event's current DTSTART is
its recurrence id. Section 4.8.4.4:

    The "RECURRENCE-ID" property is used in conjunction with the "UID"
    and "SEQUENCE" property to identify a particular instance of a
    recurring event, to-do or journal. For a given pair of "UID" and
    "SEQUENCE" property values, the "RECURRENCE-ID" value for a
    recurrence instance is fixed. When the definition of the recurrence
    set for a calendar component changes, and hence the "SEQUENCE"
    property value changes, the "RECURRENCE-ID" for a given recurrence
    instance might also change.

And in RFC 2446, section 3.7.1:

    An instance of a recurring event is assigned a unique identification,
    "RECURRENCE-ID" property, when that instance is renegotiated.
    Negotiation may be necessary when a substantive change to the event
    or to-do has be made (such as changing the start time, end time, due
    date or location). The "Organizer" can identify a specific recurrence
    instance using the "RECURRENCE-ID" property. The property value is
    equal to the date/time of the instance. If the "Organizer" wishes to
    change the "DTSTART", the original "DTSTART" value is used for
    "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
    reflect the change.  Note that after the change has occurred, the
    "RECURRENCE-ID" has changed to the new "DTSTART" value.

George

[email-masked] wrote:
> *Doug Royer <[email-masked]>*

---

From: [email-masked]
Date: Thu, 22 May 2003 10:53:55 -0400

NO.   I mean the initial dates from the inital invitation.
_____________________
Note: new email address

Doug Royer <[email-masked]> 
Sent by: [email-masked]
05/21/2003 05:10 PM
Please respond to
"[email-masked]" <[email-masked]>

To

Subject

--

---

From: [email-masked]
Date: Thu, 22 May 2003 12:14:15 -0400

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 22 May 2003 11:13:33 -0600

> NO NO NO!  That wont work!!  

Yes it does.

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.

So by original - I assume you mean the currently booked instance
and not the SEQUENCE:1 (original)?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 22 May 2003 11:27:05 -0600

> NO.   I mean the initial dates from the inital invitation.

Then no, that will not work as the initial invitation
(say SEQUENCE:1) is out of date.  If the currently
booked entry is SEQUENCE:99, it is possible that
none of the 'original'/'initial (SEQUENCE:1) instances
are the same as SEQUENCE:98. There would be no way
for the CUA to know what instance was being updated.

Put another way, if the update sequence is 99. The CUA needs
to have object/SEQUENCE:98 booked or SEQUENCE's 1-98 in the
cal-inbox in order to know how to apply the SEQUENCE:99
update as the instances in SEQUENCE:99 apply to SEQUENCE:98
not the initial invitation.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 22 May 2003 11:40:11 -0600

[email-masked] wrote:

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

No - not what I said.

--

---

From: [email-masked]
Date: Thu, 22 May 2003 14:55:26 -0400

> > NO NO NO!  That wont work!! 

No it does not.  Follow the example I used on a marker board or paper if 
need be.  The workflow breaks down because you cannot match REPLYs with 
REQUESTs over time esp. if they arrive staggered OR out of order!.. (I 
didnt describe the out of order case, Ill leave it as an exercise to the 
reader to work out since it results in the same mess.  Hint: try working 
thru the example with a RECURRENCE-ID that never changes and see if it 
breaks anything...)

> And you say yes (book it).

I was using 0 and 1 since thats how 2445 defines it but I think I can 
follow along...  This is the original invitation and we have no problems 
here...

> And you say yes (book it)

The text on RECURRENCE-ID that George cited conflicts with that in 
Sections 4.8.5.1 and 4.8.5.2 which say:

                 However, in such cases the original "DTSTART" date MUST
   still be maintained by the calendaring and scheduling system because
   the original "DTSTART" value has inherent usage dependencies by other
   properties such as the "RECURRENCE-ID".

You also both overlook the text in Section 4.8.4.4 that says:

   The date/time value is set to the time when the original recurrence
   instance would occur; meaning that if the intent is to change a
   Friday meeting to Thursday, the date/time is still set to the
   original Friday meeting.

The text clearly and unambiguously says "is still set to the original 
Friday meeting".  At least we got it right here too.  The paragraph that 
follows (Georges citation) conflicts w/this and as Tom, Ki and I claim, is 
in error.

Back to your response:  This was a case where we got it right the first 
time around.  The RECURRENCE-ID is the same as the initial (aka original) 
DTSTART.  So since the RECURRENCE-ID matches one found and the SEQUENCE is 
one less than I currently have I would agree that you can book it. However 
I vehemently disagree that RECURRENCE-ID gets rewritten as the current 
DTSTART though!

>   Nothing matches - the sending CUA is busted.

Wrong.  The CUA is NOT busted!!!!!!  It sent a 100% perfectly valid and 
well formed iTIP REPLY based on the REQUEST it was given so how is it 
busted?!?!

If you had not reassigned RECURRENCE-ID after applying UPDATE '1' you 
would not have this problem; you would easily be able to find it.  This is 
why it cannot change every message.

The real problem is in the way we worded the text George cited: 
RECURRENCE-ID MUST NEVER change once instanciated (see above).  If it 
never does then you can EASILY match the REPLY to the proper instance (no 
matter its current DTSTART or SEQUENCE!).  If it ever does then you MUST 
have _all_ the previous REQUESTs in order to properly locate the proper 
instance of the repeat set. 

Try justifying to users that they can never delete any previous REQUESTs 
because _your_CUA_ MUST have them around in case there are any future 
reschedules!  Ive been down that path before and it just flat out does not 
work!  Users always think "Why do I need that reschedule for Thursday if 
its been moved to Wednesday already?  Ill just remove it from my 
queue/Inbox." and, poof, they delete some.  Perhaps you expect to allow 
them to think they delete it when in fact they never do (or never can)... 
Gee, that sounds like a robust and scalable way to do it.  After all 
iCalendar messages are supposed to be complete snapshots of the instances 
they refer to so its logical to have to keep ALL of the prior reschedules 
around just so you can 'follow the trail' of RECURRENCE-IDs to find the 
correct instance.   Wonder what I was thinking...

> instance (currently booked entry), not the original.

_Why_ MUST it be?  That makes workflow impossible when > 1 reschedule has 
happened (ie: the SEQUENCEs differ by more than 1). 

If RECURRENCE-ID never changes then its easily matched and the proper 
instance is correctly and easily identified.

> and not the SEQUENCE:1 (original)?

I thought I was clear enough but I guess not.  To be totally unambiguous: 
the RECURRENCE-ID value is assigned the DTSTART of the instance when it 
was instanciated and it NEVER EVER changes no matter how often DTSTART 
changes.  So, in my examples (prev. msg) the RECURRENCE-IDs are assigned 
at SEQUENCE:0 and NEVER EVER change no matter when/where you move each 
instance to (separately or as a set).

Simply put another way: UID is never changed once assigned and it uniquely 
and unambiguously identifys the entire repeat set.  RECURRENCE-ID performs 
the same function but it is supposed to uniquely and unambiguously 
identify a particular instance w/in that set!  Since UIDs never change, 
RECURRENCE-IDs shouldn't either...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 22 May 2003 14:24:32 -0600

[email-masked] wrote:
> REQUESTs over time esp. if they arrive staggered OR out of order! ...

Which is why iTIP covers that exact problem. You have to do a REFRESH
or wait until they all come in.

--

---

From: [email-masked]
Date: Fri, 23 May 2003 11:04:34 -0400

> or wait until they all come in.

And by what magic/voodoo does a CUA know it has to send a REFRESH in this 
case? 

Toms CUA got a perfectly valid and legitimate REQUEST to which it sent a 
perfectly valid REPLY.  WHY in the world would it think it needed to do a 
REFRESH before it could send the REPLY??  The SEQUENCE was 0 so why would 
it even remotely suspect that it needed to REFRESH, its the first instance 
of the REQUEST!!

All of this sounds like workflow thrashing and not a recognition of the 
problem.  Ill cover it in detail in the proper sub-thread...

Bruce

---

From: [email-masked]
Date: Fri, 23 May 2003 11:31:35 -0400

> 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

---

From: [email-masked]
Date: Fri, 23 May 2003 12:03:32 -0400

Doug replied on 05/22/2003 01:27:05 PM:
> (say SEQUENCE:1) is out of date. 

Err, it will ONLY work if what Toms says occurs...

>                                There would be no way

This is a 'delta' model!!  It does not work for C&S!  We have no way to 
guarantee that every ATTENDEE got (and kept!) all previous REQUESTs!  That 
is why each iTIP message is a complete snapshot of the instance/entry in 
question. 

Keeping each and every previous message around just is not practical 
(gonna hold 98 copies of that 52 instance 'weekly' repeating entry in you 
16M PDA AND do CAP?!?!  Since each iTIP message is a complete snapshow, 
WHY are the previous entries necessary?  They are ONLY necessary if you 
try to build a 'delta' model and thus roll all the differences forward to 
reach the final value.  But there is no need for doing any of this if the 
iTIP message is a complete snapshot, yes?

Reassigning just the RECURRENCE-ID by following a 'delta chain' is 
ludicrous given that the message is the entire snapshot.  Why make 
RECURRENCE-ID the only 'delta' item??

This strongly smells of an artifact from the initial delta design we had 
(and removed in Chicago I believe; ask Derik, Steve or Frank).  Lets fix 
it (Ill send my proposal next week if I can get back to it and not spend 
more time trying to show why its bad) and move along...

Bruce

---

From: [email-masked]
Date: Fri, 23 May 2003 11:52:54 -0400

I wrote on 05/22/2003 12:14:15 PM:
> Lets see if I can demonstrate that _any_ reassigning of RECURRENCE-
> ID breaks workflow! 

I now realize that in my attempt to be calm and collected in composing the 
example I left off the other side of the example: What it looks like if 
RECURRENCE-ID _is_ fixed when its initially assigned.  Im sorry about 
that.  Ill correct that oversight now and see if that helps those 
disbelivers out there.

Go see the initial example for the Organizers view of the data in case you 
forgot it...  Summarily: I invite Doug, George, Tom and Ki to a repeating 
meeting.  I then rescheduled the entire set to a different day...

>         if Tom did not recieve the reschedule before accepting my 
> initial request then his REPLY accepting just the first instance 
> would look like: 
> 
> How can I as the Organizer match this RECURRENCE-ID to any in my 
> current set (20030611T140000Z, 20030618T140000Z & 20030625T140000Z 
> according to Doug/George)?? 

I claim that that the RECURRENCE-ID set should be (20030609T140000Z, 
20030616T140000Z & 20030623T140000Z) which represent the initial instances 
they were created for. 

If this were the case then I can very easily match Toms reply to the 
instance that was moved to a different date (and/or time).  I can see that 
he replyed to SEQUENCE:0 but Im now at SEQUENCE:1 and thus I can opt to 
resend a new REQUEST for the proper entry:

W 11-Jun-03: 
        DTSTART:20030611T140000Z 
        DTEND:20030611T150000Z 

It may be that Tom did get the reschedule REQUEST and that another REPLY 
is on the way but it not required NOR is it a problem if it is.  His 
second REPLY accepting the RECURRENCE-ID:20030609T140000Z "passes in 
email" as my new REQUEST to Tom gets sent out.  Once his REPLY arrives I 
can easily see that Tom will be at the correct Wednesday meeting. 

For Toms part, he may get a second REQUEST for 
RECURRENCE-ID:20030609T140000Z but since the SEQUENCE matches what he 
already has and so does the DTSTART/DTEND he can treat it as a NOOP (or as 
a possible non-rescheduling update like a change in DESCRIPTION, etc if 
the CUA wants to do a 'diff' of the properties). 

In any case, both Tom and I would be happy because I was easily able to 
match his REPLY to the proper entry and take the best course of action w/o 
accidentally mismatching the REPLY to the right instance.

> RECURRENCE-ID to the new DTSTART' bit gets and makes iMIP workflow 
> (and CAP workflow too) that much more impossible to keep in sync! 

This is NOT a problem if the RECURRENCE-ID never changes.  Go ahead and 
try it... 

If I move the entire set yet again to Thursdays (SEQUENCE:2) and then to 
Fridays (SEQUENCE:3) I would have the following in my calendar:

F 13-Jun-03: 
        DTSTART:20030613T140000Z 
        DTEND:20030613T150000Z 
        SEQUENCE:3 

F 20-Jun-03: 
        DTSTART:20030620T140000Z 
        DTEND:20030620T150000Z 
        SEQUENCE:3 

F 27-Jun-03: 
        DTSTART:20030627T140000Z 
        DTEND:20030627T150000Z 
        SEQUENCE:3

so if Ki now gets around to accepting my Wednesay 20-Jun-03 reschedule 
REQUEST (SEQUENCE:1) and sends me back:

I can quickly and effortlessly see that he missed (or ignored or never 
got) at least 2 reschedule REQUESTs (SEQUENCEs 2 and 3) and I can easily 
resend the correct REQUEST:

        DTSTART:20030620T140000Z 
        DTEND:20030620T150000Z 
        SEQUENCE:3 

Thats never ever guaranted possible in a 'delta' model (see other 
sub-thread from this AM)!  It can only be done reliably 100% of the time 
if RECURRENCE-ID never changes.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 10:09:59 -0600

[email-masked] wrote:
> And by what magic/voodoo does a CUA know it has to send a REFRESH in 
> this case?  

It is covered in iTIP.
If you get an update for SEQUENCE:3 and you have SEQUENCE:1,
do a REFRESH and get the latest copy.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 10:13:08 -0600

[email-masked] wrote:
> In spending some time fuming in traffic last night I realized that Doug 
> / George have reinvented the abominable "Delta" model of workflow for 
> 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).  

No, not correct.
I am simply stating that this problem is resolved in iTIP.

--

---

From: [email-masked]
Date: Fri, 23 May 2003 12:12:18 -0400

> > further updates CANNOT BE MATCHED to the ATTENDEEs view of the 
meetings.

Sorry if I misunderstood you then.  Your other reply reguarding 

> instance (currently booked entry), not the original.

I must have misread your bit on UPDATE 2 then.  Just what does "use the 
RECURRANCE-ID of the UPDATE '1' instance (currently booked entry), not the 
original." mean if it does not mean that the RECURRENCE-ID value is 
changed as each UPDATE is recieved??? 

If the RECURRENCE-ID changes then ONLY if everyone has the entire trail of 
SEQUENCE and RECURRENCE-ID values can matching be possible!  Or is there a 
way to miss UPDATE 1 and still recover? 

Oh yeah, just how would an invitee recover the missing UPDATE 1 from the 
Organizer?  By sending a REFRESH for that SEQUENCE/RECURRENCE-ID? Assuming 
that were true then it becomes encumbant on the Organizer to save off 
copies of every instance ever created in case someone lost one message 
somewhere along the line.  Gee, thats comforting to know.  And if the 
Organizer loses one for some reason??  The entry is effectively never 
recoverable!  Great workflow...

Bruce

---

From: [email-masked]
Date: Fri, 23 May 2003 10:08:41 -0700

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

What Bruce says makes perfect sense. Unfortunately the RFC 2445 (and
2446) are ambiguous regarding the issue.

Let us say an instance of recurrence is changed several times (initial
value at instantiation:r(0), later changed to r(1), r(2), ... r(n-1),
r(n). All we really need are r(0) and r(n) to locate and update the
instance: the other changes do not add any value. Requiring that the
entire "chain " of recurrence changes be seen by each CUA in the correct
sequence creates several unnecessary conundrums without any
corresponding benefits.
  
The RFCs SHOULD be amended/clarified to this effect. 

[email-masked] wrote:

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 12:01:28 -0600

[email-masked] wrote:
> matter where it has been rescheduled to.

Not true.

RECURRENCE-ID is only like UID when the SEQUENCE and UID are known.
So RECURRENCE-ID applies to the verison of the object where UID
and SEQUENCE match the update.

A RECURRENCE-ID by itself has no meaning. Only when the SEQUENCE
number and UID are known does RECURRENCE-ID have any meaning.

A RECURRENCE-ID is an instance of UID (x) SEQUENCE (y). It is
NOT an instanec of UID (x) sequence (0).

--

---

From: [email-masked]
Date: Fri, 23 May 2003 14:06:08 -0400

> do a REFRESH and get the latest copy.

But how could Toms CUA derive the correct RECURRENCE-ID value from the new 
SEQUENCE:3 info?  Also, his CUA has not seen SEQUENCE:2 or 3 yet so why 
would it think to do a REFRESH??  It has no need to!! 

The only time it would need to (in _your_ model) is if it got SEQUENCE:3 
and did not get SEQUENCE:2.   Thats because it has no way to determine the 
proper RECURRENCE-ID value because of the missing SEQUENCE:2.  Im not 

> instance (currently booked entry), not the original.

so are you saying that the REQUEST I send to Tom in response to his 
REFRESH would be different than the initial SEQUENCE:3 REQUEST I sent to 
everyone before?  It would have to be to adhere to what you said before OR 
it the REQUEST MUST contain all the 'links in the reschedule chain' 
between SEQUENCE:1 and SEQUENCE:3 so that Tom could 'follow the chain'.

Based on your text, Im assuming that the RECURRENCE-ID I resend to Tom for 
SEQUENCE:3 would have to be RECURRENCE-ID:20030611T140000Z in for this new 
REQUEST yes??  Thats the only way that Tom at SEQUENCE:1 could ever 
remotely be able to apply the SEQUENCE:3 info and get a new 'matching' 
RECURRENCE-ID of 20030613T140000Z that the rest of us share...  Is this 
accurate?  (This effectively 'skips' the Thursday reschedule at 
RECURRENCE-ID:20030612T140000Z at SEQUENCE:2)

However doing this can cause problems if Tom does get the previous 
REQUESTs to move him up to SEQUENCE:3.  After all in the iMIP world there 
is going to be latency involved.  Well, if not problems at least some odd 
behaviour/results on Toms' end.  Heres why...

Since Tom did actually get SEQUENCE:2 and SEQUENCE:3 he is able to 
recalculate the RECURRENCE-IDs by following the reschedule 'chain'.  So 
now he is at SEQUENCE:3 and RECURRENCE-ID:20030613T140000Z with a 
particular DTSTAMP (hopefully).  He now gets in my new REQUEST to bring 
him up to SEQUENCE:3.  Following the iTIP rules in Section 2.1.5 Message 
Sequencing Toms CUA would see that the new message has a newer DTSTAMP and 
thus should be processed.  The rub is though that the RECURRENCE-ID will 
not match the 'previous' instances (SEQUENCE:2 was 
RECURRENCE-ID:20030612T140000Z).  As such his CUA would have to follow the 
rules and send a REFRESH to me.  This of course would cause the same 
viscious cycle all over again.

However, if Tom had NOT recived SEQUENCE:2 and 3 yet then he could be able 
to process the REQUEST I just sent.

This is not a failure of any CUA since each CUA did the proper thing. This 
is a failure on the base designs part to remove all vestiges of the 
'delta' model because in 1 case it can get Tom into a non-recoverable 
case.

Or did I simply overlook something in following the workflow paths and 
actions??...

Bruce

---

From: [email-masked]
Date: Fri, 23 May 2003 14:17:19 -0400

> instance (currently booked entry), not the original.

This clearly says that for SEQUENCE:3 the RECURRENCE-ID "MUST" be that of 
the SEQUENCE:2.  How is that NOT a delta?!??!?! 

This says for SEQUENCE:3 your RECURRENCE-ID MUST be that of SEQUENCE:2 and 
for SEQUENCE:2 the RECURRENCE-ID MUST be that of SEQUENCE:1.  Thus, to get 
to SEQUENCE:n I MUST have a chain of SEQUENCE values from 0 thru n-1.  If 
RECURRENCE-ID changes then by definition each change (aka delta) MUST be 
available to keep the process working.

> I am simply stating that this problem is resolved in iTIP.

Umm, not its not because iTIP messages are complete snapshots.  As such, 
if there is a breakage the Organzier can send 1 REQUEST with the latest 
definition of the event/instance and that should fix it up.  This is 
technially not possible given your description above since there is no way 
to get past any missing SEQUENCE values and 'derive' the latest 
RECURRENCE-ID since the Organizer simply sends the 'latest' SEQUENCE and 
not any arbitrary one (ie: SEQUENCE:2)..

Can you please show how if Tom misses SEQUENCE:2 and I am currently at 
SEQUENCE:3 that my CUA would/could construct the proper REQUEST to get him 
back in sync w/the rest of us??  I just dont see it...

Bruce

---

From: [email-masked]
Date: Fri, 23 May 2003 14:41:26 -0400

> and SEQUENCE match the update.

Sorry but _that_ is not true. 

Go recheck RFC 2446, Section 2.1.5 Message Sequencing:

   To maximize interoperability and to handle messages that arrive in an
   unexpected order, use the following rules:

   1.  The primary key for referencing a particular iCalendar component
       is the "UID" property value. To reference an instance of a
       recurring component, the primary key is composed of the "UID" and
       the "RECURRENCE-ID" properties.

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

So RECURRENCE-ID is used in conjunction with UID and BEFORE SEQUENCE 
checking.  Why?  Simple: you have to find the right instance before you 
can check if the message is older, newer, etc.!

> number and UID are known does RECURRENCE-ID have any meaning.

Nope, go reread that bit and check the ordering again...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 12:51:51 -0600

[email-masked] wrote:
> But how could Toms CUA derive the correct RECURRENCE-ID value from the 
> new SEQUENCE:3 info?

It does not need to as the SEQUENCE:3 object contains the current
state of the object. iTIP does not have an UPDATE method. The
way that you update is to change something, increment the SEQUENCE,
then send a REQUET to the ATTENDEEs.

> Also, his CUA has not seen SEQUENCE:2 or 3 yet so 
> why would it think to do a REFRESH??  It has no need to!!  

Because that is what SEQUENCE is used for. If you get something
newer and you can not figure it out, do a REFRESH to get
the laest copy and throw your copy away.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 13:37:29 -0600

> can check if the message is older, newer, etc.!

Which was my point!?
You will notice that UID *was* in my sentence you quoted!?
As was SEQUENCE.

> Nope, go reread that bit and check the ordering again...

I do not need to, you correctly quoted the RFC above.
It is only usable when UID and SEQENCE are known.

--

---

From: [email-masked]
Date: Fri, 23 May 2003 18:56:28 -0400

> > can check if the message is older, newer, etc.!

Your ordering of usage/evaluation is whats wrong.  You totally missed the 
implication of Step 1.  UID and RECURRENCE-ID are first used in 
combination to find a set and instance and THEN SEQUENCE is used.

> It is only usable when UID and SEQENCE are known.

SEQUENCE is Step 2.  If you find NO match for the UID/RECURRENCE-ID pair 
then by iTIP, Section 3.2.2 its a new invitation and NOT an update to an 
existing one (this is derived from the 2.1.5 above and 3.2.2 as well; no 
match on the primary key with a new RECURRENCE-ID means its a new 
invitation).

Still, none of this exactly hows the iTIP messages that get sent in your 
view of things compared to the non-delta examples Ive already shown. 

Can you please show me the iTIP fragments that my CUA would send back in 
response to Tom's REPLY??  Note that Toms CUA would not need to send a 
REFRESH for the initial invitation since hes acting on the first one.  The 
quandry Im having is what my CUA would send back to him when I see his 
REPLY is old...  Everything I can imagine that matches your changing 
RECURRENCE-ID causes his CUA to treat it as a second new invitation (see 
iTIP 3.2.2) and thus he gets doubly booked and not resync'd. 

Bruce

---

From: [email-masked]
Date: Fri, 23 May 2003 19:09:08 -0400

> state of the object. 

This has digressed more than a little so Ill try to refocus before I head 
out.

By current iTIP rules (prev. citations) why would Toms CUA know/have to do 
a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value. You now 
say that it would not.  However it would have to IF RECURRENCE-ID values 
changed based on the interim DTSTART values.  In order to properly 
determine the RECURRENCE-ID of SEQUENCE:3 and match it to the existing 
SEQUENCE:1 entry something has to be done.  The ONLY way to follow iTIP 
rules on using UID/RECURRENCE-ID AND THEN SEQUENCE to find the referneced 
instance is to NEVER ALLOW RECURRENCE-ID to change.  Otherwise you have a 
chase where each SEQUENCE change involves 'rekeying' instances and that 
just wont work.

> the laest copy and throw your copy away.

I dont follow you.  If Tom has SEQUENCE:1 and he gets in a SEQUENCE:3, WHY 
does he need to do a REFRESH?  What cant his CUA "figure out" if its a 
complete snapshot?  By the iTIP rules under 3.2.2 he would treat any new 
UID/RECURRENCE-ID pair as a new invitation if not found or as an update to 
an existing entry if found.

The ONLY need I can think of is so that it can get a chain of 
RECURRENCE-IDs to relink everything.  After all per 2446, 2.1.5 Message 
Sequencing:

   3.  "Attendees" send "REPLY" messages to the "Organizer".  For
       replies where the "UID" property value is the same, the value of
       the "SEQUENCE" property indicates the revision of the component
       to which the "Attendee" is replying.  The reply with the highest
       numeric value for the "SEQUENCE" property obsoletes all other
       replies with lower values.

Thus if he gets SEQUENCE:3 and he already has 1 then he can just act on 
the new SEQUENCE:3 REQUEST.  Its totally self contained so why is any 
action apart from a REPLY needed?!?! 

Im sorry but I must be missing something if its not to build a chain of 
RECURRENCE-IDs.  After all a true complete snapshow with a higher SEQUENCE 
value is already defined obsolete "all other replys with lower values". 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Sat, 24 May 2003 10:38:25 -0600

[email-masked] wrote:
> Your ordering of usage/evaluation is whats wrong.  You totally missed 
> the implication of Step 1.  UID and RECURRENCE-ID are first used in 

I missed no such thing. I was not responding to the order of or
combination of checking.

--

---

From: Doug Royer <[email-masked]>
Date: Sat, 24 May 2003 10:36:43 -0600

[email-masked] wrote:
> This has digressed more than a little so Ill try to refocus before I 
> head out.
> 
> By current iTIP rules (prev. citations) why would Toms CUA know/have to 
> do a REFRESH if it got a SEQUENCE:3 and it had a SEQUENCE:1 value.

Because it says so in iTIP.

--

---

From: [email-masked]
Date: Thu, 29 May 2003 16:27:52 -0400

Doug replied on 05/24/2003 12:38:25 PM:
> >  > > checking.  Why?  Simple: you have to find the right instance 
before 
> > you

Ok then I cannot seem to follow your argument about reassigning 
RECURRENCE-ID at all then.  Help me out here.

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'??

If you change the key used to find the instance then how can you use it 
later on, especially if you missed 1 reschedule notice?  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??

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 May 2003 15:18:14 -0600

[email-masked] wrote:
> (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.
And the start time of any instance may be unique to that key.
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.

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.

> later on, especially if you missed 1 reschedule notice?

If your current (booked) SEQUENCE is '1'. Then RECURRENCE-ID in an iCalendar
object that also has SEQUENCE:1 is the start time of the instance
that matches the RECURRENCE-ID value for SEQUENCE:1.

If your current (booked) SEQUENCE is '1'. And you get a CANCEL (or whatever)
for a specific instance, and that CANCEL (or whatever) object has SEQUENCE:2,
then you MUST do a REFRESH which will get you the entire SEQUENCE:2 object.
Only then will you know what UID/SEQUENCE:2/DTSTART/RECURRENCE-ID instance
is being canceled..

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

The ORGANIZER adds instances with the ADD METHOD. Or by sending
a new and complete iCalendar object(s) with the latest SEQUENCE.

The ORGANIZER deletes instances with the CANCEL METHOD.

You can send multiple BEGIN/END:VCALENDAR objects per mime object
for complex ADD/CANCEL.

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

--

---

From: [email-masked]
Date: Thu, 29 May 2003 17:29:09 -0400

> Because it says so in iTIP.

I dont see anywhere in iTIP it says (paraphrasing) "If the SEQUENCE on a 
REQUEST is not just 1 value off from any existing one that the Invitee 
SHOULD / MUST send a "REFRESH" message to get the latest instance". 

If each iTIP REQUEST is the full snapshot of that instance then why would 
a CUA think that it needs to do a REFRESH if the SEQUENCE is only off by 
2?  So what if it missed the Thursday 12-Jun-03 REQUEST at SEQUENCE:2, the 
SEQUENCE:3 Friday is full and more recent!?! 

The only cases in iTIP that call out when a REFRESH SHOULD or MUST be sent 
are, Section 3.2.4 ADD:

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT".  If an "Attendee"
   implementation does not support the "ADD" method it should respond
   with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".

Clearly this is not the case in the rescheduling examples we've used so 
far.  Nor does it deal with the secondary key of SEQUENCE so I dont think 
you are referring to that bit.

In checking Section 3.2.6 REFRESH I find:

   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. The "Organizer" responds with
   the latest description and version of the event.

There is no text or inference here as to exactly when a CUA would want to 
use a REFRESH.  It could be driven by the CU themselves at any point (even 
if the UID/RECURRENCE-ID/SEQUENCE values match what the CU currently 
has!).  It could be driven by some CUA logic that thinks "If the REQUEST 
SEQUENCE value is not exactly 1 higher than what I already have then do a 
REFRESH".  However whats the use in that??  After all, the newer REQUEST 
with a higher SEQUENCE obsoletes the previous REQUESTs. 

From iTIP Section 2.1.5 Message Sequencing:

  So, unless an ADD comes in for a non-existant UID or there is some 
pressing need / desire to issue a REFRESH I fail to see why a CUA would 
send one in the case we've been discussing.  Since its clearly not an ADD 
case I really doubt that Tom or his CUA would want (certainly they do not 
NEED) to issue a REFRESH in response to the SEQUENCE:3 REQUEST. 

  Given that SEQUENCE:3 obsoletes both SEQUENCE:0 thru SEQUENCE:1, why 
would Tom or his CUA do the REFRESH?   The REQUEST that my CUA would send 
in response to the REFRESH would again use the same UID/RECURENCE-ID and a 
SEQUENCE:3 (the same that Tom JUST requested the REFRESH for).  So what is 
he to do then?  Issue another REFRESH??  Round and around we go...

  A REFRESH is not a magic bullet that can solve the fact that every time 
the UID/RECURRENCE-ID key changes the receiving CUA will treat the REQUEST 
like a NEW invitation rather than a rescheduling (per iTIP, Section 
3.2.2.1 Rescheduling an Event).

Bruce