Re: Re-currence ID input from original authors

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

I hope I'm not overstepping any boundaries here,
but there is one question about this model that
I have encoutered that I'm not quite certain how
to resolve and that's inviting a CU to a single
recurring instance for which the CU is not invited
to the recurring set.

According to my read, this CU may not receive a
description of the base recurrence set and
therefore will be unable to verify the recurrence-id
in question.

Should a rescheduling of the base set happen which
would invalidate the recurrence-id that CU had originally
received, then as far as I can tell, the ORGANIZER's CUA
will have to send a cancel of the original instance, and
a new invite to the event with the new recurrence-id.

The only other option I can see is that in the case a CU
is not invited to the base reucrring set, the base
recurrence set description is also provided alongside
the RECURRENCE-ID.

This way, when a CUA receives an object, it can verify
that all existing instances on its calendar (which in
the case of a single invite will be the one with the
wrong RECURRENCE-ID) still exist within the context
of the updated recurrence set.  Since the SEQUENCE
value of the new object will be greater than the
SEQUENCE of the old _AND_ the sets are different, then
any instance whose recurrence-id does not exist within
the new set should be removed.


Otherwise, the only recourse I can see is to send the
CU a request for the base object, and then another one
when the base object is updated - which seems to me that
it runs the risk of being treated as invite, regardless
of whether or not they are listed as an ATTENDEE (for
instance I know that MS Outlook will treat any REQUEST
like an invite regardless of what's listed for ATTENDEE).


This is the only time where I see there could be a problem
since the recipient CUA, which may have never seen the
description of the entire series won't be able to tell
that the existing event it has with the old RECURRENCE-ID
is no longer valid, and the new event it just received
replaces that one.  This problem slightly expands when
you start dealing with invited to certain subsets of
the series.

Again, I am not trying to waste anyone's time, it's just
not clear to me how you communicate a RECURRENCE-ID change
when the CU has only been invited to that one instance.

-- Michael --

"Derik Stenerson" <deriks@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:228A1748305DFF44B964F14B39865A9523CBDF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pat and Bob:



Before the summer holidays, Pat approached the editors of the iCalendar
specification to provide an opinion about an issue of interpretation of
RECURRENCE-ID semantics and behavior that had surfaced in the IETF CALSCH WG
email reflector.



In particular, 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






This posting is provided "AS IS" with no warranties, and confers no rights.



________________________________

From: owner-ietf-calendar@xxxxxxxxxxxx
[mailto:owner-ietf-calendar@xxxxxxxxxxxx] On Behalf Of
pregen@xxxxxxxxxxxxxxxxxx
Posted At: Sunday, August 17, 2003 7:51 PM
Posted To: IETF-Calendar
Conversation: Re-currence ID input from original authors
Subject: Re-currence ID input from original authors



Both Frank and Derik have finished their review of this question and are
putting together the answer for the list.  I do not know what it is yet -
but have asked them to go ahead and post it here directly.  Both of them
apologize for the delay - their work got in the way of the response.  But
it's coming - I promise!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652