Subject: RE: Correct handling of Recurrence-id

From: kiwong <[email-masked]>
Date: Thu, 22 May 2003 19:18:00 -0700

> -----Original Message-----
> From: Doug Royer [mailto:[email-masked]]
> Sent: Thursday, May 22, 2003 1:25 PM
> To: [email-masked]
> Subject: Re: Correct handling of Recurrence-id
> 
> 
> 
> [email-masked] wrote:
> >
> > Doug claimed on 05/22/2003 01:13:33 PM:
> >  > >  > 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!!
> >  >
> >  > Yes it does.
> >
> > 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! ...
> 
> Which is why iTIP covers that exact problem. You have to do a REFRESH
> or wait until they all come in.
> 

How does the REFRESH or wait work for Bruce's sample below? 

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?

....

ki

---

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

kiwong wrote:
>  > > No it does not. Follow the example I used on a marker board or paper if
> 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:

Yes.

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

No - send him the newest.

-- 

  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: Fri, 23 May 2003 13:40:44 -0400

> No - send him the newest.

And just how does the the newest one help him if there have been multiple 
reschedules (ie: Moved yet again from Wednesday to Thursday and then to 
Friday)?? 

Does the Organizer have to build a 'chain' of missing ones for Tom to roll 
up into the final value for Friday?  Or was there some interim solution I 
didnt see that shows us how to go from SEQUENCE:0 (Monday) to SEQUENCE:3 
(Friday) and magically caculate the correct RECURRENCE-IDs to match 
Friday?

By your previous example of UPDATE 2 and UPDATE 3, if the RECURRENCE-ID is 
not changed appropriately per reschedule its not possible to find a match 
or get the right value so how would a new, single REQUEST at SEQUENCE:3 
get Tom onto the same page as the rest of us?  Im sorry but I just dont 
see it...

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

---

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

[email-masked] wrote:
> And just how does the the newest one help him if there have been 
> multiple reschedules (ie: Moved yet again from Wednesday to Thursday and 
> then to Friday)??  

ATTENDEE-1 has:
	UID:1
	SEQUENCE:2

Now iTIP does not have an 'update' method. So lets say the ORGANIZER
sends a:

	METHOD:CANCEL
	UID:1
	SEQUENCE:10
	RECURRENCE-ID: monday...

ATTENDEE-1 notices that only SEQUENCE:2 has been processed
and therefore knows to send a REFRESH to the ORGANIZER.
As the latest is SEQUENCE:10, the ORGANIZER sends a "REQUEST"
method SEQUENCE:10 object to the attendee (as defined in iTIP).
Now the attendee has SEQUENCE:10, now the newly received
CANCEL/UID:1/SEQUENCE:10 is irrelevant and can be thrown
away as ATTENDEE-1 now has the latest object.

Now ATTENDEE-1 can REPLY, or COUNTER the SEQUENCE:10 object.

Any instances from SEQUENCE:2 in ATTENDEE-1's calendar that
are not in SEQUENCE:10 are no longer part of that object.
So ATTENDE-1 can COUNTER or delete them.
In iTIP:

    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.

No one needs to know the intermediate objects.

> Does the Organizer have to build a 'chain' of missing ones for Tom to 
> roll up into the final value for Friday?

No. However the ORGANIZER may wish to keep track of who did a REPLY
to the newest SEQUENCE and perhaps re-send a REQUEST with the newest
SEQUENCE in it to the non-responsive ATTENDEE.

Or perhaps the ORGANIZER keeps track of the SEQUENCE value in each
reply to each ATTENDEE. So if ATTENDEE-1 had only replied to SEQUENCE:2,
then the ORGANIZER could optimize their code knowing that if a CANCEL
SEQUENCE:10 were sent to ATTENDEE-1 that the first thing that ATTENDEE-1
would do was a REFRESH. So knowing that ATTENDEE-1 had only done a
REPLY/SEQUENCE:2, could instead of sending ATTENDEE-1 the CANCEL,
instead send ATTENDEE-1 a REQUEST/SEQUENCE:10 avoiding that extra
send/reply loop.

The ORGANIZER controls the object.

 >  Or was there some interim
> solution I didnt see that shows us how to go from SEQUENCE:0 (Monday) to 
> SEQUENCE:3 (Friday) and magically caculate the correct RECURRENCE-IDs to 
> match Friday?

No, simply do a REFRESH and get the latest copy, then the ATTENDEE
can do a REPLY or COUNTER to that object.

--

---

From: [email-masked]
Date: Fri, 23 May 2003 17:10:07 -0400

> Now iTIP does not have an 'update' method. So lets say the ORGANIZER

Lets try to stay focused on the basic example I used before (Monday -> 
Wednesday -> Thursday -> Friday) shall we?  Otherwise we cant reach any 
clear resolution.  Ill be more than happy to consider this new example 
after this one.

So using the example we've already used, Tom has REPLYd with:

M 09-Jun-03: 

but Ive already rescheduled twice more (Wednesday -> Thursday was 
SEQUENCE:2 and Thursday -> Friday was SEQUENCE:3) so Im at:

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

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

F 27-Jun-03: 
        DTSTART:20030627T140000Z 
        DTEND:20030627T150000Z 
        RECURRENCE-ID:20030623T140000Z 
        SEQUENCE:3
by my claims of a fixed RECURRENCE-ID(and backed by the conflicting 
citation from "4.8.4.4 Recurrence ID").  As such I can see that Tom has 
replyed to a stale version of the meeting and I can easily send him the 
correct new REQUEST.

However by your previous claims that RECURRENCE-ID is changed to match the 
DTSTART after the entry is rescheduled ("So it IS always the same as the 
'booked' object instance." and the conflicting citation from 4.8.4.4 too). 
 As such you would be at:

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

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

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

So just how can I tell exactly which instance Tom was accepting??  NO 
RECURRENCE-IDs match.  No SEQUENCEs match.  I guess you could just say 
"Send them all over again" and I resend a new REQUEST with the data from 
above.

However what the heck can Tom do with it?  He has a snowballs chance in a 
microwaves chance of matching up the initial REQUEST he got with the new 
REQUEST.  The UIDs match but NO RECURRENCE-IDs match.  His CUA of course 
would conform to 2446, Section 4.7.2 Bad RECURRENCE-ID which says:

   2.  The component with the referenced "UID" has been found, the
       "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
       found.
[Snip]
   In case (2), something has gone wrong.  Both the "Organizer" and the
   "Attendee" should have the same instances, but the "Attendee" does
   not have the referenced instance.  In this case the "Attendee" SHOULD
   send a "REFRESH" to the "Organizer" to get an updated version of the
   event.

Gee, isnt that exactly what just happened??  Didnt I just send a REQUEST 
that was to be the 'updated version'??  Guess we can just keep looping 
until something special happens and it just works or the meeting passes 
and Tom fails to show up...

> No one needs to know the intermediate objects.

Given your comments about changing RECURRENCE-ID based on the 'booked' 
value of DTSTART they (the invitees) MUST absolutely, positively, 100% 
know them!  Otherwise they can never match them up if they miss ANY 
reschedules!! 

The only way that you do NOT need the intermediate REQUESTs is if the key 
values (UID and RECURRENCE-ID in repeating instances if you read bullet 1 
above your citation) does not change!

> SEQUENCE in it to the non-responsive ATTENDEE.

Ok, I still cannot see how Tom who has:

M 09-Jun-03: 
        DTSTART:20030609T140000Z 
        DTEND:20030609T150000Z 

is going to be able to match it to the newly received REQUEST you send 
that has:

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

The primary key for finding a repeating instance is UID & RECURRENCE-ID 
but these do NOT match between the initial REQUEST and the subsequent 
REQUEST.  So how can Tom get resync'd???

The only way for Tom to be able to get resync'd is if UID and 
RECURRENCE-ID never change.  If you change the primary key, you'll never 
be able to make a match!  (If you change the locks on your house, can you 
get in using the old keys?)

> reply to each ATTENDEE. 

No 'perhaps' about it.  If the id changes, the Organizer MUST so they can 
build a chain to get all invitees to the same view of the repeat set. 
However can easily fail as Ive shown before given the latency involved in 
iMIP and the potential for in-transit loss.  See previous postings today 
on that if need be.

> The ORGANIZER controls the object.

Thats not in contention.  They do however have to obey the constraints of 
the system/model.  For example they cannot decrement SEQUENCE when 
rescheduling; they cannot make the DTEND before the DTSTART, etc.  Ok, 
they CAN if they use notepad or a non-compliant CUA but we are not talking 
about that scenario.  In any case, this has no bearing on the rules in 
question governing RECURRENCE-ID.

> can do a REPLY or COUNTER to that object.

I cant see this working.   Please show me exactly how.  Ill keep asking 
until someone can show me how Tom will be able to resync the correct 
instance to Friday in the case where RECURRENCE-IDs change and he misses 
one or more interim reschedules... 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 15:47:25 -0600

> clear resolution.  Ill be more than happy to consider this new example 

Simply do a REFRESH.
Then it does not matter how many times you update.

--

---

From: [email-masked]
Date: Tue, 27 May 2003 12:54:48 -0400

> Then it does not matter how many times you update.

Umm, the Organizer is NOT the one who sends a REFRESH.  REFRESH is sent by 
invitees who, for whatever reason, think they need to get the current view 
of things. 

As such, I would NOT be sending a REFRESH, Tom would have to.  This of 
course begs the question as to why would he think he has to if he just got 
the initial invitation with a SEQUENCE:0?

As the Organzier I could see that Toms REPLY was for an older SEQUENCE and 
automagically send a new REQUEST with the latest snapshot of the event.  I 
have shown what would be in _my_  resent REQUEST but I have yet to see 
what would be in the one you think should be sent...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 May 2003 11:34:24 -0600

[email-masked] wrote:

> Umm, the Organizer is NOT the one who sends a REFRESH.  REFRESH is sent 
> by invitees who, for whatever reason, think they need to get the current 
> view of things.  

The quote of mine you included is correct.
And you will note the word 'ORGANIZER' is not included in my quote.
We agree.

--