Recurrence-ID issue - Comments from the original authors

Several months ago, I approached the original authors of iTIP to raise the 
issues of Recurrence IDs.  They have, in their busy schedules, come up 
with some points/comments.  I am posting them to the list with their 
permission.

From Frank Dawson and Derik Stenerson:

"We understand that there was a question of  interpretation about whether 
the value for the RECURRENCE-ID property for a  recurrence instance will 
change when the recurrence instance start/end date/time  is modified.

We have read through related email threads about the discussions  on this 
matter and have reviewed relevant sections of the RFC2445/iCalendar and 
RFC2446/iTIP.

Our opinion is that:

1) The issue resides with interpretation of the semantics and  behavior of 
a property for an iCalendar component; which is defined by 
RFC2445/iCalendar alone.

2) The RFC2445/iCalendar is the foundation for the suite of IETF 
calendaring/scheduling RFCs. The purpose of this specification is to 
define the  common semantics and behavior for calendar components, 
properties and parameters  utilized by the companion specifications (i.e., 
RFCs 2446 and 2447). These  companion specifications were never intended 
to be inconsistent from or overriding of the semantics and behavior 
defined by RFC2445.

3) Considerable discussion was held on semantics and behavior of recurring 
events during the IETF deliberations leading to WG consensus around  the 
definition of iCalendar. It is our belief that the intent of this 
consensus  is as follows: 

a) the value for RECURRENCE-ID was agreed to be the date/time  value of 
the original recurrence instance. This value remains unchanged for as long 
as the base recurrence set (or pattern) exists. A rescheduling of an 
individual recurrence instance did not cause creation of new base 
recurrence  set, but only moved the start/end of the specified recurrence 
instance. 

b) An addition of a new recurrence instance to the set would be an example 
of an action that would create a new recurrence set ? e.g. changing a 
Monday weekly meeting to a Monday and Tuesday weekly meeting. This latter 
action  is an example of an action that *might* also cause the values of 
the  RECURRENCE-ID properties for each member of the recurrence set to get 
redefined  (*might* is used here and in the RFC because it is possible 
that occurrences in  the new recurrence set will have the same date/time 
value). But a rescheduling  of a member of the recurrence set would not 
cause such behavior (i.e., change  the value) of the RECURRENCE-ID 
property associated with the rescheduled  recurrence instance. 

This semantic and behavior was settled on because it is imperative in 
order for  an implementation to maintain order and sensibility between the 
original definition  for the recurrence set and exceptions created by 
subsequent rescheduling actions  on the recurrence set. 

To illustrate, consider the consequences if RECURRENCE-ID  changed on each 
reschedule of an instance. Specifically, if the RECURRENCE-ID is  changed 
on each reschedule of an instance, the sender and the recipient have no 
way to accurately know which instance is being referred to if just a 
single iTIP  message was lost or mis-sequenced, or if the message is an 
invitation to a new  instance entirely.  This inability  to distinguish 
invitation, from reschedule, from update is not problematic with  the 
fixed RECURRENCE-ID because it is unambiguous which instance is being 
referred to. 

Both of us remember numerous such use cases being presented to  illustrate 
the conditions and border-cases for such changes to the original 
recurrence instances and the recurrence set.

4) It is worth noting that those discussion in the related WG  email 
threads referring to examples in iTIP are problematic, as section 3 of 
RFC2446 was intended to be illustrative text and was not reviewed as 
thoroughly  as other sections of the RFC for consistency with iCalendar 
semantics or  conformity to iTIP normative sections. This text defines a 
set of examples, or  informational material. Further, this text is known 
to have numerous typographic  errors.

 5) It is also worth noting that the semantics and  behavior confirmed in 
(3), above, is validated by existing  deployed calendaring/scheduling 
systems. A different interpretation of the semantics  and behavior would 
be counter to this practice today. 


In summary, the original intention of the iCalendar specification  was 
that the value of the RECURRENCE-ID for a specific recurrence instance 
would  remain unchanged for the duration of the existence of the 
recurrence set.  Rescheduling individual recurrence instances did not 
cause recreation of the  recurrence set or change the value of the 
RECURRENCE-ID property for the  associated recurrence instance, but only 
involved changes to the start/end of  the recurrence instance.

Frank Dawson and Derik Stenerson"