New question in regards to the fixed-id model

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

In spirit of coming up with what the new text should
unambiguously say and not having this answered for
myself yet, I have a question about how rescheduling
an entire series of events impacts individual instances
that may have been previously renegotiated.


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.

So I send:
UID:1
SEQ:2
RRULE/RDATE:Every Monday this year.



So now what to do about that Thursday meeting.
The SEQUENCE of the rescheduled parent event being
at 2 clearly indicates that it supercedes the
renegotiation of the instance at 1.

Further, the RECURRENCE-ID list described by the
set no longer includes June 13th.

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.


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.


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.

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.


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.

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.


To attempt to answer my own question, there is an
example in 4.7.2 Bad RECURRENCE-ID which might resolve
the dilemma, but it's format is only in 4.7.2 and in
no other example dealing with recurring instances.

The example shows an event that has both RECURRENCE-ID
and RRULE/RDATE properties.  This is the only time I
have ever seen that used.

If we define that when inviting an individual CU to a
particular instance, the ORGANIZER's CUA MUST include
both the RECURRENCE-ID of the instance AND the RRULE(s)
and/or RDATE(s) (with any EX counterparts) then this
whole situation can be avoided.

In this case, when the recipient's CUA receives the
new description with the now Monday RECURRENCE-ID
it can use the RRULE/RDATE/EXRULE/EXDATE information
to find out if the set still includes the other instances
that it has on its calendar.

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.

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?

-- Michael --