Re: DTSTART for recurrence instances

> As I understand the process  that some on this list believe to be true,
the
> answers will not be the same for some of; ORGANIZER, both ATTENDEE's,
> or for all 4 update methods.

Ok I think the easiest way to answer the first half of this message is
merely to iterate the calendar stores for UID:XXX resulting from each
method.  At the bottom I address how the assertment that there is a
problem with things being out of sync is not a problem and why the
assertment that RECURRENCE-IDs should be derived from the present state
of an instance must not be followed and to do so would be a violation
of the RFCs.


First the CS gets the original 3 instance recurring event resulting
in the following four calendar store components:

UID:XXX / SEQUENCE:0
   RRULE:FREQ=DAILY;COUNT=3
   DTSTART: 1-dec-2003 at noon

UID:XXX / RECURRENCE-ID: 1-dec-2003 at noon / SEQUENCE:0
   DTSTART: 1-dec-2003 at noon

UID:XXX / RECURRENCE-ID: 2-dec-2003 at noon / SEQUENCE:0
   DTSTART: 2-dec-2003 at noon

UID:XXX / RECURRENCE-ID: 3-dec-2003 at noon / SEQUENCE:0
   DTSTART: 3-dec-2003 at noon



Then we start manipulating the store:

Method A:
1) Recreate UID:XXX to have 2 instances on 1-Dec and 3-Dec
2) Add the 2-Dec instance back in

After step 1:
- The store has deleted all instances and created a new set
- 1-Dec and 3-Dec instances are reinitialized
- All SEQUENCEs are at 1.
- There is no 2-Dec instance

After step 2:
- The store retains 1-Dec and 3-Dec instances
- The store now also has a 2-Dec instance
    the newly created instance has RECURRENCE-ID: 2-dec-2003 at 2pm
- All SEQUENCEs are at 2.



Method B:
1) Recreate UID:XXX to have 2 instances on 1-Dec and 3-Dec
2) Add the 2-Dec instance back in

The results are exactly the same as Method A.
(The only difference between A and B was the method used
 to describe the set in step 1).



Method C:
1) Cancel the 2-dec-2003 instance
2) Add the 2-dec instance back in

After step 1:
- The store retains all information about 1-Dec and 3-Dec instances
- The store no longer has a 2-dec-2003 instance
- All SEQUENCEs are at 1

After step 2:
- The store retains the 1-dec-2003 and 3-dec-2003 instances
- The store now has a 2-dec-2003 instance
    the instance has RECURRENCE-ID: 2-dec-2003 at 2pm
- All SEQUENCEs are at 2.



Method D:
1) Properly reschedule the 2-dec-2003 instance

After step 1:
- The store retains all instances with their original RECURRENCE-ID
- The 2-dec-2003 instance begins at 3:30 and has kept the
    RECURRENCE-ID: 2-dec-2003 at noon (the original)
- All SEQUENCEs are 0 except the 2-dec instance which is 1.


> And that is busted as no ORGANIZER CUA could figure them out if
they -later-
> send  single instance reschedule (As sent in the 1st email) to the same
UID.
> As the ORGANZER's CUA would have to contact each ATTENDEEs CS to
> figure out what that ATTENDEE's CS thought the RECURRECE-ID's were
> or do some vendor specific CAP I/O to look at a log of what was sent
> to each attendee which may not work with the next CUA looking at the
> same UID.

This is not a real problem as this can never legally happen.

It is a violation of the protocol to send Attendee-1 one set description for
UID:XXX and Attendee-2 a differing description for UID:XXX.

There is no allowance in iTIP or iCal for differing RECURRENCE-IDs to be in
the set of instances for the same UID between different CS' (assuming the
updates aren't still in transit or lost or something abnormal).  To do so
violates the global uniqueness rule of UIDs.

All attendees MUST be sent the same set description information for
the same UID under all circumstances.



> Which is why I say for any UID/SEQUENCE the RECURRENCE-ID's must be
> derived from the object it self without any knowledge of history

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.

The REQUEST message that has the proper UID with the highest SEQUENCE and
no RECURRENCE-ID defines the set of legal RECURRENCE-IDs for that UID.

If you ever receive a message for a RECURRENCE-ID that is not in the
set described the most recent UID only object there is something wrong.

If there ever exists more than one set of RECURRENCE-IDs described by
the same UID/SEQUENCE pair there has been a violation of the protocol.
A UID/RECURRENCE-ID/SEQUENCE triplet does not count as a UID/SEQUENCE pair.

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.


-- Michael --