Subject: BYSETPOS: Fresh start

From: [email-masked]
Date: Fri, 27 Jul 2001 01:44:03 -0400

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.

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?

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.

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?

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. 
  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.

Time to get some sleep...

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: "Shannon J. Clark" <[email-masked]>
Date: Fri, 27 Jul 2001 11:31:12 -0500

Re point 1 - it is a rare case - but in theory a BYHOUR rule could generate
a variable number of hours twice a year (i.e. the two days a year for
locations with Daylight Savings that do not have 24 hours) Even more
obscurely, BYSECONDS could for the moments of leap seconds (but this is
unlikely to managed by most systems in any case)

Also a BYMONTHDAY or a BYYEARDAY could generate a variable number of values
for a FREQ:YEAR due to leap years (i.e. some years have more instances of
MONTHDAY=29, or YEARDAY=366. Though rules with this would be rather silly.

Also a slightly complex case, but one that the standard is designed to
allow: if you vary the WKST setting - then rules with weekly rules or a
BYWEEKNO are applied could have variable results for a given FREQ of either
MONTHLY or YEARLY.

(to quote the standard on what WKST does)

    The WKST rule part specifies the day on which the workweek starts.
       Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant
       when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule
       part is specified. This is also significant when in a YEARLY RRULE
       when a BYWEEKNO rule part is specified. The default value is MO.

Hope this helps bring to light some other cases with variable result sets.

Shannon

  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
  Sent: Friday, July 27, 2001 12:44 AM
  To: Jonathan Lennox
  Cc: [email-masked]
  Subject: BYSETPOS: Fresh start

  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.

  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.

  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.
    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.

  Bruce

---

From: "Thomas O'Dowd" <[email-masked]>
Date: Sat, 28 Jul 2001 14:12:53 +0900

Hi all,

I posted a little on this before. I've implemented the RRULE spec
as per RFC2445 including BYSETPOS, so having worked on some of the
details, I've some of my own opinions...

> just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. 

RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU

-> Event on Wednesday, Friday, Sunday every week.

RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU;BYSETPOS=1

-> Event on Wednesday every week.

If we add WKST=SU to the rule though this changes. This is another case
where WKST affects the outcome of an RRULE.

RRULE:FREQ=WEEKLY;BYDAY=WE,FR,SU;WKST=SU;BYSETPOS=1

-> Event on Sunday every week.

As Bruce said though, this is pretty silly usage of RRULE and it would be
hard to see why an interface would generate such a rule anyway. Much 
simplier would be FREQ=WEEKLY;BYDAY=WE or FREQ=WEEKLY;BYDAY=SU

Personally after evaluating most real life cases and what actual users are
interested in representing, I believe that BYSETPOS should be simplified
and limited to MONTHLY and YEARLY Frequencies (monthly is the most useful
in real life). BYSETPOS should also not be used when the following 
BYxxx rules are used; BYSECOND, BYMINUTE, BYHOUR.

I think this solves most problems for most people. I think the other
situations are nice to consider but who will implement them and also
what calendar system will be able generate them via a GUI without asking
the user to enter raw RRULE text?

Tom.
-- 
Thomas O'Dowd. - Nooping - http://nooper.com
[email-masked] - Testing - http://nooper.co.jp/labs