Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Message-ID | <OF7CA31E7A.E9936536-ON85256D98.00671D85-85256D98.0067E885@notesdev.ibm.com> |
Michael replied on 09/04/2003 06:28:40 PM:
> "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)?
> 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?
> 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.
Bruce
===========================================================================
Bruce Kahn INet:
[email protected]
Messaging & Collaboration Phone: 978.399.6496
IBM Software Group FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...