RECURRENCE-ID / instance reschedule (Was Re: DTSTART for recurrence instances)

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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