[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RECURRENCE-ID / instance reschedule (Was Re: DTSTART for recurrence instances)
Doug wrote on 12/10/2003 03:15:17 PM:
> PLEASE - if you want to talk about the other RECURRENCE-ID issue -
> the subject line. How you derive RECURRENCE-ID from a given object
> EXPAND:TRUE and how it effects DTSTART is NOT the same as
> if (or not) RECURRENCE-ID changes after a reschedule.
It was already hammered at ad naseum
and confirmed by the RFC authors that RECURRENCE-ID does not change on
an instance reschedule. Please see http://www.imc.org/ietf-calendar/mail-archive/msg08662.html
for confirmation of this.
As such, can we please NOT even go down
any discussion path that tries to reintroduce the concept of RECURRENCE-ID
changing on a reschedule?!?
The RECURRENCE-ID value should be the
the DTSTART that the instance was originally created at as described in
iCalendar Section 188.8.131.52:
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 use of EXPAND should be orthogonal
to the discussion of calculating any instances RECURRENCE-ID. EXPAND
is currently defined in CAP-12-e as:
Purpose: This property is to notify the
CS if it should or should not
expand any component with recurrence rules into multiple instances
a query reply.
so it is defined as a way for the CUA
to tell the CS how to handle bundling results to return. It should
have no bearing on the actual instance properties themselves. The
EXPAND property does not impact how the CS calculates the RECURRENCE-ID
of any particular instance; that is already defined by iCalendar.
Messaging & Collaboration
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...