Subject: RFC2445 comments on section 4.3.10

From: "Thomas O'Dowd" <[email-masked]>
Date: Thu, 12 Jul 2001 09:47:18 +0900

Hi all,

I'd been reading section 4.3.10 "Recurrance Rule" and I've some 
questions on the meanings of BYSETPOS and also on some of the
proposed revisions which I found at the following url.

http://softwarestudio.org/iCal/ProposedChanges.txt

I. BYSETPOS

I wasn't aware of this mail lists existance until today but was
thinking a lot about the proper usage of BYSETPOS over the past week.
I came to the following conclusions. 

BYSETPOS only makes sense (to me at least) if it only applies to ByRules
of a date nature and those which expand the event set. This is because
BYSETPOS is limited to values between 1..366 and -366..-1 and therefore
cannot access sub-day events in the case of something like the following
rule...

RRULE:FREQ=YEARLY;BYDAY=MO,TU,WE,TH,FR,SA,SU;BYHOUR=8,9,10;BYSETPOS=-1

I see two ways, to deal with this rule given the BYSETPOS range.

a) evaluate BYSETPOS before time rules meaning that the rule will be
evaluated as 3 events, Dec 31st at 8, 9 and 10am, every year.

b) Disallow, BYSETPOS where a time ByRule is given.

Personally I think that a) makes sense and it is the way that I've implemented
it. How are other people doing it?

In summary I think that the RFC could be clearer around the BYSETPOS
defination. I would think the following should apply.

1) The paragraph about multiple BYxxx rules should be changed to specify
an order which makes a) above happen. ie. move BYSETPOS from after BYSECOND
to before BYHOUR.

	BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYSETPOS,
	BYHOUR, BYMINUTE and BYSECOND ; then COUNT and UNTIL are evaluated.

2) BYSETPOS makes no sense (if time ByRules are disallowed) if FREQ=DAILY
as the max events per set is 1 at the time BYSETPOS is evaluated.

3) BYSETPOS be disallowed for time frequencies ie, HOURLY, MINUTELY,
and SECONDLY.

I'm looking forward to hearing other peoples thoughts on the above.

I'd also like to comment on some of the proposed changes to this sections
that I found at the url I mentioned above. Namely the following:

   A rule may not not have a BYxxx rule part that conflicts with the
   recurrence interval.

      A SECONDLY recurrence may not have both a BYSECOND >rule part and
      an INTERVAL that is greater than 1

      An HOURLY recurrence may not have both a BYHOUR rule part and
      an INTERVAL that is greater than 1

      A MINUTELY recurrence may not have both a BYMINUTE rule part and
      an INTERVAL that is greater than 1

      A WEEKLY recurrence may not have both a BYWEEKNO rule part and
      an INTERVAL that is greater than 1

      A MONTHLY recurrence may not have both a BYMONTH rule part and
      an INTERVAL that is greater than 1

While these rules elimate the possibility of there being no valid events
where the interval causes the rule never to hit a match on a byrule
limitation, I think this should be handled by the software itself so
that valid rules like the following should be allowed to be expressed.

DSTART:20000110T200000Z
RRULE:FREQ=HOURLY;UNTIL=20000125T080000Z;INTERVAL=5;BYHOUR=8,11
Mon Jan 10 20:00:00 2000
Thu Jan 13 11:00:00 2000
Sat Jan 15 08:00:00 2000
Tue Jan 18 11:00:00 2000
Thu Jan 20 08:00:00 2000
Sun Jan 23 11:00:00 2000
Tue Jan 25 08:00:00 2000

Which is what I have also implemented from my reading of the RFC. Sure
it prevents ugly rules like

DSTART:20000110T200000Z
RRULE:FREQ=HOURLY;INTERVAL=2;BYHOUR=11

But I don't see why the RFC should restrict that just like it doesn't
restrict setting something like.

RRULE:FREQ=YEARLY;BYMONTH=2;BYMONTHDAY=30

ie. the implementing software can find it pretty easily and you don't block
potentially useful rules in the process.

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