[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
-------------------------------|-----------------------------
Doug@xxxxxxxxx                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                              |   Cell: (208)520-4044

We Do Standards - You Need Standards


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature