Re: New question in regards to the fixed-id model

["Chris Olds" <cco@xxxxxxxxxxxxxxxx>]

On Wed, 13 Aug 2003 16:22:41 -0700, Michael Fair wrote
> 
> The scenario goes something like this:
> 
> I send an invite to a bunch of people:
> UID:1
> SEQ:0
> RRULE/RDATE:Every Friday this year.
> 
> I then move Friday, June 13th, to Thursday, June 12th.
> UID:1
> RID:June 13th
> SEQ:1
> DTSTART:June 12th
> 
> I then decide to move the entire series to Monday.
> Since the SEQUENCE of the largest instance in the
> series is now 1, the next highest value to use for
> the new SEQUENCE is now 2.  This forumla was given
> to me offline from the list and I can find no real
> text in iTIP supporting it, but I agree it is what
> is necessary for the desired outcome.

SEQ is for the whole set, not per-instance.  Since you changed an instance
(and changing a member of a set changes the set), 2 is the correct value.

> So I send:
> UID:1
> SEQ:2
> RRULE/RDATE:Every Monday this year.
> 
> So now what to do about that Thursday meeting.

All you need to do is add another date, specifying Thursday.  If it replaces a
meeting from the RRULE/RDATE set, then use EXRULE/EXDATE.  If it is in
addition use RDATE

> iCal says that RECURRENCE-IDs are only fixed for
> a given UID/SEQ pair.  Since that pair has now
> changed it is valid for the RECURRENCE-ID of the
> instance in question to change.  Unless I am
> misapplying that text.

Nope, that's exactly how I read it, and how I understand Doug to be reading
it.  Welcome to the 'current-value' camp!

> At this point I feel it reasonable to say that the
> CUA should just cancel the offended out of date
> instance and assume that the message it just received
> is the complete latest description.  If the CUA
> wanted to maintain the Thursday rather than Monday
> occurence, then along with the reschedule to Monday
> it must include a per-instance update to the now
> Monday RECURRENCE-ID.

Sure, although a simple EXDATE would be enough, no RECURRENCE-ID messing about
needed.

> This however poses a problem in the case that an
> individual CU has been invited to that one and
> only instance because they would never have seen
> the master recurring event nor its reschedule.

No problem at all.

Nothing says that every Attendee must (or even should) see the same event as
the Organizer.  There are many reasons that an Organizer might want to present
different versions of the event object to different users (or classes of
users), and since the Organizer is the only arbiter of what constitutes 'the
same event' (for purposes of unambiguous UID assignment), this all works out
just fine.

> Therefore to maintain consistency it must send two
> messages one with a CANCEL of the old RECURRENCE-ID
> and another with the new RECURRENCE-ID of Monday.

Not needed.  The old RECURRENCE-ID message was sent with SEQ:1, and the new
(complete) VEVENT was sent with SEQ:2, so any instances a CUA might find in
it's calendar that don't match any instance in the new set should be removed
anyway.  The exception can be included in the complete event definition.  If
only one attendee was rescheduled from Friday (now Monday) to Tuesday, just
send them an exception with SEQ:2, RECURRENCE-ID:Monday and that's it.
[ My reasoning for leaving the SEQ at 2 is that the change was initially made
before the reschedule of the event set, so the execption, whether general or
individual, was present before the change to the set.  If these messages
arrive out-of order, the CUA will request a REFRESH (to get the complete set),
and use either the VEVENT sent to everyone or the sepecific response
(whichever arrives first).  Since all of these have the same SEQ (and likely
the same DTSTAMP), they all have equal priority and should be considered
together, which gives the correct result. ]

> If the recipient's CUA should miss the CANCEL message
> it will end up with two instances on its calendar.
> The original as yet uncancelled instance RID:Friday,
> and the new RID:Monday instance.

No.  Getting the complete SEQ:2 event means you have all of the scheduled
instances for that UID, and so all the Friday instances get deleted.

> Save for the CUA receiving the CANCEL message which
> I can't see any way of resending I see no way to get
> the recipient's calendar back into sync since they
> aren't invited to the base recurring event and shouldn't
> ever receive it.

Each Attendee MAY have a different view of the event.  If the Organizer knew
how to send the original version, they know how to send an update.  Again,
SEQ:2 makes _all_ SEQ:1 data out of date.

> Since the SEQUENCE of the new instance will be greater
> and the set will no longer describe the original RID
> then the CUA will no that the instance in question no
> longer exists and can remove it.  It is the ORGANIZER
> CUA's responsibility to ensure that any and all instance
> information it wants copied from the old instances be
> included in the new updates.

Yes.  The examples make this clear.

> The act of updating the SEQUENCE value on the
> UID/RID:NULL object, implicitly cancels any and all
> instances whose RECURRENCE-ID no longer exists in
> the new series.
> 
> Any thoughts?  Or is there something out there I am
> just misinterpreting/not taking into account?
> How do other implementations already handle this?

Thank you for this clear description of the 'current-value' model, and why it
is simpler and less error-prone.  I snipped some text describing problems that
occur if one uses the 'fixed' model, but that doesn't mean I think they're
unimportant, it just means that I want to point out that they don't occur in
the 'current-value' model.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)