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

[email protected]
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...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.