Subject: Recurrence Rules Issue Summary

From: Eric Busboom <[email-masked]>
Date: Mon, 11 Dec 2000 23:11:14 -0800 (PST)

Here are the recorded issues with recurrence rules and some proposed
text.

eric. 

(1) In a YEARLY frequency with BYMONTH and/or BYWEEKNO set, does the
BYDAY modifier apply to the year day, the month day, or the week day?

(2) The BYYEARDAY part, for a given year, effectively specifies the month,
day of month, and week number, so other BYXX rule parts for month,
day of month and week number may conflict.

(3) BYWEEKNO implies a month, conflicting with BYMONTH

(4) MONTHLY recurrences (FREQ=MONTHLY) conflict with BYYEARDAY and
BYWEEKNO.

(5) WEEKLY recurrences (FREQ=WEEKLY) conflict with BYMONTHDAY and
BYYEARDAY.

(6) BYSETPOS is limited to 366 positive values or 366*2 positive and
negative values in a sufficiently large set. A complete expansion for
every second in every day of the year would result in much larger
sets. ( Do we need BYSETPOS? ) 

(7) The algorithm to calculate the first week in the year may be
awkward, since some people/countries may be used to other numbering
schemes.  Maybe there should be a choice of a few schemes for
this.

(8) What do you do with a WEEKLY recurrence if it has BYDAY=2TU ?

Some proposed text, an addition to RFC2445, section 4.3.10. Numbers in
parenthesis refer to the problems listed above.

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

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 periods less than 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:

        [a] If the BYYEARDAY part appears in a rule , no other date rule
        part may appear. (2)

        [b] BYWEEKNO and BYMONTH rule parts may not both appear. (3)
        [ except when week covers two months?]

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

        [c] For MONTHLY recurrences neither BYYEARDAY nor
        BYWEEKNO may appear. (4)

        [d] For WEEKLY recurrences neither BYMONTHDAY nor
        BYYEARDAY may appear. (5)
 
There are no restrictions regarding combinations of date rule parts and
time rule parts. There are no restrictions with using any combination of
time rule part.

For FREQ=WEEKLY, BYDAY rule parts MUST have integer values of 1, or
the integer value MUST be omitted.  "FREQ=WEEKLY;BYDAY=TU" is valid,
but "FREQ=WEEKLY;BYDAY=2TU" is not. (8)

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

The text does not address (1), (6) and (7)

---

From: John Stracke <[email-masked]>
Date: Tue, 12 Dec 2000 11:44:36 -0500

> parenthesis refer to the problems listed above.

The proposed text looks good; we might also want to consider recommending
what to do if you get a noncompliant iCalendar that contains a conflict.  You
could just flag the error, of course.  If you don't, though, it might be
useful to have a rule of thumb like "if two specifiers conflict, then the one
that refers to a larger unit of time takes precedence".  So, for example,
BYYEARDAY takes precedence over BYMONTH.  This would mean that, if I send out
a noncompliant iCalendar to N people, at least they'll all agree on what it
means--there can still be confusion, but less than if each of them interprets
it differently.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Lollygaggers will be shot on sight!" "I didn't|
[email-masked]|say that!" "I was paraphrasing."               |
\================================================================/

---

From: Federico Mena Quintero <[email-masked]>
Date: Tue, 12 Dec 2000 14:18:55 -0600

> means--there can still be confusion, but less than if each of them interprets

Is it not just easier to mark it as an invalid component and ignore
it, warning the user about it?  It seems to me that trying to fix up
broken components on the fly will lead to implementations that do
different things in badly inconsistent ways.

  Federico

---

From: John Stracke <[email-masked]>
Date: Tue, 12 Dec 2000 16:17:44 -0500

Federico Mena Quintero wrote:

> > what to do if you get a noncompliant iCalendar that contains a conflict.
>
> it, warning the user about it?

Usually.  This is mostly for edge cases--for example, if the user is a robot, and
can't talk the problem over with the sender.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |I'm a zygote, he's a zygote, she's a zygote, |
[email-masked]|wouldn't you like to be a zygote, too?       |
\==============================================================/