Subject: RE: Correct handling of Recurrence-id

From: Arnaud Quillaud <[email-masked]>
Date: Wed, 02 Jul 2003 12:14:44 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 10:28 AM
To: [email-masked]
Subject: Re: Correct handling of Recurrence-id

However, in taking a step back I think that the key to this is a phrase
that seems to have been misinterpreted by some and misunderstood by
others.  Doug and George have cited the following as the basis for
claiming a changing RECURRENCE-ID model: 

                                   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 operative phrase here is "definition of the recurrence set for a
calendar component changes".  This means when the entrys repeat _set_
changes from "Every Monday for 5 weeks" to "Every Thursday and Friday for
3 months", NOT "When the individual instance is rescheduled to a different
date/time."   

When an instance itself is rescheduled, its RECURRENCE-ID
_does_not_change_.  This _is_ coherent w/the paragraph previous to the
citation in 2445 and w/the message sequencing and method interpreation
sections in iTIP because it means the UID/RECURRENCE-ID values do not
change with each reschedule.  As such a single (or 100) missed reschedules
(or CANCELs, etc) can be safely ignored and no "full REFRESH" or full
resyncs are necessary.   

This makes a lot of sense I think.
 
Arnaud

---

From: [email-masked]
Date: Mon, 7 Jul 2003 13:50:25 -0400

Bruce, I think this is a good summary of the recurrence issue.  Hopefully, 
we'll have Frank's note to the list by this week to put an end to the 
discussion and make it clear for everyone. 

So, now, back to the real issue that should be on the list.  Is CAP ready? 
If not, what's wrong/missing/needs clarification/etc.... Keep those cards 
and letters coming.

And, keep it nice!

[email-masked]
Sent by: [email-masked]
07/03/2003 17:49

        cc: 

Doug pondered on 07/02/2003 06:24:20 PM:
>  > ...and so far the discussions were foucsed
> > around the most common and basic model of invitations and reschedules 
to 
> > the initial set.
> 
> I have not seen any one claim that including you in the debate.
> But assuming it is - so what?
 
The point is to put misinterpretations to rest and get on with other WG 
business.  I just do not want some folks misinterpreation of the RFCs to 
become contagious causing us no end of grief to those that read the RFCs 
correctly. 

Lets get back to the facts of this shall we: 

1: iCalendar clearly says that RECURRENCE-ID does not change on a 
reschedule.  For those that missed it the last 4 times: 

   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. 

2: iCalendar has been misquoted/misread by some as saying that the 
RECURRENCE-ID does change on a reschedule.  The misunderstanding stems 
from: 

   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. 

which says that RECURRENCE-ID "might also change" but ONLY for the case where "the definition of the recurrence set for a calendar component changes".  A reschedule of an entry in the recurrence (aka repeat) set is NOT 
changing the set definition!  Changing the definition is going from 
repeating "Every Monday for 3 weeks" to "Every Wednesday and Thursday for 
2 months" (or some other pattern).  Sounds like confusion on the part of 
some between the two. 

3: iTIP does not describe changing the RECURRENCE-ID value on a reschedule 
depsite instances to the contrary.  Section 4.7.2 Bad RECURRENCE-ID says: 

   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. 

In order for the UID and RECURRENCE-ID  to match but the SEQUENCE to be 
"larger" or "smaller" then obviously UID and RECURRENCE-ID cannot be 
changed when SEQUENCE changes or they would never match the correct 
instance in question. 

Section 2.1.5 Message Sequencing clearly states that UID and RECURRENCE-ID 
are to be used as the primary key when sequencing any iTIP message for a 
particular repeating instance.  They are to be combined into a key to find 
the particular instance and then SEQUENCE is to be looked for (as 
described in Section 4.7.2 bullet 1 even).  Missed messages at lower 
SEQUENCE values are irrelevant because they are obsoleted by the newer 
SEQUENCE versions.  As such missed messages are not a problem for workflow 
(unless you need them to change the RECURRENCE-ID values). 

Section 3.2.2 REQUEST clearly describes how to differentiate between a new 
request and a reschedule of an existing one.  If RECURRENCE-ID changed on 
each reschedule then it would be impossible to match it to an existing 
entry correctly.   

Any attempts to change the model so that RECURRENCE-ID changes on each 
reschedule is either a misinterpretation of the RFCs or an attempt to 
change their behaviour that is clearly outlined otherwise.   

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