Subject: Re: UID & RECURRENCE-ID

From: "John Stracke" <[email-masked]>
Date: Fri, 8 Mar 2002 13:23:10 -0500

>> Er? Can't you send out the REQUEST with the extra recurrence included?
>
>Yes, but you need to recognize that.

Uh-huh.  And in what way could a representation format for events (a) 
support repeating events with exceptions and (b) not require 
implementations to recognize repeating events with exceptions?

/===========================================================\
|John Stracke                    |Principal Engineer        |
[email-masked]   |Incentive Systems, Inc.   |
|http://www.incentivesystems.com |My opinions are my own.   |
|===========================================================|
|Stupid, adj.: Losing $25 on the game and $50 on the instant|
|replay.                                                    |
\===========================================================/

---

From: JP Rosevear <[email-masked]>
Date: 08 Mar 2002 15:09:23 -0500

> implementations to recognize repeating events with exceptions?

The issue is not with recognizing that fact but with recognizing that
external calendar components can affect when and how another component
repeats.  If I have the orignal VEVENT component, simply expanding its
recurrence rules may yield a faulty expansion if another component
contains the same UID, a RECURRENCE-ID and a different DTSTART/DTEND
pair.

At any rate, the statement was made as a final clarifying statement.

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

---

From: "Graham Gilmore" <[email-masked]>
Date: Fri, 8 Mar 2002 15:33:58 -0500

----- Original Message -----
From: "JP Rosevear" <[email-masked]>
To: "John Stracke" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 08, 2002 3:09 PM
Subject: Re: UID & RECURRENCE-ID

> contains the same UID, a RECURRENCE-ID and a different DTSTART/DTEND

    A calendar component cannot unilaterally lay claim to an existing UID
using a RECURRENCE-ID.  Components that use the RECURRENCE-ID property must
be referenced by the original, either by being part of an RRULE or
explicitly with an RDATE.  The reason for having the extra component is not
to add more dates; it is to describe in detail the other properties that are
different from the original component (for example, SUMMARY, DESCRIPTION,
ATTENDEEs, etc.).
    The only time a "subsidiary" calendar component has a DTSTART that is
not referenced by the original component is when you're sending an iTIP
message that says "I'm moving this component, originally scheduled at
[RECURRENCE-ID], to be at [DTSTART]".  The original and subsidiary calendar
components must then be "updated" (I'll leave the semantics of that in terms
of object storage aside) with the new date of the subsidiary.

    Graham

---

From: JP Rosevear <[email-masked]>
Date: 08 Mar 2002 16:03:16 -0500

> different from the original component (for example, SUMMARY, DESCRIPTION,

I know it is not to have more dates.  But it can have different dates,
as you clearly state below, in some cases.  Also, I haven't seen
anything which states that only the differing properties should be
listed in the component with the RECURRENCE-ID.

> of object storage aside) with the new date of the subsidiary.

Why does the original need to be updated in this particular case?

-JP

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Mar 2002 15:09:51 -0700

Graham Glimmer wrote:

> [RECURRENCE-ID], to be at [DTSTART]". 

I am not sure of what you are saying. And I don't think that is correct.
By "subsidiary" - you mean one that has the same UID but is not
in the same component - correct? If so:

A "subsidiary" calendar component can be 100% different (except UID) from
the original component.  It is the only way to add a new DTSTART value
to an existing component and when the ADDed component has one or more other 
properties not in common (Such as SUMMARY).

 > The original and subsidiary calendar

'date' did you mean 'data'? If not:

New 'date'? I don't follow your point. You can do a REQUEST with DTSTART
and later ADD a new instance with a DTSTART where DTSTART != DTSTART.
And you are NOT updating or moving any existing instance. The values
in the original REQUEST can be completely unrelated to the contents in the
ADD object - other than they are the same sequence of events with the same UID.

---

From: "Graham Gilmore" <[email-masked]>
Date: Fri, 8 Mar 2002 16:47:50 -0500

> Why does the original need to be updated in this particular case?

    So that its list of dates (RRULE, EXRULE, etc.) remains in sync with the
other components sharing the same UID.  If you move an instance of a RRULE
(as described), for example, from then on your component with the RRULE must
reflect the changed date; one way that this can be done by using the EXDATE
and RDATE properties to remove the old date and add the new one to the
recurrence set.  In this way, the "original" component (by which I don't
mean the original state; but rather the "master" component) always keeps
track of the dates of all of its subsidiary components.  Otherwise, as you
surmised, you could never *know* what all the dates would be without finding
all the components that might have the same UID (leaving aside, of course,
the possibility of outstanding unprocessed iTIP messages).

    Graham

---

From: "Graham Gilmore" <[email-masked]>
Date: Fri, 8 Mar 2002 18:10:26 -0500

----- Original Message -----
From: "Doug Royer" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 08, 2002 5:09 PM
Subject: Re: UID & RECURRENCE-ID

> Graham [Gilmore] wrote:

[Doug - your address book keeps putting 'Graham Glimmer']

> properties not in common (Such as SUMMARY).

    I'll try to explain what I'm saying before you correct something
entirely different :)

    Yes, the subsidiary component can have completely different data.  I'm
simply saying RECURRENCE-ID must match a date in the "original" component's
(this is a bad term; it implies that we're comparing a "before" and "after"
view of the component, which is not the intention.  I'll call it the
"master" component) recurrence set (EXCEPT when the iCalendar is part of an
iTIP message whose purpose is modifying those dates, like moving an instance
of a recurring event, or as you suggest, doing an ADD.  I tried to say/imply
that I was considering only the calendaring data ("booked" data, in CAP
terms, that is, a snapshot of the calendar), and not "in-flight" iTIP
scheduling data, but I guess I failed).

>  > The [master] and subsidiary calendar

    'Date'.

    But the data store that is keeping track of the calendar data should
update the calendar object that you're ADDing to, to reflect the ADD, after
it is performed.  Whether your data store interprets "update the component"
as meaning "change the contents of the blob stored at address X to be Y" or
"the most up-to-date version of this component is now at address Z instead
of address W" is truly irrelevant.  Conceptually, the CU's view of the data
has been "updated", and when they export their "updated" data in iCalendar
form, the "original" component's iCalendar representation should reference
the newly added instance in its recurrence set.

    Graham

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Mar 2002 18:25:35 -0700

Graham Gilmore wrote:

> [Doug - your address book keeps putting 'Graham Glimmer']

Sorry! It must be the spell checker/fixer. I just added your
last name to the dictionary - it is correct in my address book.

Let me know if it does it again - I am using Netscape 6.2, we'll

get Steve to fix it :-)

>     Yes, ...

:-) Yes now I understand your point. Thanks.