Subject: Re: BYSETPOS: Fresh start

From: Jonathan Lennox <[email-masked]>
Date: Wed, 8 Aug 2001 14:09:52 -0400 (EDT)

On Friday, July 27 2001, "[email-masked]" wrote to "Jonathan Lennox, [email-masked]" saying:

> Ok, Im totally overwhelmed by the backlog of WG traffic that I filed away 
> so Im going to take a fresh start at this BYSETPOS concept again to see if 
> I can summarize the latest thoughts on it.  Here are my takes on how 
> things stand with BYSETPOS based on emails and phone calls.

I'm sorry I haven't responded to this earlier.  I had been waiting to see if
you had any respone to my other "RECAP and status" message
<http://www.imc.org/ietf-calendar/mail-archive/msg02946.html>, but this
might have been after your mail started bouncing.

I'll try to comment on the issues you mention from CPL's point of view.

> 1: BYSETPOS is only of real use when the data set from the recurrence rule 
> has a variable amount of data (ie: "All the Thursdays in the Month")  For 
> ALL other cases the recurrence rule can easily be rewritten to just select 
> those desired data points.  So I would agree that some prose in the 
> updated draft could reflect this and possibly even mandate that BYSETPOS 
> is only used for rules that generate variable sets of data.  That is to 
> say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should 
> just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. 
> 
>   As far as we've seen so far, the only rule that will generate a variable 
> length data set is the FREQ=MONTHLY;BYDAY=[MO,TU,WE,TH,FR,SA,SU] so this 
> should not be that great an impact going forwards.  Anyone know of other 
> cases?

A number of the FREQ=YEARLY cases can do this.  Any case can do it in the
presence of DST transitions, but those are corner cases.

There's also the "The 30th of the month, if it exists, otherwise the last
day of the month" case someone mentioned here --
FREQ=MONTHLY;BYMONTHDAY=28,29,30;BYSETPOS=-1.  There are other ways to do
this, but they're less concise.

As a general philosophical issue, though, I don't know if it's a good idea
to be imposing arbitrary constraints upon the RECUR language without good
reasons.  FREQ=WEEKLY;BYDAY=MO,WE,FR;BYSETPOS=2 doesn't actually *hurt*
anything, after all.  It's not hard to process; it's just mildly ugly.
Imposing aesthetic constraints on a data representation language feels like
a slippery slope to me.

(I also note that it isn't necessarily the same thing as
FREQ=WEEKLY;BYDAY=WE; this depends on what day of the week DTSTART falls
on.)

> 2: The concern about ~31M data points is orthogonal to the BYSETPOS issue 
> since all the BYxxx subcomponents on a FREQ=DAILY rule w/o a BYSETPOS can 
> generate that large data set size.  As such it is unclear to me (at this 
> late hour at least) why they are considered llinked.

In the CPL case -- and for other cases, such as "show me all the occurences
of this rule that happen this week" -- you don't normally have to expand out
the whole data set.  You can be much more efficient by just expanding those
occurences you actually need to expand.  However, once BYSETPOS enters the
picture, you really *do* have to expand the whole set, in order to count out
the set positions.

> 3: iTIP / iCalendar define the use of REQUEST-STATUS properties to back 
> application level statuses like "Grammar too complex", "Unsupported RRULE 
> subcomponent", etc.  Why cant this same kind of mechanism be reused in CPL 
> when a rule uses a BYSETPOS or generates a data set too large for O(1) 
> evaluation?

It can.  CPL already assumes a mechanism that allows servers to complain
about errors in a submitted CPL script.  However, I think that, for
interoperability, the definition of "too complex" ought to be formally
defined, so clients can know what they can reasonably expect to be allowed
to generate.

I don't think such a formal definition would be terribly hard to write.  I
already have an outline of such a definition in my "Recap and status"
message.

> 4: Much of the bitter back and forth seems to focus on very extreme cases 
> (ie: "bombing" CS/CPL servers) rather than on the 'normal' usages that the 
> vast majority of installations will deal with on a regular basis.  Sure we 
> have to deal with some DOS or other maliscious kinds of activity at 
> various levels of design bug I suspect that these fringe cases have 
> distracted us from the real technical work. 

This could be, certainly.  As long as we have *some* way to deal with it
(such as "go away"), and as long as legitimate cases don't get
mis-identified as malicious, I'm inclined to let this slide to a "watch out
for this, and do something reasonable" statement in a Security
Considerations section.

>   So how about we refocus on the items above or if I left any off that we 
> put them on the plate anew and try to get on the same page. I talked w/Tom 
> (Robert) today before dinner and he seemed to think that we were all in 
> basic agreement about how recurrence grammars get expanded.  If this is 
> not quite accurate then Im willing to try and restart that again too.

It sounds fine to me.  If you could take a look at my other message as well,
that'd be great...

-- 
Jonathan Lennox
[email-masked]