Re: DTSTART for recurrence instances

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.


Please read all of this as there are some interdependencies with
text after statements.

Olivier Gutknecht wrote:

>
> Method C: ok too
>     - CANCEL to remove the instance identified by UID  + recurrence-ID 
> 2-dec-noon
>     - then a ADD to put another instance at 2-dec-2003 2pm
> And in all cases (A,B,C,D), SEQUENCE for all instances is 2.
> I also agree with Michael's comments that we end with a calendar where 
> we have 1-dec noon->1pm, 2-dec 2pm->3:30pm, 3-dec noon->1pm and I'm 
> not sure I can consider every method as a 'reschedule'. 

In the first email the sequence is '1', and in (A, B, C) the sequence is 
'2'. (D?).

And although they are -all-  -not- really a 'reschedule' they all four
represent ways the CU could change the 2nd instance.

Now assume that 'A' or 'B' as sent previously to this list was
sent to ATTENDEE:attendee-2 as attendee-2's initial REQUEST
to attendee this meeting. Except 'ATTENDEE:attendee-2'
in place of (or in addition to) ATTENDEE:attendee. And
attendee-2 said yes.

The CS of the  attendee-2 (I am NOT talking about the organizer
or attendee-1) has in the attendee-2's CS (I am NOT talking about
the CUAs)

  BEGIN:VEVENT
  ...
  (no METHOD as it is booked)
  ...
  UID:XXX
  ...
  SEQUENCE:2
  ...
  ATTENDEE:attendee-2
  ...
  DTSTART: 1-dec-2003 at noon
  DTEND: 1-dec-2003 at 1pm
  ...
  RRULE:FREQ=DAILY;COUNT=3
  EXDATE:2-dec-2003 at noon
  ...
  (plus the following start/stop time however it may be
    represented in the 'attendee-2' CS)
  ...
  DTSTART:2-dec-2003 at 2pm
  DTEND:2-dec-2003 at 3:30pm
  ...
  END:VEVENT
  END:VCALENDAR
 
Assume this is the ONLY UID for all of  the organizer, original 
attendee, and
attendee-2 in their  CS's (not CUAs).

On -4-dec-2003, I said, and you replied on 5-dec for to the ORIGINAL 
object (Not
A, B, or C as they has not been sent yet) to attendee (not attendee-2)' 
and you agreed.

 >> Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you 
have 3
 >> daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 
5-DEC, and
 >> the 3rd 6-DEC. So the value of recurrence ids are:
 >>
 >> 1st
 >>  RECURRENCE-ID: 4-DEC
 >>
 >> 2nd
 >> RECURRENCE-ID:5-DEC
 >>
 >>3rd
 >> RECURRENCE-ID:6-DEC
 >
 > Agreed.

At this point both 'attendee' and 'attendee-2' have the same pattern of
instances. The ORGANIZER (master copy) of UID:XXX is at SEQUENCE:2.

So my questions to any and all  using your understanding of how they
are generated.

 What are the RECURRENCE-ID's and DTSTARTs for 'attendee-2'? That is
  attendee-2 does an EXPAND:TRUE fetch. (Got one object == SEQUENCE:2)

 What are the RECURRENCE-ID's and DTSTARTs for 'attendee' (not-2) after
 getting the 1st (not A, B, or C) objects?  (Got original[SEQUENCE:0]
 + instance update[SEQUENCE:1], 'attendee' at SEQUENCE:1)

 What are the RECURRENCE-ID's and DTSTARTs for 'attendee' after
  getting A, B, or C (not the first reschedule)?   (Got original 
[SEQUENCE:0],
  + 2 sequence updates,  'attendee' now at SEQUENCE:2).

 What are the RECURRENCE-ID's and DTSTARTs for the
 ORGANIZER? (master copy now at SEQUENCE:2).

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.

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.

Attendee-2 will not have any history of the object at this point only
has SEQUENCE:2 invite.

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 - or of 
the previous
methods. And as the ORGANIZER is the owner of a UID, then the owners
object is the 'master' copy.

The answers have to be all 2-dec-2003 at noon, 3-dec-2003-at 2pm, and 
4-dec-2003 at noon
for RECURENCE-ID's and the DTSTARTs are the one in the master object.

If you disagree:

 - And if all of your answers to the above questions are the same:
     Say so and start a NEW thread (new subject line)  on how
     and why.

 - And if all of your answers to the above questions are not the same:
     Start a new thread (new subject line) and please step this WG through
     the process you use to later send a single instance update to all 
attendees.
 
    And we can start a thread (new subject line) on how  you got your 
answers.

Only when everything is documented step by stem in writing can we solve 
this.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards