Subject: Re: Clarification and current status of CPL RECUR thoughts

From: [email-masked]
Date: Fri, 18 May 2001 18:51:00 -0400

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 <[email-masked]>
Sent by: [email-masked]
05/17/01 11:42 AM

        To:     [email-masked]
        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?

-- 
Jonathan Lennox
[email-masked]