Subject: [Ietf-calsify] 2445bis problem

From: Cyrus Daboo <[email-masked]>
Date: Fri, 14 Mar 2008 17:13:21 -0400

Hi,
I think there is a problem in the recurrence description section 3.3.10 in 
2445bis:

    The numeric value in a BYDAY rule part with the FREQ rule part set to
    YEARLY corresponds to an offset within the month when the BYMONTH rule
    part is present, and corresponds to an offset within the year when the
    BYWEEKNO or BYMONTH rule parts are present.

BYMONTH is special-cased twice with different meaning.

It also goes on to state:

    Furthermore, the BYDAY rule part MUST NOT be specified with a numeric
    value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part
    is specified.

However, that means the BYWEEKNO description in the earlier statement is 
bogus!

At this point, I have to say I am still slightly confused about all the 
combinations of BYDAY plus the other BYxxx's. I really think more clarity 
is needed here - even at this late stage.

I am going to try and put together a complete set of examples for all the 
possible combinations of numeric/non-numeric BYDAY with YEARLY/MONTHLY and 
other BYxxx rules and see whether all those make sense in terms of the 
current statements in 2445bis.

This might take a while but I think is an important step to verify that we 
have the description of all these BYxxx's right.

-- 
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Reinhold Kainhofer <[email-masked]>
Date: Fri, 14 Mar 2008 22:25:12 +0100

>     value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part

Doesn't this make it impossible to recur on yearly on e.g. Wednesday of 
calendar week 3? Notice that if Jan 1 is a Thursday, that's the second 
Wednesday of the year, in all other cases it's the third Wednesday...

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 14 Mar 2008 17:32:02 -0400

Hi Reinhold,

--On March 14, 2008 10:25:12 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

>>     Furthermore, the BYDAY rule part MUST NOT be specified with a
>> numeric     value with the FREQ rule part set to YEARLY when the
>> BYWEEKNO rule part     is specified.
>

Isn't that just:

RRULE:FREQ=YEARLY;BYWEEKNO=3;BYDAY=WE

Are you saying that you might want to only pick the instance if its the 2nd 
Wednesday of the year?

-- 
Cyrus Daboo

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 17 Mar 2008 13:05:45 -0000

> However, that means the BYWEEKNO description in the earlier statement is

Agreed :o)  Irritatingly I made this very point to the list on the 8th Feb
this year, but the post got eaten. :o(

> is needed here - even at this late stage.

I've been lobbying for this for quite some time.  Sadly our company wanted
to change email addresses from rockliffe.com to mailsite.com and in the
change the calsify list software has been silently ignoring may last 5 posts
to this list (I would have expected a bounce).  I shall re-post them once
I've persuaded to listen to me at mailsite.com.  Ironically one of the
messages it ate was as below:

From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 08, 2008 4:14 PM
Subject: [Ietf-calsify] working group last call comments for
draft-ietf-calsify-rfc2445bis-07.txt]

> While reviewing
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08,
> I wondered what would happen about recurrence rules, as I'd not seen much
> discussion on the list on the topic.  Looking in the archive, I notice
that
> the attached message never made it to the archive, and thus possibly never
> made it to any of you.  I guess that would partly explain the lack of
> response, although I suspect it is largely because recurrence rules are
> complex with a lot of corner cases, and it's hard to think about them.
This
> is the very reason why I am proposing changes, to make that difficult and
> error prone area as easy as possible to understand.
>
> While I attach my message from September, I shall include re-send each
open
> item as a separate thread, in the hope that folks might respond to at
least
> one of the three open issues.
>
> Nigel

Subject: Re: [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt
From: "Nigel Swinson" <[email-masked]>
To: "CALSIFY Mailinglist" <[email-masked]>
Cc: "Bernard Desruisseaux" <[email-masked]>, "Eliot Lear" <[email-masked]>
Date: Fri, 21 Sep 2007 17:15:28 +0100

> Hi Nigel,
>
> "Not changed for now" meant that I would not do the change
> until we have had input from the working group.
>
> Cheers,
> Bernard

Ok so there are 3 issues remaining from my feedback, two of which require
additional input from the working group to proceed.  So could folks please
have a read through and comment?  I care about the third one the most...

> >> 3.3.10.  Recurrence Rule
> >>
> >>       The UNTIL rule part defines a DATE or DATE-TIME value which
bounds
> >>       the recurrence rule in an inclusive manner.  If the value
> >>       specified by UNTIL is synchronized with the specified recurrence,
> >>       this DATE or DATE-TIME becomes the last instance of the
> >>       recurrence.  The value of the UNTIL rule part MUST have the same
> >>       value type as the "DTSTART" property.  Furthermore, if the
> >>       "DTSTART" property is specified as a date with local time, then
> >>       the UNTIL rule part MUST also be specified as a date with local
> >>       time.  If the "DTSTART" property is specified as a date with
> >>       UTC time or a date with local time and time zone reference, then
> >>       the UNTIL rule part MUST be specified as a date with UTC time.
In
> >>       the case of the "STANDARD" and "DAYLIGHT" sub-components the
UNTIL
> >> -      rule part MUST always be specified as a date with UTC time.  If
> >> -      specified as a DATE-TIME value, then it MUST be specified in a
UTC
> >> -      time format.  If not present, and the COUNT rule part is also
not
> >> +      rule part MUST always be specified as a date with UTC time,
> >> with the
> >> +      "DTSTART" always represented as a date with local time.  If the
> >> UNTIL
> >> +      and COUNT rule parts are not
>>>          present, the "RRULE" is considered to repeat forever.
> >>
> >
> > Substantial.
>
> Nigel's addition is not substantial.  It is repeating what is
> already specified in section 4.6.5 "Time Zone Component" of
> RFC 2445, that is:
>
>     The mandatory "DTSTART" property gives the effective onset date and
>     local time for the time zone sub-component definition. "DTSTART" in
>     this usage MUST be specified as a local DATE-TIME value.
>
> I'm not convinced we should repeat this information.
>
> No change done.

The existing text has this:

      ...  In
      the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
      rule part MUST always be specified as a date with UTC time.  If
      specified as a DATE-TIME value, then it MUST be specified in a UTC
      time format. .......

One of my objectives was to get rid of the second sentence, as I don't think
it adds anything, and in the context of the whole paragraph it's confusing
to know what the second sentence is even refering to.  If this second
sentence is to stay could someone please explain what it adds?

My second objective was indeed to correlate more fully the relationship
between DTSTART and UNTIL as it says in 4.6.5.  The start of the paragraph
has described this relationship in detail for DTSTART and UNTIL under normal
circumstances, but then goes on to talk about the behaviour within the
STANDARD/DAYLIGHT components.  I think either it should leave all the
discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or
complete the discussion by saying, as I had suggested, that UNTIL is always
date with UTC time and DTSTART is always date with local time.

My third objective was to cleanup the language of the last sentence.

So please can we have either:

       time.  If the "DTSTART" property is specified as a date with
       UTC time or a date with local time and time zone reference, then
       the UNTIL rule part MUST be specified as a date with UTC time.  In
       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
 -      rule part MUST always be specified as a date with UTC time.  If
 -      specified as a DATE-TIME value, then it MUST be specified in a UTC
 -      time format.  If not present, and the COUNT rule part is also not
 +      rule part MUST always be specified as a date with UTC time, with the
 +      "DTSTART" always represented as a date with local time.  If the
UNTIL
 +      and COUNT rule parts are not
       present, the "RRULE" is considered to repeat forever.

Or:

       time.  If the "DTSTART" property is specified as a date with
       UTC time or a date with local time and time zone reference, then
-       the UNTIL rule part MUST be specified as a date with UTC time.  In
-       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
-       rule part MUST always be specified as a date with UTC time.  If
-       specified as a DATE-TIME value, then it MUST be specified in a UTC
-       time format.  If not present, and the COUNT rule part is also not
+       the UNTIL rule part MUST be specified as a date with UTC time.
+       If the UNTIL and COUNT rule parts are not
       present, the "RRULE" is considered to repeat forever.

> >> WRT to the text below I think we should either:
> >> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules,
> >> - Specify what the "interval" for daily, hourly, minutely, secondly
> >> means.
> >> - Drop the new text, as I think the example is sufficient illustration.
> >> - Change the example to illustrate what obscurity it was that lead to
the
> >> need for the new text.
> >>
> >> My vote would be to drop some of the new text to become:
> >>
> >>       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 recurrence instances specified by
the
> >>       rule.  BYSETPOS operates on a set of recurrence instances in one
> >> -      interval of the recurrence rule.  For a WEEKLY rule, the
interval
> >> -      is one week, for a MONTHLY rule, one month, and for a YEARLY
rule,
> >> -      one year.  Valid values are 1 to 366 or -366 to -1.  It MUST
only
> >> +      interval of the recurrence rule.
> >> +      Valid values are 1 to 366 or -366 to -1.  It MUST only
> >>       be used in conjunction with another BYxxx rule part.  For example
> >>       "the last work day of the month" could be represented as:
> >>
> >>         FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
> >>
> >>       Each BYSETPOS value can include a positive (+n) or negative (-n)
> >>       integer.  If present, this indicates the nth occurrence of the
> >>       specific occurrence within the set of occurences specified by the
> >>       rule.
> >
> > Substantial.
>
> Not changed.

I think this is important, as currently we have it's an inconsistent level
of specification, which I think leaves it vague what BYSETPOS means with
daily, hourly, minutely, secondly.  Could people please comment/vote?

> >> The phrase "special expand" is mentioned nowhere else in the document.
I
> >> think the concept was better expressed by my suggestion from the 29th
May.
> >> You merge the "Expand" cells in the Yearly/Monthly columns to
illustrate
> >> that each creates a set, and when taken together it's the union of the
sets.
> >> Also even with a numeric modifier on ByDay, it's still the case that
> >> Monthly/Yearly + BYDAY will expand, and while it's true that numeric
> >> modifiers on ByDay with yearly rules requires attention, I think it's
> >> adequately dealt with in the paragraphs above on ByDay.  So I'd make
it:
> >>
> >> -      BYDAY has some special behaviour depending on the FREQ value and
> >> -      this is described in separate notes below the table.
> >>
> >>    +----------+--------+--------+-------+-------+------+-------+------+
> >>    |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
> >>    +----------+--------+--------+-------+-------+------+-------+------+
> >> -   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit
|Expand|
> >> -
+----------+--------+--------+-------+-------+------+-------+------+
> >> -   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A
|Expand|
> >> -
+----------+--------+--------+-------+-------+------+-------+------+
> >> -   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A
|Expand|
> >> -
+----------+--------+--------+-------+-------+------+-------+------+
> >> -   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand
|Expand|
> >> -
+----------+--------+--------+-------+-------+------+-------+------+
> >> -   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note
2|
> >> -
+----------+--------+--------+-------+-------+------+-------+------+
> >> +   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |
|
> >> +   +----------+--------+--------+-------+-------+------+-------+
+
> >> +   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |
|
> >> +   +----------+--------+--------+-------+-------+------+-------+
+
> >> +   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A
|Expand|
> >> +   +----------+--------+--------+-------+-------+------+-------+
+
> >> +   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |       |
|
> >> +   +----------+--------+--------+-------+-------+------+Expand +
+
> >> +   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|       |
|
> >> +
+----------+--------+--------+-------+-------+------+-------+------+
> >>    |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
> >>    +----------+--------+--------+-------+-------+------+-------+------+
> >>    |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
> >>    +----------+--------+--------+-------+-------+------+-------+------+
> >>    |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
> >>    +----------+--------+--------+-------+-------+------+-------+------+
> >>    |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
> >>    +----------+--------+--------+-------+-------+------+-------+------+
> >>
> >> -      Note 1:  Limit if BYMONTHDAY is present, otherwise special
expand
> >> -            for MONTHLY.
> >> -
> >> -      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
> >> -            special expand for WEEKLY if BYWEEKNO present, otherwise
> >> -            special expand for MONTHLY if BYMONTH present, otherwise
> >> -            special expand for YEARLY.
> >>
> >> +      In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and
BYDAY work
> >> +      together to expand the recurrence set.  Each on their own will
specify
> >> +      a range of valid instances, and when used in combination it is
the union
> >> +      of all ranges that create the required recurrence set.  So for
example
> >> +      in a YEARLY rule BYDAY=MO will mean every Monday, and
BYMONTHDAY=1 will
> >> +      mean the first of every month, so when used together they mean
the first of
> >> +      every month, but only when it's a Monday.  It would not mean on
the first
> >> +      of every month and also on every Monday.  Likewise in MONTHLY
rules,
> >> +      BYMONTHDAY and BYDAY work together to expand the recurrence set.
> >>
> >
> >
> > Substantial and editorial.  The combining of boxes is editorial.
>
> Not changed for now.
>

Rather than give you lots more text to read, can I just urge you to (re)read
the text above and provide opinions.  I think recurrence is the most
complicated part of iCalendar, and think it's worth crafting the addition of
the new table just a little more.

> Nigel: Thanks a lot!

You are most welcome.  Thanks for processing my feedback :o)

Nigel