Subject: Re: UID & RECURRENCE-ID

From: "John Stracke" <[email-masked]>
Date: Fri, 8 Mar 2002 11:33:53 -0500

>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.

That is more or less correct.  In your internal storage, of course, you'd 
want to simplify it by, say, storing objects with the same UID together; 
but, however you manage it, any time you're expanding a recurrence rule, 
you do have to be aware that there can be exceptions.

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|This space intentionally not left blank.                |
\========================================================/

---

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

> you do have to be aware that there can be exceptions.

You also need to be extremely careful when sending out itip requests to
new attendees or canceling existing events.  In my mind it somewhat
defeats the purpose of a unique identifier.

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Mar 2002 10:34:00 -0700

> defeats the purpose of a unique identifier.

The UID is unique per event (as you have pointed out), not unique per
packet (component). So you can ADD and CANCEL instances of the same UID.
It is also possible to not be able to represent a single event in one single 
component. Only the ORGANIZER and the ORGANIZER-CUA(s) know what the entire 
state of any UID as not all ATTENDEEs have data for the other ATTENDEEs.

iCalendar and iTIP are not meant to represent the exact state
of any event. They are an interoperability protocol for exchanging the
information between users so that the ORGANIZER has control of
an event.