Subject: UID & RECURRENCE-ID

From: JP Rosevear <[email-masked]>
Date: 07 Mar 2002 20:45:18 -0500

According to the spec regarding UID:

This property defines the persistent, globally unique
identifier for the calendar component.

Now, with itip, RECURRENCE-ID can specify how to modify a single
instance of a recurring event and it specifies which event(s) based on
RECURRENCE-ID and UID.  Now, if you such a change is made, how should
the changes be stored?  If you create a new component, a new UID will be
created, removing any possibility of the organizer sending future
changes.  If a separate component is created with the same UID and
containing the given RECURRENCE-ID, it would seem to violate the the UID
spec (as quoted above).

Thoughts?

-JP
-- 
--
=======================================================================
JP Rosevear				[email-masked]
Ximian Inc.				http://www.ximian.com

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Mar 2002 20:32:30 -0700

> identifier for the calendar component.

Its wrong (and good catch!), it should say something like:

    Purpose: This property defines the persistent, globally unique
    identifier for the calendar object. Where object is one or
    more components that make up one VEVENT, VTODO, VJOURNAL,
    or any other iCalendar object.

> the changes be stored?

Storage is not specified in iCal, iTIP, iMIP or CAP.

> ... If a separate component is created with the same UID and

We need to fix 2445 so it does not say that it is unique per component.
The ADD method has the same problem.

---

From: JP Rosevear <[email-masked]>
Date: 08 Mar 2002 11:00:17 -0500

> Storage is not specified in iCal, iTIP, iMIP or CAP.

Fair enough, but there is a practical implementation side to things
here.  Essentially what I meant by storage was an iCalendar object.

> The ADD method has the same problem.

If this is so, it would seem to mean that any icalendar objects that
allow recurrences cannot be considered individually by a CUA in many
cases (like recurrence instance generation) because there might exist a
modifying object with the same UID and a RECURRENCE-ID.

-JP