Subject: [IPTEL] Re: Current thinking on CPL/iCalendar

From: [email-masked]
Date: Tue, 20 Mar 2001 19:02:05 -0500

>John Stracke wrote (snipped from a longer note):
However, we may be able to achieve O(1) without banning the sub-day
recurrences.  If so, then we still have the issue of usability; the 
current
RECUR grammar is extremely complex, far too complex to express in a simple
UI.  This means that we'll get implementations that support only subsets
(there will also be those that use complex UIs, but they'll lose out to 
the
simple UIs over time); if we don't want to wind up with *different* 
subsets,
non-interoperable ones, then we'd better pick a single subset *now*.

John, it is looking like the RECUR rules are too complex. That issue keeps 
"recurring".  While you are there as a group in Minn perhaps you can 
recommend a subset that will work as a good starting base.  This will help 
the IPTEL group as well as ours.  Thanks.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 21 Mar 2001 18:27:14 -0500 (EST)

> the IPTEL group as well as ours.  Thanks.

(This is an argument I made in the CalSch WG meeting today -- I'm
re-iterating and amplifying on it here for the list.)

The iCalendar RECUR rules, as they stand now, allow all sorts of absurd
recurrences, which are nearly-impossible to describe to users, to represent
as user interfaces, or to evaluate in an efficient manner.

The problem is that there's no clear boundary between the absurd rules and
the useful rules.  Things like "every Tuesday for two days", or "every six
hours" -- which are reasonable, but my subset would eliminate -- verge
seamlessly into things like "every June 23, when it's a Thursday, for eighty
weeks", or "every 7,192,314 seconds".

Thus, if there isn't any way to set up a clear boundary, the only thing that
can be done is to set up an arbitrary boundary instead.  The subset I
created for CPL, and which John and I turned into the post-deadline draft
for iCalendar, picked "one day duration, no rules smaller" as this arbitrary
boundary.  This certainly does eliminate some useful recurrences -- I think
that's clear.  However, I think it maintains 95% of the useful recurrences,
and eliminates all of the agressively pathological recurrences.

Note that the looser version of my subset rule -- "the duration must be
shorter than the shortest time period mentioned in the recurrence" -- would
still forbid a fair number of useful recurrences.  It's looser, though, and
I'd be willing to go with this version, but I'm concerned it's hard to
explain to users.

One big concern a lot of people raised is whether it's legitimate for the
working group to back off of the promises that RFC 2445 made, and break
backward compatibility.  It's not like there's anything *broken* about
RRULE.  If you're willing to invest enough CPU effort, all of the iCalendar
RRULEs are resolvable -- there's nothing Turing-equivalent here.  I'm not
sure how I feel about this.  Would it be possible to move those RRULE parts
that go beyond a subset to an extension of some sort?

I'll send my observations of existing calendaring systems shortly, and
hopefully the CalSch people will be able to expand on them...

-- 
Jonathan Lennox
[email-masked]

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel