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!
Bruce_Kahn@xxxxxxxxxxxxxxxx Sent by: owner-ietf-calendar@xxxxxxxxxxxx
Subject: Re: Correct handling of Recurrence-id
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 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...