Jonathan, that's great that you and Eric have come up with something that appears to be nearing an agreement. We do, however, need to have our method reviewer, Bruce Kahn, review the thoughts to make sure they dont' "break" iCalendar. I know Bruce has put some thoughts on the list but have seen no replies to his comments. Does that mean that his comments are accepted as is? Want to make sure we go through the right steps. IT does sound like we might be close here.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
Jonathan Lennox <lennox@xxxxxxxxxxxxxxx> Sent by: owner-ietf-calendar@xxxxxxxxxxxx
05/17/01 11:42 AM
To: ietf-calendar@xxxxxxx
cc:
Subject: Clarification and current status of CPL RECUR thoughts
I thought I'd clarify further my current thoughts on RECUR in CPL.
After my phone conversation with Eric Busboom, we agreed that we could do
everything CPL needed with only one change to RECUR:
* Drop BYSETPOS.
I also suggested two clarifications/recommendations:
* A server (CPL server, calendaring server, whatever) MAY reject any RECUR
rule on the grounds that it's too "expensive" (complex, whatever). The
definition of expense/complexity is implementation-dependent.
* We ought to add text to the recur definition which says that a server
SHOULD support any RECUR which meets certain constraints. This allows us
to guarantee that unconditionally compliant implementations will be
interoperable. (The exact nature and values of these constraints can be
hashed out later.)
Note that this means:
* COUNT is back (but may be subject to the server's complexity rules).
* Sub-day frequencies and BY* rules are back.
* Durations can be any length (subject to the server's complexity rules).
I have (mostly) completed an implementation -- a modification to the Java
code I released late last year -- which implements this RECUR-minus-
BYSETPOS. It correctly generates all the RECUR examples from 2445 except
the two which use BYSETPOS.
The two complexity constraints I impose in my code are that if a rule has a
COUNT value, it must be fully satisifed before a caller-specified time and a
caller-specified recurrence of the smallest time unit mentioned in the rule;
and the duration of a recurrence must be less than a caller-specified
multiple of the smallest time unit mentioned in the rule.
The running time of my code is linear in the caller-specified bounds. (The
COUNT bounds are linear once; the duration bound is linear every time the
rule is evaluated.) In all other respects it's linear in the textual size
of the rule. It's possible to determine whether a rule exceeds the bounds
at the time a script is submitted to a server.
In the phone conversation, Eric seemed to indicate that he thought that
BYSETPOS was too complex for iCalendar as well. And of course iCalendar
(2446, yes?) already has the concept of rejecting a calendering object for
being too complex.
What's the feeling of the working group on this proposal?