Subject: Re: Fw: Correct handling of Recurrence-id

From: [email-masked]
Date: Wed, 2 Jul 2003 15:00:16 -0400

Doug wrote on 06/12/2003 04:46:31 PM:
> > You can easily if the RECURRENCE-ID never changes. 
> 
> 1) Unless you do not have it because you joined the event
>     after SEQUENCE:0 was obsoleted.

Not true.  Per iTIP, Section 3.2.2 REQUEST:

   The "UID" and "SEQUENCE" properties are used to distinguish the
   various uses of the "REQUEST" method. If the "UID" property value in
   the "REQUEST" is not found on the recipient's calendar, then the
   "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
   property value is found on the recipient's calendar, then the
   "REQUEST" is for a rescheduling, an update, or a reconfirm of the
   "VEVENT" calendar component.

In this case the REQUEST is for an unknown UID/RECURRENCE-ID and thus its 
a new invitation to a particular instance.  Thats exactly why we allow 
sending RECURRENCE-IDs in the REQUESTs; so particular instances can be 
consistantly and accurately identified and referenced and workflow for 
each instance can occur independent of the workflow on other instances in 
the set.

> 2) Unless NONE of the current instances match up to ANY
>     of the original instances.

"Original instances" = what??  I dont want to misinterpret this...

In the "delta" model it only takes 5 steps to misidentify once instance 
for another as I demonstrated 3 weeks ago.  And thats _without_ changing 
the set!!!!

> You do not have to SYNC - simply do a REFRESH and get the latest object
> version.

I said 'resync', not SYNC (a new METHOD?).  You also seem to agree that 
its impossible to resync a particular instance if you miss 1 rescheduling 
REQUEST in your model; you MUST resync ALL instances in the set!  After 
all thats what a REFRESH w/o a RECURRENCE-ID does, it resends a 'base' 
definition and then you MUST follow it with the current individual 
instance definitions since they realistically wont share the same attendee 
list, agenda, ATTACHments and other details.  However your assumption 
seems to be that all instances share the same SEQUENCE value (they MUST 
for the 'base' defintion to be useful/accurate).  Still though Ive asked 
for more info on this to be sure and I haven't seen any yet.

So far Ive been talking about the case where we are simply doing workflow 
on the original set of instances.  Despite what Doug may claim, 2445 is 
not ambiguous about RECURRENCE-IDs value for this.  It clearly 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 "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.

The 1st paragraph clearly says that the value does not change when the 
instance moves to a different date (and time too really).  The entire 
justification for this "delta" model of RECURRENCE-ID has been the 
highlighted line in the 2nd paragraph.  However if you read it accurately 
it clearly says "recurrence set for a calendar compoennt changes" meaning 
that the set gets changes; NOT the instance gets changed!

A set change is "Every Monday for 5 weeks" to "Every Monday and Friday for 
3 months"; NOT "Lets move the 2nd instance back 3 hours".  At the time we 
wrote that noone was doing set changes and so noone worked thru all the 
scenarios; much like the multipart issues with some CUAs...

So despite claims to the contrary I think some folks have misinterpreted 
"recurrence set... changes" as meaning "instance reschedules" and that has 
lead to the rest of this discussion.  If you take a technical look at the 
basic cases where we are not changing the set then it should be pretty 
clear why RECURRENCE-ID must stay fixed.  Id like to reach a conclusion 
for this before we digress totally into "Well I can change the set to XXX 
instead of YYY so..." or "What about method Z vs Q..." discussion since 
this set changes are much more the exception than the rule.

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: Wed, 02 Jul 2003 16:43:28 -0600

[email-masked] wrote:
> In this case the REQUEST is for an unknown UID/RECURRENCE-ID and thus 
> its a new invitation to a particular instance.  Thats exactly why we 
> allow sending RECURRENCE-IDs in the REQUESTs; so particular instances 
> can be consistantly and accurately identified and referenced and 
> workflow for each instance can occur independent of the workflow on 
> other instances in the set.

To invite an ATTENDEE to a single instance, send
them a REQUEST with that UID, the latest SEQUENCE
and the instance(s) in RRULEs, RDATEs, EXRULEs, and EXDATEs
they are requested to attend and let them reply. (NO RECURRENCE-ID).

No RECURRENCE-ID needed. If you add RECURRENCE-ID to the REQUEST
and call it a new invitation, the ATTENDEE would be unable to
distinguish it from a single instance reschedule where they
have somehow missed the full REQUEST. They would then have
to do a REFRESH and get back the latest copy without
any RECURRENCE-ID in it anyway, so why do it that way? I could
not find a single example or text in iTIP that said you
can do that anyway.

-- 

  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: Doug Royer <[email-masked]>
Date: Wed, 02 Jul 2003 16:46:04 -0600

> for another as I demonstrated 3 weeks ago.  And thats _without_ changing 

No you proposed a new way to invite someone, you did not show
that anything is busted.

> I said 'resync', not SYNC (a new METHOD?). 

No are you saying 'resync' is a new METHOD - I did not use the
word METHOD - only you did in your reply.

> You also seem to agree that 
> its impossible to resync a particular instance if you miss 1 
> rescheduling REQUEST in your model;

NO I SAID IT IS POSSIBLE - DO A REFRESH.

--

---

From: [email-masked]
Date: Thu, 3 Jul 2003 17:00:22 -0400

> they are requested to attend and let them reply. (NO RECURRENCE-ID).

If you are inviting to a single instance there you do NOT include RRULEs, 
RDATEs, EXDATES or EXRULES.  Those are for defining the repeat set.  By 
definition in iCalendar the RECURRENCE-ID _is_ expressly used "to identify 
a specific instance of a recurring" calendar entry.

Since the invitation is for an instance in that set and NOT the entire set 
you do not send them.  They are NOT of any relevance since the REQUEST by 
definition is the full snapshot of the instance in question.

> have somehow missed the full REQUEST. 

Whoa!  Lots of things in that hairball...

First off, each REQUEST is a "full REQUEST".  At no point is a REQUEST NOT 
the full and current defintion of the instance in question. 

Second, by NOT including a RECURRENCE-ID in the REQUEST for the instance 
you give the wrong impression that the REQUEST is for the entire set of 
instances defined by that UID (and associated RDATEs, etc that were 
included at top). 

Also, RECURRENCE-IDs are necessary so that you can properly detect if the 
workflow (ie: REQUEST/REPLY) is for a particular instance, a range of 
instances or the entire recurrence set.  Why do you think the REQUEST 
restriction table has:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.

in it.  The text clearly says "if referring to an instance of a recurring 
calendar component".  Since we are talking about the invitation to an 
instance of the set then this certainly fits the bill and should be used. 
A REQUEST without a RECURRENCE-ID propery is therefore one that is NOT 
"referring to an instnace of a recurring calendar component".  So if Im 
inviting someone to a single instance then Im referring to just that 
single instance and as such my REQUEST must contain the RECURRENCE-ID 
property.

This also jives with the iTIP message sequencing rules that state:

   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.

(emphasis added).  So since the REQUEST is for a particular instance it 
MUST have the proper RECURRENCE-ID property for that instance so you can 
properly distinguish a new invitation from a reschedule (per iTIP Section 
3.2.2 REQUEST).

Still none of this justifys the original claim that RECURRENCE-ID changes 
on each reschedule (paraphrased pretty closely from Dougs May 20th reply). 
 In fact that claim is clearly disallowed by the defintion of 
RECURRENCE-ID in iCalendar:

and the other misinterpreted text:

                                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.

which allows for RECURRENCE-ID changing only for the case where "the 
definition of the recurrence set for a calendar component changes".  A 
reschedule REQUEST does not qualify as a change to "the definition of the 
recurrence set for a calendar component changes", it is merely moving an 
instance in the set around.

>                                        They would then have

No need for a REFRESH if you get a new UID/RECURRENCE-ID.  By applying:

and treating the "UID" reference as "UID"/"RECURRENCE-ID" since its a 
repeating instance (per Section 2.1.5s Rule #1) you will correctly treat 
the new REQUEST as just that, a new invitation and act accordingly. 

Interestingly enough, Doug cited iTIP Section 4.7.2 Bad RECURRENCE-ID as 
another reason to justify using UID then SEQUENCE then RECURRENCE-ID for 
message sequencing but I think the text from Bullet 1 there failed to sink 
in too:

   1.  The component with the referenced "UID" and "RECURRENCE-ID" has
       been found but the "SEQUENCE" number in the calendar store does
       not match that of the ITIP message.

This means that the UID and RECURRENCE-ID do not change when the SEQUENCE 
does.  In fact the text describing case 1 that followed does not say 
SEQUENCE is "higher by 1" or "lower by 1", it merely says "smaller" or 
"larger".  This means that RECURRENCE-ID does change with each SEQUENCE 
change as some believe.

Bullet 2 under that example talks about a found UID and SEQUENCE but no 
matching RECURRENCE-ID and this is likely what gives some the wrong 
impression about using UID then SEQUENCE then RECURRENCE-ID in message 
sequencing.   The description for that bullet says:

   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.

It should be noted that:

1: The initial REQUEST with the unknown UID/RECURRENCE-ID (and yes 
SEQUENCE) will NOT be found and hence is not covered by this case.  It 
simply is treated as the initial REQUEST as described in Section 3.2.2.
2: Just because an invitation to a single instance results in the UID 
being known it does not mean that all instances are known to the invitee. 
As such the new UID/RECURRENCE-ID key is treated like a new invitation 
which it is.
3: This text makes NO mention of changing the RECURRENCE-ID when SEQUENCE 
is changed so its not valid supporting evidence for that claim.

So lets get back to the facts:

1: iCalendar clearly says that RECURRENCE-ID does not change when a 
reschedule of an instance takes place.  The only time RECURRENCE-ID 
"might" change is if the repeat set itself changes.  Reschedules are not 
the same as rerolling the repeat set.
2: iTIP does not say that RECURRENCE-ID changes with each reschedule of an 
instance.
3: The citation from iTIP Section 4.7.2 clearly describes the case where 
UID and RECURRENCE-ID do not change when SEQUENCE does.  Any other reading 
of Bullet 1 there is a misinterpretation.
4: The WG covered this exact question at least as far back as July 1999 
and the concensus then was that it does not change on the reschedule.

Any misinterpretations to the contrary are just that, misinterpretations.

Bruce

---

From: [email-masked]
Date: Thu, 3 Jul 2003 17:27:06 -0400

> No you proposed a new way to invite someone, you did not show

Perhaps you missed my posting that showed how easy it is to break the 
delta model by misidentifying instances in 5 steps.  From my response 
dated 05/27/2003 01:38:43 PM AST:

It can become worse if instances in a repeat set 'cross' at some point 
such that the rekeyd RECURRENCE-ID is shared between different instances 
at different points in time.  The SEQUENCE values could match when the 
overlap happens so then it becomes impossible to accurately tell which 
instance is being referred to at any given time.  To see this, simply do 
the following 5 steps: 

1: Create a 2 entry repeating set for every Wednesday @ a given time. 
2: Reschedule the first instance to the Friday between the two Wednesdays 
(now SEQUENCE:1) 
3: Reschedule it again to the day before (Thursday, SEQUENCE:2) 
4: Reschedule the second instance to the Friday between the two Wednesdays 
(now SEQUENCE:1 and same RECURRENCE-ID) 
5: Reschedule it again to another day. 

So now if a REPLY for RECURRENCE-ID:THURSDAY / SEQUENCE:1 comes in, can 
you tell me which instance it was for AND more to the point what the 
correct new RECURRENCE-ID is??  Didn't think you could, at least not 
accurately... 

Essentially if each instance gets rescheduled to the same RECURRENCE-ID / 
SEQUENCE values at some point then you cannot accurately match the 
invitees REPLY for that UID / RECURRENCE-ID / SEQUENCE to the proper 
instance.

> word METHOD - only you did in your reply.

Not sure how you got that all a sudden when Ive been using that term all 
along and not as a new method.  Simply put, if the RECURRENCE-IDs get out 
of sync due to a missed REQUEST then the invitee and the Organizer need to 
get back in sync (aka resync) so that they can do workflow on the same 
instances and be certain that that both sides are dealing with the same 
data/dates/times/etc.  Doug was the only one to use "SYNC" in any message 
so far...

> NO I SAID IT IS POSSIBLE - DO A REFRESH.

Yes you've said that all along.  So lets get the terminology straight 
shall we?

The invitee is the only party who sends REFRESH messages and thus the only 
party in this who "does a REFRESH" or "full REFRESH" as its been called. 
REFRESH is specifically defined as:

3.2.6 REFRESH

   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.

The Organizers response to a REFRESH messge is to send "the latest 
description and version of the event" which would be in the form of a 
REQUEST.  So far I think we all agree.  As the hilighted description above 
says, RECURRENCE-IDs are used when particular instances are being 
referenced.  In the delta model of things this would _NEVER_ be necessary 
since the only reason to actually do a REFRESH is because the invitee 
needs to get back in sync w/the Organizer.  _ANY_ RECURRENCE-ID used would 
be invalid from the Organizers perspective if the invitee and Organzier 
are out of sync so that negates the whole benefit of REFRESH.  If the 
invitee is current with the Organzier then why would they need to do a 
REFRESH in the first place?  Thus there is no apparent need for REFRESH 
for particular instances.

Now it did appear that Doug was intending to send a REFRESH message 
without a RECURRENCE-ID in it and that was what he means by a "full 
REFRESH" or all other references to "doing" REFRESH, etc.  If Im wrong I 
appologize and Ill await my punishment for putting words into Dougs mouth. 
 However it it should be noted that the only way for a REFRESH on a 
particular RECURRENCE-ID to be of any value is if RECURRENCE-ID does not 
change between reschedules.   The only other alternative reading is that 
someone just decided for no real reason that they wanted to ask for a 
REFRESH just because they can.   All that results in is a new REQUEST has 
the same UID / RECURRENCE-ID / SEQUENCE and a newer DTSTAMP.

Now by NOT using RECURRENCE-ID in the REFRESH message the invitee is 
asking for a refresh of the entire event or set (assuming its a repeating 
entry).  As noted above, if the invitee is just invited to a particular 
instance then the REQUEST MUST contain a RECURRENCE-ID property.  However 
if RECURRENCE-ID change with each reschedule of each instance then there 
is still no way to match up the initial REQUEST for RECURRENCE-ID:XXX at 
SEQUENCE:5 with RECURRENCE-ID:YYY at SEQUENCE:10.  As such the invitee 
thinks they are invited to 2 instances rather than just the single one.

Still, this is all a distraction from the facts that iCalendar was 
misinterpreted (and the parts that directly say RECURRENCE-ID does not 
change were ignored) and that iTIP does NOT say that RECURRENCE-ID changes 
with each reschedule REQUEST (recheck Bullet 1 under Section 4.7.2 and its 
case description if you think otherwise).

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jul 2003 16:48:39 -0600

> 2: Reschedule the first instance to the Friday between the two 
> Wednesdays (now SEQUENCE:1)
> 4: Reschedule the second instance to the Friday between the two 
> Wednesdays (now SEQUENCE:1 and same RECURRENCE-ID)

If a REPLY comes in with SEQUENCE:1 and the current object is SEQUENCE:2
Do the following:

        Did you already send them a SEQUENCE:2 request:

             yes - toss the SEQUENCE:1 reply
                   and wait for the SEQUENCE:2 reply

             no  - toss the SEQUENCE:1 reply
                   and send them a SEQUENCE:2 REQUEST

Problem solved.

--