Re: DTSTART for recurrence instances

"Doug Royer" <[email protected]> wrote in message
news:[email protected]...
>
> (Again the topic is DTSTART for recurrence instances, not any thing else)
>
> Is there any disagreement that these are -also- a valid ways to change
> the 2nd instance:
>
> Again starting from the same original object.
>
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:0
>    ...
>    METHOD:REQUEST
>    ATTENDEE:attendee
>    ...
>    DTSTART: 1-dec-2003 at noon
>    DTEND: 1-dec-2003 at 1pm
>    ...
>    RRULE:FREQ=DAILY;COUNT=3
>    ...
>    END:VEVENT
>
> (And 'attendee' sends a  reply saying yes).

Just to ensure that I am following I am going to describe
the state of the CU's store at the end of each message.


> Method A:  Now later ORGANIZER sends iTIP updates to move the second
> instance
>  from  noon->1pm  and have it at 2pm->3:30pm:
>
>    BEGIN:VCALENDAR
>    ...
>    METHOD:REQUEST
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:1
>    ...
>    DTSTART: 1-dec-2003 at noon
>    DTEND: 1-dec-2003 at 1pm
>    ...
>    RDATE:3-dec-2003 at noon
>    ...
>    END:VEVENT
>    END:VCALENDAR
>
>    BEGIN:VCALENDAR
>    METHOD:ADD
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:2
>    ...
>    DTSTART:2-dec-2003 at 2pm
>    DTEND:2-dec-2003 at 3:30pm
>    ...
>    END:VEVENT
>    END:VCALENDAR

I agree.

This first message would redefine the event XXX to have exactly two
instances (Dec 1, Dec 3), and drop the orginal Dec 2 instance.

The second message then adds to the series of UID XXX one singleton
on Dec 2 and updates the SEQUENCE of all instances to 2.


> Method B:  Now later ORGANIZER sends iTIP updates to move the second
> instance
>  from  noon->1pm  and have it at 2pm->3:30pm:
>
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:1
>    ...
>    METHOD:REQUEST
>    ATTENDEE:attendee
>    ...
>    DTSTART: 1-dec-2003 at noon
>    DTEND: 1-dec-2003 at 1pm
>    ...
>    RRULE:FREQ=DAILY;COUNT=3
>    EXDATE:2-dec-2003 at noon
>    ...
>    END:VEVENT
>
>    BEGIN:VCALENDAR
>    METHOD:ADD
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:2
>    ...
>    DTSTART:2-dec-2003 at 2pm
>    DTEND:2-dec-2003 at 3:30pm
>    ...
>    END:VEVENT
>    END:VCALENDAR

I agree.

The first message redefines the series to contain two instances
on Dec 1 and Dec 3.
The second message redefines the entire series to add a singleton
event happening on Dec 2.

It then updates the SEQUENCE for all instances of XXX to 2.

> Method C:  -OR- this:
>
>    BEGIN:VCALENDAR
>    ...
>    METHOD:CANCEL
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:1
>    ...
>    RECURRENCE-ID:2-dec-2003 at noon
>    ...
>    END:VEVENT
>    END:VCALENDAR
>
>    BEGIN:VCALENDAR
>    METHOD:ADD
>    BEGIN:VEVENT
>    UID:XXX
>    SEQUENCE:2
>    ...
>    DTSTART:2-dec-2003 at 2pm
>    DTEND:2-dec-2003 at 3:30pm
>    ...
>    END:VEVENT
>    END:VCALENDAR
>
> Do you agree that these are also valid objects to tell the ATTENDEE of
> the single instance change?

I agree.

I'm not entirely certain of all the gritty details of how the first message
gets handled because of other questions I raised back in August.
Don't bother looking for them though, they aren't relevant at this point.
For now I'm fine to just accept that this has the effect of cancelling the
second instance in the series leaving just Dec 1 and Dec 3.

The second message then adds a new instance to the series XXX on Dec-2 and
updates the SEQUENCE of all instances of XXX to 2.



Having said that there is one thing I do have a problem with and that is
calling any of the above methods an instance reschedule.  They result in
the intended calendar and that's about all I can say about them.

Everyone of the aboves methods uses extremely invasive reschedules of
the entire series and I cannot consider them as proper methods for
instance updates or reschedules.


Where do we go from here?

-- Michael --