Subject: Correct handling of Recurrence-id

From: "V. Oliver" <[email-masked]>
Date: Mon, 19 May 2003 09:50:12 -0700

Resending (I apologize if this ends up as a duplicate, but I didn't see 
the first submission come through).

I am hoping that someone can clarify the correct use of Recurrence-id in
recurring calendar components. Specifically, what is the correct value
to use when setting the Recurrence-id?

RFC 2445, Section 4.8.4.4 "Recurrence ID" seems to contain contradictory
statements:

"... The property value is the effective value of the "DTSTART" property
of the recurrence instance."

The meaning of "effective value" is not defined, but could be
interpreted to mean the date/time when the instance will occur.

However, several paragraphs later:

"The date/time value is set to the time when the original recurrence
instance would occur; meaning that if the intent is to change a Friday
meeting to Thursday, the date/time is still set to the original Friday
meeting."

The above seems very clear if I change the date/time of a recurring
instance, the Recurrence-id is set to the date/time that the instance
originally had.

Finally, in RFC 2446 (iTIP), Section 3.7.1 "Working With Recurrence
Instances" the following paragraph is found:

"An instance of a recurring event is assigned a unique identification,
"RECURRENCE-ID" property, when that instance is renegotiated.
Negotiation may be necessary when a substantive change to the event or
to-do has be made (such as changing the start time, end time, due date
or location). The "Organizer" can identify a specific recurrence
instance using the "RECURRENCE-ID" property. The property value is equal
to the date/time of the instance. If the "Organizer" wishes to change
the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID"
property and the new "DTSTART" and "DTEND" values reflect the change.
Note that after the change has occurred, the "RECURRENCE-ID" has changed
to the new "DTSTART" value."

The last sentence in the above paragraph is the interesting one. It
clearly states that Recurrence-id will change. But this seems to
contradict the paragraph from RFC 2445 that says "... date/time is still
set to the original Friday meeting".

There is also an example in RFC 2446, Section 4.4.7 "Add A New Series of
Instances To A Recurring Event" which would seem to adhere to the
description in Section 3.7.1 above. Unfortunately, the example given
does not work with an RRULE, but defines the recurring series entirely
through a sequence of RDATEs. This may have no effect on the correct
setting of Recurrence-id, but it is not entirely clear if that is the case.

Here is an example of a sequence of changes to a recurring series. I am
leaving out lots of associated fields since I am really interested only
in the correct setting of Recurrence-id (and perhaps the EXDATEs and
RDATEs) at the moment. The data represents a series of iTIP messages.

- there is a "master" component which defines a recurring series through
an RRULE.
    The event occurs weekly on Mondays, starting 5/5/2003 from 6 - 7 pm
UTC, with no end date

BEGIN:VEVENT
UID:12345
SUMMARY:recurring event
DTSTART:20030505T180000Z
DTEND:20030505T190000Z
SEQUENCE:0
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;WKST=SU
END:VEVENT

OPTION 1: recurrence-id never changes (always the very original DTSTART)

- Change 1: create one exception to this event by changing the time on
5/12/2003 to 5pm UTC

exception (5/12/2003 17:00) :

BEGIN:VEVENT
UID:12345
RECURRENCE-ID:20030512T180000Z
SUMMARY:recurring event
DTSTART:20030512T170000Z
DTEND:20030512T180000Z
SEQUENCE:1
END:VEVENT

- Change 2: move the same instance to a different day

exception (5/13/2003 17:00):

BEGIN:VEVENT
UID:12345
RECURRENCE-ID:20030512T180000Z
SUMMARY:recurring event
DTSTART:20030513T170000Z
DTEND:20030513T180000Z
SEQUENCE:2
END:VEVENT

OPTION 2: the recurrence-id changes

- Change 1:

exception (5/12/2003 17:00) :

BEGIN:VEVENT
UID:12345
RECURRENCE-ID:20030512T180000Z
SUMMARY:recurring event
DTSTART:20030512T170000Z
DTEND:20030512T180000Z
SEQUENCE:1
END:VEVENT

- Change 2:

exception (5/13/2003 17:00):

BEGIN:VEVENT
UID:12345
RECURRENCE-ID:20030512T170000Z
SUMMARY:recurring event
DTSTART:20030513T170000Z
DTEND:20030513T180000Z
SEQUENCE:2
END:VEVENT

And, finally, if I ask for a REFRESH of the entire component? What
should that look like

OPTION 1:

BEGIN:VCALENDAR

BEGIN:VEVENT
UID:12345
SUMMARY:recurring event
DTSTART:20030505T180000Z
DTEND:20030505T190000Z
SEQUENCE:1
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;WKST=SU
EXDATE:20030512T180000Z
RDATE;VALUE=DATE-TIME:20030513T170000Z
END:VEVENT

BEGIN:VEVENT
UID:12345
RECURRENCE-ID:20030512T180000Z
SUMMARY:recurring event
DTSTART:20030513T170000Z
DTEND:20030513T180000Z
SEQUENCE:2
END:VEVENT

END:VCALENDAR

OPTION 2:

BEGIN:VCALENDAR

BEGIN:VEVENT
UID:12345
SUMMARY:recurring event
DTSTART:20030505T180000Z
DTEND:20030505T190000Z
SEQUENCE:1
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO;WKST=SU
EXDATE:20030512T180000Z
RDATE;VALUE=DATE-TIME:20030513T170000Z
END:VEVENT

BEGIN:VEVENT
UID:12345
RECURRENCE-ID:20030513T170000Z
SUMMARY:recurring event
DTSTART:20030513T170000Z
DTEND:20030513T180000Z
SEQUENCE:2
END:VEVENT

END:VCALENDAR

Which of the two options above is correct? Or is there some third way
that is correct?

Is there a distinction between recurrence sets whose instances are
defined only by RDATEs as opposed to those sets which are defined
(primarily) by RRULEs?

I'd appreciate any clarification to this problem.

---

From: John Stracke <[email-masked]>
Date: Mon, 19 May 2003 13:10:14 -0400

> set to the original Friday meeting".

These two paragraphs are saying the same thing.  They are both referring 
to changing a recurrence.  In the message that describes the change, the 
old DTSTART is used; after that, the new DTSTART must be used.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|What do you mean, *you're* a solipsist?   |
\==========================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 May 2003 12:00:40 -0600

> interpreted to mean the date/time when the instance will occur.

That is what it means. If a repeating component has 10 instances
in which it will occur. Then each has instance has a RECURRENCE-ID
equivalent to its own start time.

> instance, the Recurrence-id is set to the date/time that the instance

That refers to a COUNTER or an new REQUEST or PUBLISH that is updating
an instance. You have to give the OLD RECURRENCE-ID in order for the
recipients to know the 'from' RECURRENCE-ID that you are changing.
It is worded badly.

> ...

During an update to an instance RECURRENCE-ID is used to specify the 'was'
instance. After the update RECURRENCE-ID refers to the 'is now' instance.

> setting of Recurrence-id, but it is not entirely clear if that is the case.

Given this component:

  BEGIN:VCALENDAR
  METHOD:REQUEST (or PUBLISH)
  ...
  RDATE: 1-jan...
  RDATE: 2-jan...
  UID: 1st
  SEQ:1
  ...
  END:VCALENDAR

Now to ADD one instance:

  BEGIN:VCALENDAR
  METHOD:ADD
  ...
  RDATE: 3-jan
  UID: 1st  (same UID as original)
  ...
  END:VCALENDAR

Now if you want to update just ONE instance, supply
an RECURRENCE-ID a value that is equivalent
to the start time of the one instance
you wish to change (change 1-jan to 4-jan):

  BEGIN:VCALENDAR
  METHOD: REQUEST
  RDATE: 4-jan  (the new date)
  SEQ:2         (must be a newer sequence number than recipient has)
  RECURRENCE-ID: 1-jan (the one you are changing)
  UID: 1st
  ...
  END:VCALENDAR

Now to CANCEL an INSTANCE (4-jan):

  BEGIN:VCALENDAR
  METHOD:CANCEL
  ...
  RECURRENCE-ID: 4-jan (the instance to be canceled)
  UID: 1st
  SEQ:2
  ...
  END:VCALENDAR

RECURRENCE-ID is not really a part of the persistent object. It is a handle
to refer to an instance within a context in time with a known sequence.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: John Stracke <[email-masked]>
Date: Mon, 19 May 2003 14:16:25 -0400

> equivalent to its own start time. 

Basically, if you took the RECUR and rewrote it as a series of RDATEs, 
the RECURRENCE-ID of each instance would be equal to the corresponding 
RDATE.

-- 
/===========================================================\
|John Stracke      [email-masked]                    |
|Principal Engineer|http://www.centive.com                  |
|Centive           |My opinions are my own.                 |
|===========================================================|
|We must be devious, cunning, inventive... too bad we're us.|
\===========================================================/

---

From: [email-masked]
Date: Mon, 19 May 2003 14:36:13 -0400

I disagree, the recurrence-id must always refer to the original date.
 
of the meeting.  Lets say i had a 5 day repeating meeting. However I 
invited you to just Monday Tuesday to start with, but for some reason you 
have not received the mail yet.
I now reschedule Thursday Friday to a later time in the day and add you to 
the invitee list. 
You now get a sequence 2 invite for Thursday Friday
Later you finally receive the meeting for Monday Tuesday with sequence of 
1.
If I allow recurrence dates to reset on a reschedule, I can not tell if 
the Monday Tuesday invitee was rescheduled to Thursday Friday or if this 
is a separate invite.
_____________________
Note: new email address

[email-masked]

---

From: [email-masked]
Date: Fri, 23 May 2003 14:22:32 -0400

> the RECURRENCE-ID of each instance would be equal to the corresponding 

ONLY the first time the instaces are created!  After that the 
RECURRENCE-ID values are fixed and NEVER EVER EVER change even if the 
RDATEs do!

Otherwise you will run into the same kinds of "Which instance was he 
accepting?" quandry Ive mentioned elsewhere in this thread.  Or can you 
explain Dougs model to me  because Im still not seeing how things work 
properly..

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 May 2003 13:01:45 -0600

> explain Dougs model to me  because Im still not seeing how things work 

Bruces responses above are contrary to RFC-2446.

The RECURRENCE-ID values only usable with a known UID and SEQUENCE.

Bruces comments are only valid when SEQUENCE == 0, when there has
never been a ADD or CANCEL, there have been no significant revision to
the calendar component (as defined in 2445), as long as DTSTART,
DTEND, DUE, RDATE, RRULE, EXDATE, EXRULE, STATUS, LOCATION, and
perhaps more have not changed - as defined in 2445.

The 'which instance' is not an issue. The instance is
UID/RECURRENCE-ID/SEQUENCE and sometimes DTSTAMP. That
is 'an instance'.

--

---

From: [email-masked]
Date: Fri, 23 May 2003 18:44:05 -0400

> Bruces responses above are contrary to RFC-2446.

Please cite.  Ive already ponited out the relevant parts in 2445 and 2446. 
 What did I misquote??

Please also show me how changing the RECURRENCE-ID on every reschedule 
works if any are missed?  I still have yet to see it (nor can I find 
anything in iTIP that supports your claims).

> The RECURRENCE-ID values only usable with a known UID and SEQUENCE.

WRONG!  Please reread 2446, Section 3.2.2 REQUEST:

   The "UID" and "SEQUENCE" properties are used to distinguish the
   various uses of the "REQUEST" method. 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. If the "UID"
   property value is found on the recipient's calendar, then the
   "REQUEST" is for a rescheduling, an update, or a reconfirm of the
   "VEVENT" calendar component.

For repeating instances the key is not just UID but UID and RECURRENCE-ID. 
 In case you missed it before, Section 2.1.5 Message Sequencing:

   1.  The primary key for referencing a particular iCalendar component
       is the "UID" property value. To reference an instance of a
       recurring component, the primary key is composed of the "UID" and
       the "RECURRENCE-ID" properties.

the rest of the steps use "UID" but that is not a literal 'just "UID"', 
for a repeating instance its the UID/RECURRENCE-ID.  This was done for 
brevitys sake in the editing because we use "UID" in lots of places in the 
specs and its WAAAYY too cumbersome to constantly say" the "UID" property 
(or the combination of "UID" and "RECURRENCE-ID" properties in teh case of 
a recurring component)". 

> perhaps more have not changed - as defined in 2445.

Absolutely false.  Ill keep pointing back to Section 3.2.2 REQUEST if I 
have to until it sinks in...  Go reread it again please.

> UID/RECURRENCE-ID/SEQUENCE and sometimes DTSTAMP. That

You argue my point now, thanks!  If RECURRENCE-ID changes then you are 
describing a different instance; NOT the same instance at a different 
date/time!

By 2446 Section 3.2.2, if an invitee gets a new REQUEST for a different 
RECURRENCE-ID then they can consider it a new invitation to a new instance 
of that repeat set.  Thus Tom thinks we are meeting on both Monday 
(RECURRENCE-ID:20030609T140000Z) AND on Friday 
(RECURRENCE-ID:20030613T140000Z) when in fact we are no longer meeting on 
Monday!  Now can you see why 'deltas' are bad?!?

Bruce
Warning: Dates in Calendar are closer than they appear.