RE: Recurrence ID changes?

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.

-----Original Message-----
From: Frank_Dawson@lotus.com [mailto:Frank_Dawson@lotus.com]
Sent: Wednesday, July 21, 1999 6:51 PM
To: Dan Hickman
Cc: ietf-calendar@imc.org
Subject: Re: Recurrence ID changes?

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

References:

Re: Recurrence ID changes?
- From: Frank_Dawson