Subject: [Ietf-calsify] Issue 48: Section 4.2.13 Recurrence Identifier Range

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 10 Jan 2008 22:01:09 -0500

Back in October 2006, we decided to deprecate the RANGE parameter
from iCalendar.  See:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html
http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue48

As we found out, it is hard to do without RANGE=THISANDFUTURE
with unbounded recurring calendar components when the Organizer
wants to modify all future instances, or when an Attendee wants
to modify his participation status to all future instances.

Here's a proposal along the lines of what was discussed at the
last IETF meeting in Vancouver.

- Revert the change to deprecate the RANGE parameter.

- Only the THISANDPRIOR value would be deprecated.

- Clarify that THISANDFUTURE is based on RECURRENCE-ID
   values and not the current value of DTSTART.

- Clarify that exception components have precedence
   over THISANDFUTURE.

- Clarify that when the recurrence instance specified with
   RANGE=THISANDFUTURE is rescheduled, that all future recurrence
   instances ends up being rescheduled "the same way". For
   instance, if the recurrence instance specified with
   RANGE=THISANDFUTURE is rescheduled to start 2 hours later
   then all future instances will also be rescheduled to start
   2 hours later. Similarly, if the duration of the recurrence
   instance specified with RANGE=THISANDFUTURE is modified then
   all future recurrence instances should be changed to have this
   new duration.

   Obviously, there will be cases where this approach will not be
   sufficient to reschedule all future instances exactly like the
   end user wants. Let's take the case of a recurrence meeting
   scheduled to occur on Monday and Wednesday for ever. At some
   point the Organizer decides to reschedule all future Wednesday
   instances to occur on Thursday instead. With the approach
   mentioned above this is not possible, since all future
   instances (i.e., including the Monday instances) would end up
   being rescheduled to start 24 hours later (i.e., the Monday
   instances would be rescheduled on Tuesday). In such situations
   the calendar application should truncate the unbounded
   recurring calendar components and create a new unbounded
   recurring calendar components for the future instances.

Cheers,
Bernard
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify