[Ietf-calsify] Re: Should we bring back the RANGE parameter?
cyrus at daboo.name
Wed Jul 4 12:17:04 PDT 2007
--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
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).
More information about the Ietf-calsify