Subject: Changes to RECUR

From: Eric Busboom <[email-masked]>
Date: Tue, 27 Mar 2001 15:48:30 -0800 (PST)

Here is the current proposed text for changes to recurrence rules. Please
read and comment. 

BTW, I still need to rework the text to use MUST and MUST not. 

eric. 

------------------------------------------------------------------------

[This proposed text is an addition to RFC2445, section 4.3.10]

There are two types of BYxxx rules; date BYxxx rule parts that
specify time periods equal to or longer than a day, and time BYxxx
rule parts that specify the time within a day. The day BYxxx rule
parts are : BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY. The
time BYxxx rule parts are BYHOUR, BYMINUTE, and BYSECOND. BYSETPOS is
neither a date rule part nor  time rule part. 

Not all date BYxxx rule parts can appear simultaneously in a
single recurrence rule. Date BYxxx rule part restrictions are:

	If the BYYEARDAY appears, no other date rule part may appear. 
   
	BYWEEKNO and BYMONTH rule parts may not both appear. 

Furthermore, not all date rule parts may be used with all
recurrence intervals. 

	For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor
	BYWEEKNO may appear.

	For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor
	BYYEARDAY may appear.

	For DAILY recurrences (FREQ=DAILY) BYYEARDAY may not appear.

( BYYEARDAY may only appear in YEARLY recurrences ) 
 
A rule may 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

There are no restrictions regarding use of date rule parts and
time rule parts. There are no restrictions with using any combination
of time rule parts

[ The following is a change to section 4.3.10]

Change:

   The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
   44) separated list of values which corresponds to the nth occurrence
   within the set of events specified by the rule. Valid values are 1 to
   366 or -366 to -1. It MUST only be used in conjunction with another
   BYxxx rule part

To: 

   The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
   44) separated list of values which corresponds to the nth occurrence
   within the set of events specified by the rule. Valid values are 1 to
   31622401 or -31622401 to -1. It MUST only be used in conjunction
   with another BYxxx rule part

[31622401 is the number of seconds in a year plus a leap second, 366 *
24 * 60 * 60 + 1]

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 29 Mar 2001 04:21:43 -0500 (EST)

> single recurrence rule. Date BYxxx rule part restrictions are:

What's the motivation for this?  Is the idea to forbid self-contradictory
rules, ones that never result in any recurrence at all?

It's not clear to me that that's really necessary.  A self-contradictory
rule isn't *ambiguous* -- it's clear that it means "no recurrence at all,
except for the DTSTART."   Mind you, a user interface probably wants to warn
the user if they've constructed a useless recurrence, but there's no
interoperability problem with them.

Also note that self-contradictory rules are still possible with your
restrictions, and I don't think they can in general be eliminated.  Consider
the obvious
RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=31
or the somewhat less obvious
DTSTART;TZID=America/New_York:20010329T0230
DURATION:T20M
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU

In the interest of keeping the spec simple, I'd be inclined to say
"self-contradictory rules are allowed, and they mean no recurrence.  If the
total number of possible recurrences of an event is less than its COUNT
parameter, the COUNT parameter is ignored."

> [31622401 is the number of seconds in a year plus a leap second, 366 *

Is this really sufficient?  Are you sure you don't need the number of
seconds in a 28-year leap year cycle?  (Or worse, a 2800-year Gregorian leap
year cycle, but I'll ignore that for now.)

(This is the reason I dropped bysetpos from CPL...)

-- 
Jonathan Lennox
[email-masked]

---

From: Eric Busboom <[email-masked]>
Date: Thu, 29 Mar 2001 08:41:27 -0800 (PST)

On Thu, 29 Mar 2001, Jonathan Lennox wrote:

> except for the DTSTART."

If you combine all of the date BYxxx rules and date frequencies, you get
128 possible combinations. Of these, 92 are declared invalid under the
proposed changes. These 92 rule combinations are either always nonsense or
are frequently enough nonsense that they are not very useful. 

Now, if a rule is nearly always useless, then why create a specification
that requires implementers to write code for it? In nearly all
of the cases, if you really wanted to express the rule you
could add an EXRULE to achieve the same effect. Recurrences are hard
enough to implement without the additional work of 92 mostly useless
rules. 

Furthermore, past discussions on the list indicate that implementers will
interpret the spec inconsistently for these rules. The spec must resolve
any confusion, and recurrences have generated plently of confusion.  

> RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU

Sure we can't eliminate everything. But this example is a sensible
combination with out-of-range values. On the other hand, 

	RRULE:FREQ=DAILY;BYDAY=SU;BYWEEKNO=23,34,50;BYMONTHDAY=15

is almost always nonsense and is never very useful. If that is what you
really want to say, use an EXRULE or a set of RDATES

The core problem right now is not that the recurrence spec is too complex,
but that it cannot be implemented interoperably, The proposed changes
answer some questions that, if left unanswered, would fairly ensure
different interpretations of some recurrence rules. 

eric.