Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]

> > "Bad Recurrence-ID" needs to be expanded to include a fourth
> > possibility; that it has never seen neither the base UID nor
> > the RECURRENCE-ID before.
>
> Isn't that already covered by:
>
>                                  If the "UID" property value in
>    the "REQUEST" is not found on the recipient's calendar, then the
>    "REQUEST" is for a new "VEVENT" calendar component.
>
> (factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in
> place of UID when dealing with recurring instances per Section 2.1.5)?

What to do is handled, but it's the actual text of 4.7.2 that
bothers me.

Section 4.7.2 Bad RECURRENCE-ID says:
 ... there are three cases in which an instance cannot be found. ...

It then talks about finding the "UID" but then either not
finding the RID or having problems with the SEQUENCE value.

This isn't true.  There are four cases.  The fourth case being
that neither the UID nor the RID have ever been seen before.
A simple reference to "Do what 2.1.5 says" would suffice, but
the declaration that there are only three cases can be confusing.



> > Somehow it needs to be made clear that every relevant reference
> > to "UID" throughout the document really means something more
> > along the lines of "primary key" which could include UID,
> > RECURRENCE-ID, and RANGE to accurately identify which events
> > are being referred to.  Much of the confusion here has been
> > as a result of interpretting "UID" to not mean all of those.
>
> Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's
> meaning) would be useful?

Yes, that would be best, I fear putting it in a different section
like Convenentions used in this document would be to easily missed.


> > Making it clear that when canceling an event for a particular
> > user the SEQUENCE value should not be incremented (or at least
> > more discussion on what it should do).
>
> While this is a good change, exactly how to do it is another matter.  The
> problem is that this change is that it will effect all implementations
> already out there that follow that text from Section 2.1.4.  Just making
> the change could mean interoperability issues w/existing implementations
> and no way to detect it.

Well is there any _real_ problem that develops if we do this?

There's 4 scenarios I can think of, of which only 2 might be
an issue:

1) Old sends a cancel to Old
No problem they do what they always did

2) New sends a cancel to New
No problem they both expect the new behavior

3) Old sends a cancel to New
No problem, SEQUENCE value has been incremented New just prcesses it.
If Old wants to reinvite New it will do whatever it has always done
in the past when it did such things.

4) New sends a cancel to Old
Not sure what happens here since it seems to be implementation specific.
I suspect that it will actually still work since DTSTAMP will be
greater than what it has, but some CUAs might try to enforce the
RFC MUST and ignore a CANCEL if the SEQUENCE isn't greater.
I guess the question is are there any CUAs we know of that will
fail to CANCEL an event if the SEQUENCE is the same?

Assuming that the CUAs will indeed cancel the event, will they
reschedule it if they receive a request at the same SEQUENCE
but greater DTSTAMP.


--------------------------------------
There might be another approach.
Rather than try and prevent SEQUENCE from being incremented,
define rules for exceptions to invalidating the ATTENDENCE status.

For instance, if an update is sent with a greater SEQUENCE and
ALL fields except Comments are identical, then no REPLY is required
and ORGANIZERS should simply transfer the attendence status.

This way, cancelling an ATTENDEE with cause a SEQUENCE bump,
and reinviting an ATTENDEE will also cause a SEQUENCE bump,
however, those bumps will have no impact on the existing attendees.

Old CUAs will simply go through the extra effort of processing
the replies and New CUAs might be sent an RSVP=true for the
higher SEQUENCE value because it failed to respond.
However, in any case, the right things end up on the calendar.

-- Michael --