Subject: RECUR Subset and IPTel's CPL: Need Resolution

From: Jonathan Lennox <[email-masked]>
Date: Wed, 25 Apr 2001 17:58:51 -0400 (EDT)

The IPTel group's Call Processing Language specification is currently
stalled on the question of its specification of recurrence subsets.  This
issue was raised here in the CalSch group, but consensus was never reached.

To review:
A fundamental requirement of the IPTel's CPL work is that it be possible to
process scripts in constant time.  (Technically, linear time in the textual
length of the script, and constant time in the values of all the script's
parameters.)  This allows user-created scripts to be placed on high-volume
call servers, without providers having to worry about malicious or
mis-designed scripts overloading the server.

CPL adopts RFC 2445's method of describing recurrences, with minor syntactic
transformations, to define recurring intervals in which a person might want
specialized call handling.  However, the full RFC 2445 RECUR syntax does not
satisfy the fundamental requirement I stated above.

Thus, for CPL I removed several features, which I considered to be of only
relatively specialized applicability, from recurrences, and showed (with
running code) that the rest of the features could be implemented in constant
time.

However, there were significant objections from the IESG and the CalSch
community that this subset was not actually compatible with all of RFC
2445.

As I mentioned, this was discussed at the Minnesota IETF and on the mailing
list, but no consensus was ever reached.  One significant point was raised,
though, that the computational complexity of RECUR can be a significant
issue for calendaring applications as well, for example for a centralized
calendaring server for a large organization; and that RECUR is sufficiently
complicated that it presents significant interoperability problems for RFC
2445 implementations.

As I see it, therefore, there are several ways we could proceed:

1. Somehow demonstrate that the full RFC 2445 recurrences actually do
satisfy the requirement I listed above after all.  I don't believe this is
possible.

2. Re-define RECUR in a successor to RFC 2445, eliminating the
computationally-intensive parts.  Since there is currently some effort to
limit RECUR in some other ways to be more tractable, this may be feasible.
However, this clearly isn't going to happen quickly.

3. Issue a document describing the recurrence subset, along with advice
describing ways to transform full RFC2445 recurrences into the subset with
minimal information loss.

4. Do (3) short term, with the intention of doing (2) and folding it into a
future rfc2445bis long-term.

5. Allow CPL to go its own way, and eliminate its text claiming iCalendar
compatibility.

I personally would prefer option (4), unless (2) is going to happen a lot
more quickly that it would currently appear.  However, failing this, I'm
afraid that it might be necessary to go with (5).

What is the feeling of the working group on this issue?

-- 
Jonathan Lennox
[email-masked]

---

From: [email-masked]
Date: Thu, 26 Apr 2001 00:29:53 -0400

Not being in Minnesota, I can not be sure of all that was discussed. 
However, I really am reluctant to see us "step back" a draft in order to 
make it fit a smaller model such as telephony.  I don't believe that is 
the best thing to do here.  There are already vendors implementing or 
attempting to implement iCalendar and making what appears to be such a big 
change could potentially throw a monkey wrench in a process that is 
finally starting to move - i.e. interoperability.  Those of you on the 
list need to speak up on this comment about reducing the complexity of 
recurrence rules.  If anything happens it needs to be a new RFC.  There 
will always be new technology that comes along after a draft has been 
produced.  What happens in those situations?  They don't rewrite the draft 
- they build new drafts that add on to or enhance the draft. I don't think 
they step the drafts backwards.  I may be wrong - some one step up and 
throw rocks at me if I'm reading this incorrectly.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652