Re: Can we fix BYSETPOS? (Proposed Restrictions)

[Bruce_Kahn@xxxxxxxx]

Eric wrote:
>It is the useful features that have resulted in recurrence rules being
>absurdly complex. We should be focusing on the mandatory features.

Are you suggesting we codify what subcomponents of a recurrence rule are MUST, SHOULD, MAY, etc?  Thats a different argument that the discussion so far so I want to try and stay relevant here...

>The problem we have is that if we allow BYSETPOS to operate over the
>entire range of seconds in a year, it is possible for CUAs to
>generate rules that CPU-bound servers will reject because they are too
>complex to evaluate in a small amount of time.

Thats a justification from CPL for removing BYSETPOS entirely (at least initially).  But not every system that implements iCalendar is going to have an O(1) time requirement for expanding sets of recurrence instances.  We (Lotus Notes) certainly do not have one.  I do not recall finding one in Outlook/Exchange.  Besides CPL, are there any other implemenations that have this requirement??  

Since not every implemenation has such a requirement I do not think it an absolute necessity to impose said restriction on the rest.  (Thats akin to the smallest footprint argument for cutting features argument again...)

>I believe that we can restrict recurrence rules to only using BYSETPOS for
>day-scale events, thus eliminating the complexity problem for all but the
>most feeble servers. 

That may be fine for CPL but it may not be fine for, say, SKiCAL.  I would stipulate that the base definition (ie: iCalendar) is NOT the place to put restrictions motivated by this kind of argument since they do not apply to all uses of the grammar.  It is applicable to put them into non-base definitions or other derivative works though that may have such a restriction.  (That is to say, the restriction is in the Cell Phone Sync program/protocol, NOT in iCalendar itself!)

>                      I also think that any plausible rule that would use
>BYSETPOS for sub-day intervals can be re-written without BYSETPOS, so the
>restriction does not reduce the functionality of recurrence rules.

Nothing argued so far seems to justify why losing functionality that exists now for sub-day sets is a good thing (apart from it is not something that some derivative works want to deal with).  At least not that Ive been able to digest so far...

>You are arguing that BYSETPOS for sub-day intervals is useful and that
>there may be cases where some CUA will want to use them. 

It is the same argument for both sub-day and super-day recurrences that I trying to present here.  BYSETPOS is used to select specific instances of the set for use.  That is irregardless of the FREQ scale.

>                                                             Neither
>case is necessary, and both of them cause interoperability problems
>related to computational complexity.

This gets back to the O(1) requirement of CPL.  It is NOT a requirement of iCalendar.

>The proposed restrictions are a compromise between a complexity problem
>that we know exists and a set of future possibilities that we suppose
>exist. We can't design for a vague an unknown future; if you've got some
>plausible use cases that cannot be implemented without BYSETPOS on a
>sub-day scale, then we can do some analysis. Otherwise, we are just
>guessing.

The proposed restrictions are _NOT_ a compromise that needs to made in iCalendar; those are current restrictions of CPLs model.  

The addition of clarifying text about BYSETPOS is a good thing though.  In providing clear text about how to evaluate any recurrence rule subcomponent and any theoretical limitations that apply to them we are doing the right thing and allowing future implementors to benefit from our open mindedness.  If we take the approach of "I cant think of a use for this mix although it could be useful sometime later" then we are not providing a springboard for future extension and reuse; we are providing a plank for them to walk along and fall off.

>So, can you show some rules for a plausible scenario that cannot be
>implemented without BYSETPOS on a sub-day interval?

Argue for it at all on super-day intervals.  The same usage applys to both cases (its just that some folks do not want to deal w/sub-day cases).  In case some folks haven't seen that line in 2445 (p. 44) the use for BYSETPOS is to "indicates the nth occurrence of the specific occurrence within the set of events specified by the rule".  So whatever size your rule can geneate, BYSETPOS needs to be able to indicate ANY instance in that set.  You cannot justify it one way w/o also justfying the other way at the same time...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...