Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions)

From: [email-masked]
Date: Mon, 11 Jun 2001 19:24:38 -0400

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: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 12 Jun 2001 15:58:10 -0400

I think I had an ephiany last night one the drive home that makes some of 
what Eric and Jonathan are saying clear.  Let me see if I can reexplain 
their rationale for trying to restrict BYSETPOS and you guys can tell me 
if the lights are finally on...

<NUTSHELL>
Since BYSETPOS is only useful for selecting particular instances in a set 
generated by each pass of the rule.  As such, for sub-day recurrences (ie: 
FREQ less than DAILY really) the same effect can be achieved by simply 
splitting the rule into 'smaller' rules which do not include the instances 
that would be punched out (or conversely selected).  As such, we do not 
need to have BYSETPOS if the FREQ is less than DAILY since we can simply 
subdivide the recurrence rule into smaller bounding recurrences.
</NUTSHELL>

I think the key factor for me was part of a response from Jonathan that 
said:
>In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 
instances
>long, not 2.

Since the set is variable in this case the BYSETPOS is useful (or 
necessary).  For a case where the set is NOT variable (ie: 
FREQ=HOURLY;BYHOUR=9,10,11,12;BYMINUTE=0,20,40 will ALWAYS generate 12 
instances) then BYSETPOS is not of any real value since we can easily 
'subdivide' the recurrence rule into separate but proper subsets of the 
original rule.  This can I live with as long as we expressly say to do 
this in the text for BYSETPOS where we preclude it for FREQ values DAILY 
or smaller.

I think the key rationale (that the set for FREQ=DAILY and below is not 
variable in size when instanciated) was what was not clear to me in the 
previous threads (was it to others??).  Now I can accept the rationale for 
restricting BYSETPOS for 'fixed size instanciations' is a viable change 
(even if it does cause some data size expansion). 

Eric/Jonathan: Does this jive w/what you had in mind all along??

Bruce