Subject: [Ietf-calsify] Should we bring back the RANGE parameter?

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jul 4 08:48:54 2007

Cyrus,

At the last Jabber session you said you were tempted to bring back the
RANGE parameter to allow an Organizer to cancel all future recurrence
instances of a recurring component defined with an unbounded RRULE.

While I understand that most applications don't handle arbitrary
modifications to the RRULE property nicely, I believe it shouldn't
be difficult to handle truncation of unbounded RRULE properly with
the simple addition of a COUNT or UNTIL rule part.

In my opinion, this would be much simpler than trying to address
the 4 issues that were raised with the RANGE parameter in the
following thread:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html

and, more importantly, expect applications to support it.

Cheers,
Bernard

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Jul 4 12:18:11 2007

Hi Bernard,

> the simple addition of a COUNT or UNTIL rule part.

There is a semantic difference between sending a REQUEST that changes a 
rule vs sending a CANCEL to remove instances.

Consider: an existing event with a series of overridden instances. The 
attendee's client will have the master event stored with the rrule, plus 
all the instances. Now the Organizer sends out a CANCEL that uses RANGE - 
in that case it is obvious that any overridden instances whose 
RECURRENCE-ID overlaps the RANGE are to be removed. Now consider the 
alternative you propose: in that case the Organizer has to send not only 
the modified master event with the RRULE but also ALL overridden instances 
that are not being cancelled. That would be very inefficient.

So the important thing here is that its better to update a recurring event 
in iTIP by sending diffs. As soon as you try and change the rule you have 
to send out the entire set of valid instances. CANCEL, ADD and a REQUEST 
that uses RECURRENCE-ID are effectively "diffs" to the original set.

In any case it is not just CANCEL that is an issue here. A more common case 
is an ongoing meeting where the location changes, or where an attendee is 
added or removed and those changes are ongoing. How do you do that without 
RANGE=THISANDFUTURE?

I realize that there are issues with multiple RANGE's in the same event 
set, but how else can we support a use case like this?

I believe that we can pin down the semantics of RANGE=THISANDFUTURE enough 
to do what we need (I don't care about THISANDPRIOR).

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Jul 4 13:20:52 2007

> > instances of a recurring component defined with an unbounded RRULE.

Apart from the technical issues and the semantics, looking at a practical 
point: 
How many calendaring applications and server have implemented or might be 
using the RANGE concept now or in the future?

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/