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

Cyrus Daboo cyrus at daboo.name
Wed Jul 4 12:17:04 PDT 2007


Hi Bernard,

--On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux 
<bernard.desruisseaux at oracle.com> wrote:

> 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.

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



More information about the Ietf-calsify mailing list