Re: DTSTART for recurrence instances

"Mark Smith" <[email protected]> wrote in message
news:[email protected]...
>
> Michael Fair wrote:
>
> > The RECURRENCE-IDs are derived from the set described by the object
> > with the UID in question but no RECURRENCE-ID property. period.
> > The RECURRENCE-ID MUST NEVER be derived from the instance itself.
> > If the instance is being stored as a separate object in the CS it
> > must also track the RECURRENCE-ID value originally assigned to it.
>
> How would the CS used by attendee-2 ever have that history in
> order to find or track the originall and RECURRENCE-ID?


Attendee-2 received a sequence of messages that:

   a) defined a 3peat event  (UID:XXX/SEQ:0)
   b) redefined that event to be a 2peat event  (UID:XXX/SEQ:1)
   c) added a 3rd instance (using ADD)   (UID:XXX/SEQ:2)

   None of these actions are an instance reschedule.
   All three messages are set redefining messages.

   Therefore, the "history" is a combination of messages b and c.
   If c were a REQUEST and not an ADD, then you would only need message c.

   When message b arrives, as a "REQUEST", it replaces all prior data
   associated with UID:XXX.

   When message c arrives, as an "ADD", it merges with all existing data
   associated with UID:XXX.

   By creating the "UNION" of the set described by messages b and c
   you get the set described by the object UID:XXX/SEQ:2.  The valid
   RECURRENCE-IDs would be the set of start times generated by
   enumerating that set.

   For any given event that repeats N times, there are N+1 objects in
   the CS.  N instance objects identified by UID/RECURRENCE-ID and 1
   set description object identified by the UID alone.  It is the 1
   set description object that defines the set or RECURRENCE-IDs that
   the N instance objects will use.


> > There will never be a REQUEST object that redefines the set of
> > instances and has a RECURRENCE-ID property.  To invoke the clause
regarding
> > a UID/SEQUENCE pair the RECURRENCE-ID property can not be present.
>
> When you send and instance update you must bump the sequence, so the
> set changes? correct?

Yes the SEQUENCE for that instance gets bumped, but no the set doesn't
change.
You are bumping the SEQUENCE for the instance object (UID/RID) not the set
description object (UID only).

In the "proper rescheduling" (aka method D) from the prior examples
the 2-dec-2003 at noon instance still exists, it just doesn't start
on 2-dec-2203 at noon anymore.

UID:XXX/SEQ:0 defined 3 instances 1-dec, 2-dec, 3-dec.
UID:XXX/RID:2-dec/SEQ:1 updated the DTSTART of the 2-dec instance.

The 2-dec instance is still the 2-dec instance identified by the
enumeration of the set description from UID:XXX/SEQ:0.  It just
starts at a different time.

Another way to understand it is that all events are identified by
two components, the UID and RECURRENCE-ID.  For singleton events
the value of the RECURRENCE-ID is NULL and there are no RDATE/RRULE
or EXDATE/EXRULE properties.  For recurring events, the UID object
without a RECURRENCE-ID attatched is the "set definition" object
and the instances are identified with a RECURRENCE-ID that is a
member of the set described therein.  When you reschedule an instance
you don't redefine the set, you update the times of the instance
identified by the RECURRENCE-ID.

The RECURRENCE-ID is just a name assigned to the instance.  But it's
an algorithmically assigned name so that it can be automaticly chosen
and so that physical storage for the instance can be delayed until
there is a real need to actually track differences related to that
particular instance.  The RECURRENCE-ID is not a reflection of reality,
it's an identifier.  Only DTSTART can tell you when an instance
actually starts.  DTSTART is not an identifier, only UID/RECURRENCE-ID
can identify a particular instance for you.  They, by design, do
oftentimes coincide, but that's an artifact not a mandate or rule.

-- Michael --