Subject: Re: Recurrence ID changes?

From: [email-masked]
Date: Wed, 21 Jul 1999 23:50:41 GMT

Dan:
Good to hear from you. Hope your iCalendar activities are going great!
The RECURRENCE-ID (along with the UID and SEQUENCE properties) are used to 
reference (a particular version of) an individual occurrence for a 
repeating event or to-do. As such, it will change after the DTSTART for 
the occurrence changes.
>The paragraph below is shown at the very end of section 3.7.1 in the 
rfc2446
>(iTIP).  The last two sentences seem to conflict in meaning.  The first 
says
>that "the original DTSTART value is used for RECURRENCE-ID" but the 
second
>says that "RECURRENCE-ID has changed to the new DTSTART".
For example, if you scheduled a Monday, Wednesday and Friday meeting and 
you want to reschedule the Wednesday meeting meeting to Thursday, then the 
RECURRENCE-ID in the reschedule would specify the date/time of the 
Wednesday meeting as specified in the original REQUEST. Now, after 
rescheduling to Thursday, if you want to reference that rescheduled 
occurrence you specify a RECURRENCE-ID that would have the date/time of 
the Thursday meeting. 

>I thought we decided to leave the RECURRENCE-ID the same.  If the last
>sentence is true, then it seems we would have to exclude the original 
date
>in an "EXDATE" property and then include the new date in an "RDATE"
>property.  Is this right?
Not sure I agree with the last part. You can currently specify a "EXDATE" 
property in the original REQUEST that has the date/time value of a 
particular occurrence. You could also specify a duplicate date/time value 
in a RDATE that is the same as an occurrence specified in a RRULE or other 
RDATE. However, the set of occurrences will only have one element with a 
given date/time interval.
You can also reschedule by specifying the revised DTSTART/DTEND for the 
occurrence. However, if you use EXDATE/RDATE wouldn't that appear to be 
"ADDing" an occurrence? We use the ADD method to do this. It seems to be 
problematic if you try to use the EXDATE/RDATE to specify the date/time 
for the rescheduled meeting. It would seem that we should be using the 
DTSTART/DTEND properties for that.
-- Frank

---

From: "Dan Hickman" <[email-masked]>
Date: Wed, 21 Jul 1999 20:14:09 -0500

Hi Frank,

Thanks for your reply.  I've been on hiatus for a while and haven't had time
to join in on the fun with CAP.  Looks like you guys are making good
progress.

You are probably right that EXDATE wouldn't be the way to handle it.  I
guess I am thinking more in terms of my internal calculations for recurring
instances.  If I have a weekly event on Wednesday and I reschedule one of
the occurrences to a Tuesday then my RRULE will calculate the Wednesday and
there is nothing telling me it was actually moved to Tuesday.  I will need
to store both the old RECURRENCE-ID along with the new DTSTART so I can tell
that the calculated Wednesday event is actually on Tuesday.

It just seems to make things complicated when they didn't need to be.  Now
if someone asks for a REFRESH, how do I handle it?  I would send the
original recurring event with RRULE and then a seperate component for the
changed occurrence.  I would need to send the original RECURRENCE-ID of the
changed event (Wednesday) or the attendee won't know which event I am saying
was changed.  I guess this would work if you requested a refresh of the
whole event but what if you requested a refresh of the Wednesday event?  It
would return saying the event doesn't exist, wouldn't it?  There is no way
to figure out whether the event was moved or canceled without refreshing the
whole event.

I understand the problem where you might want to reschedule another instance
to the same time as another rescheduled instance and there is a conflict.
I guess this was necessary to avoid that but it sure made things more
complicated.

Thanks and let me know if my thoughts are way off base.

Dan Hickman
Rockin' Software
[email-masked]
http://www.rockinsoftware.com

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
  Sent: Wednesday, July 21, 1999 6:51 PM
  To: Dan Hickman
  Cc: [email-masked]
  Subject: Re: Recurrence ID changes?

  Dan:

  The RECURRENCE-ID (along with the UID and SEQUENCE properties) are used to
reference (a particular version of) an individual occurrence for a repeating
event or to-do. As such, it will change after the DTSTART for the occurrence
changes.

rfc2446
says
second

  For example, if you scheduled a Monday, Wednesday and Friday meeting and
you want to reschedule the Wednesday meeting meeting to Thursday, then the
RECURRENCE-ID in the reschedule would specify the date/time of the Wednesday
meeting as specified in the original REQUEST. Now, after rescheduling to
Thursday, if you want to reference that rescheduled occurrence you specify a
RECURRENCE-ID that would have the date/time of the Thursday meeting.

date

  Not sure I agree with the last part. You can currently specify a "EXDATE"
property in the original REQUEST that has the date/time value of a
particular occurrence. You could also specify a duplicate date/time value in
a RDATE that is the same as an occurrence specified in a RRULE or other
RDATE. However, the set of occurrences will only have one element with a
given date/time interval.

  You can also reschedule by specifying the revised DTSTART/DTEND for the
occurrence. However, if you use EXDATE/RDATE wouldn't that appear to be
"ADDing" an occurrence? We use the ADD method to do this. It seems to be
problematic if you try to use the EXDATE/RDATE to specify the date/time for
the rescheduled meeting. It would seem that we should be using the
DTSTART/DTEND properties for that.

  -- Frank