Subject: [Ietf-calsify] Section 4.2.13 Recurrence Identifier Range: Should we deprecate the RANGE parameter?

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Oct 2 13:58:00 2006

In section 4.2.13 Recurrence Identifier Range of RFC 2445 it says:

 > Description: The parameter can be specified on a property that
 > specifies a recurrence identifier. The parameter specifies the
 > effective range of recurrence instances that is specified by the
 > property. The effective range is from the recurrence identified
 > specified by the property. If this parameter is not specified an
 > allowed property, then the default range is the single instance
 > specified by the recurrence identifier value of the property. The
 > parameter value can be "THISANDPRIOR" to indicate a range defined by
 > the recurrence identified value of the property and all prior
 > instances. The parameter value can also be "THISANDFUTURE" to
 > indicate a range defined by the recurrence identifier and all
 > subsequent instances.

I have two issues with the RANGE parameter:

1- We should clarify the meaning of "all prior instances" and "all
    subsequence instances". Should it be based on the RECURRENCE-ID
    or the DTSTART value of the recurrence instances?

2- If an iCalendar object defines (1) a "master component" that
    defines a recurrence set, (2) an "exception component" that
    makes use of RANGE=THISANDFUTURE, and (3) another "exception
    component" for an instance subsequent to the "exception component"
    that make use of RANGE=THISANDFUTURE. Should the 3rd component
    that only makes reference to a specific recurrence instance
    override the component with RANGE=THISANDFUTURE?

Anybody thinks the RANGE parameter is important?  Do we want to
address the issues mentioned above or should we simply deprecate
the RANGE parameter?

Cheers,
Bernard

---

From: caleb at everyone.net (Caleb Richardson)
Date: Mon Oct 2 15:45:52 2006

A third issue:

Which portions of the DTSTART and DTEND properties specified as part of 
a component containing a RECURRENCE-ID should be applied to the "master 
component".

For example:

Given an event with a daily recurrence at 1400 UTC and a newly created 
component with the following properties:

RECURRENCE-ID;RANGE=THISANDFUTURE:20070401T140000Z
DTSTART:20070401T133000Z

Clearly this indicates that all occurrences of this event on and after 
April 1st 2007 should occur at 1330 UTC instead of 1400 UTC.

Common sense dictates that future occurrences should NOT have their date 
set to April 1st 2007, but nowhere is this explicitly mentioned in RFC 2445.

Furthermore, in the case of a YEARLY recurrence it makes sense to use 
the month and date (all future occurrences should be moved to April 
1st), but not the year.

There seems to be a correlation between the recurrence FREQUENCY and 
what date-time fields should be applied to the master component, I think 
it would be beneficial to have these rules enumerated in RFC 2445 (if 
this is in fact the desired behavior).

Caleb Richardson

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

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Mon Oct 2 16:18:12 2006

Hi Bernard,

+1 to deprecating RANGE.  While we lose some semantic power, it
simplifies life, and I think the major use cases for RANGE can be
handled by just re-issuing a truncated version of the old event plus a
new event.  This is what several clients already do.

Sincerely,
Jeffrey

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Oct 3 01:00:05 2006

> set to April 1st 2007, but nowhere is this explicitly mentioned in RFC
[...]
> this is in fact the desired behavior).

Even worse: If you have a recurrence on every first monday of the month, and 
you shift it with RANGE=THISANDFUTURE to a different date (e.g. to a sunday), 
what is the recurrence for the future events? First monday? (Probably not, 
because that's the thing you changed). First sunday? (would make sense, but 
what about a recurrence every first monday and tuesday? Shall the days be 
shifted here, too? Both days or just the one from RECURRENCE-ID?) Day before 
the first monday? (can't be expressed in RRULE).
So, basically, the recurrence rule needs to be updated, too, which is 
practically impossible due to the huge complexity that is possible with 
rrules.

I'm all for removing the RANGE parameter. In KOrganizer and libkcal I also 
simply generate a new event with RELATED-TO set to the original event as a 
sibling. This makes life much easier, as you now have a completely separate 
event where the RRULE can be edited separately and the UIDs don't conflict.

Cheers,
Reinhold

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/