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 - 
change
> the subject line. How you derive RECURRENCE-ID from a given object with
> 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 4.8.4.4:

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

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...