Subject: "Re: [Ietf-calsify] Working Group Last Call:draft-ietf-calsify-rfc2445bis-07.txt

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Wed Aug 1 08:47:09 2007

Below are my assorted notes based on reviewing the diff from v6 to v7.  I
confess I haven't mustered the energy yet to do as Elliot sensibly suggests
and review the document as a whole, but I was still able to find a number of
editorial corrections most of which aren't too controvertial, but there's
some, specificially recurrence rule related that might be more contentious.

Version 7 contains numerous additions of this form:

    "Applications MUST treat x-name and iana-token value they don't
    recognized the same way as the XXXX value."

I don't think this is gramatically correct.  I'd suggest:

    "Applications MUST treat x-name and iana-token values they don't
    recognize the same way as they would the XXXX value."

Or better still rely on the existing description of what the default value
is:

    "Applications MUST ignore x-name and iana-token values they don't
    recognize and revert to the default value for the parameter."

This comment applies to:
- 3.2.  Property Parameters
- 3.2.3.  Calendar User Type
- 3.2.9.  Free/Busy Time Type
- 3.2.12.  Participation Status
- 3.2.14.  Relationship Type
- 3.2.15.  Participation Role
- 3.2.19.  Value Data Types
- 3.8.1.3.  Classification
- 3.8.6.1.  Action

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.  Else, if the "DTSTART" property is specified as a date with
+      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.

Below I've re-ordered the sentences in addition to changing one word.  I
find changing from "the specific day" to "a specific day" helpful in warning
that 3MO in a yearly rule isn't necessarily "the 3rd Monday in the year" and
rather "a 3rd Monday in the year".  Later we go on to describe in more
detail how to interpret "a 3rd Monday in the year".

      Each BYDAY value can also be preceded by a positive (+n) or
      negative (-n) integer.  If present, this indicates the nth
-      occurrence of the specific day within the MONTHLY or YEARLY
+      occurrence of a specific day within the MONTHLY or YEARLY
      "RRULE".  For example, within a MONTHLY rule, +1MO (or simply 1MO)
      represents the first Monday within the month, whereas -1MO
-      represents the last Monday of the month.  If an integer modifier
+      represents the last Monday of the month.  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.
+      If an integer modifier
      is not present, it means all days of this type within the
      specified frequency.  For example, within a MONTHLY rule, MO
      represents all Mondays within the month.  The BYDAY rule part MUST
      NOT be specified with a numeric value when the FREQ rule part is
      not set to MONTHLY or YEARLY.  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.
-      set to YEARLY when the BYWEEKNO rule part is specified.  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.

      The BYYEARDAY rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of days of the year.  Valid values are
      1 to 366 or -366 to -1.  For example, -1 represents the last day
      of the year (December 31st) and -306 represents the 306th to the
      last day of the year (March 1st).  The BYYEARDAY rule part MUST
      NOT be specified when the FREQ rule part is set to DAILY, WEEKLY,
-      and MONTHLY.
+     or MONTHLY.

I think there's too many negatives in what was there:

      The BYWEEKNO rule part specifies a COMMA character (US-ASCII
      decimal 44) separated list of ordinals specifying weeks of the
      year.  Valid values are 1 to 53 or -53 to -1.  This corresponds to
      weeks according to week numbering as defined in [ISO.8601.2004].
      A week is defined as a seven day period, starting on the day of
      the week defined to be the week start (see WKST).  Week number one
      of the calendar year is the first week which contains at least
      four (4) days in that calendar year.  This rule part MUST NOT be
-      used when the FREQ rule part is not set to YEARLY.  For example, 3
+      used when the FREQ rule part is set to anything other than YEARLY.
+      For example, 3
      represents the third week of the year.

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.

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.

3.6.  Calendar Components

   An iCalendar object MUST include the "PRODID" and "VERSION" calendar
   properties.  In addition, it MUST include at least one calendar
   component.  Special forms of iCalendar objects are possible to
   publish just busy time (i.e., only a "VFREEBUSY" calendar component)
   or time zone (i.e., only a "VTIMEZONE" calendar component)
   information.  In addition, a complex iCalendar object that is used to
   capture a complete snapshot of the contents of a calendar is possible
   (e.g., composite of many different calendar components).  More
   commonly, an iCalendar object will consist of just a single "VEVENT",
   "VTODO" or "VJOURNAL" calendar component.  Applications MUST ignore
-   x-comp and iana-comp they don't recognized.
+   x-comp and iana-comp they don't recognize.

3.8.1.1.  Attachment

   Conformance:  This property can be specified multiple times in a
      "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with
-      the exception of AUDIO alarm which only allow this property to
+      the exception of AUDIO alarm which only allows this property to
      occur once.

3.8.2.3.  Date/Time Due

-   Description:  This property defines the date and time that a to-do is
+   Description:  This property defines the date and time before which a
to-do is
      expected to be completed.  For cases where this property is
      specified in a "VTODO" calendar component that also specifies a
      "DTSTART" property, the value type of this property MUST be the
      same as the "DTSTART" property, and the value of this property
      MUST be later in time than the value of the "DTSTART" property.
      Furthermore, this property MUST be specified as a date with local
      time if and only if the "DTSTART" property is also specified as a
      date with local time.

3.8.6.2.  Repeat Count
-   Description:  This property defines the number of time an alarm
+   Description:  This property defines the number of times an alarm
      should be repeated after its initial trigger.  If the alarm
      triggers more than once, then this property MUST be specified
      along with the "DURATION" property.

3.8.7.2.  Date/Time Stamp

      In the case of an iCalendar object that specifies a "METHOD"
-      property, this property is different than the "CREATED" and "LAST-
+      property, this property is different to the "CREATED" and "LAST-
      MODIFIED" properties.  These two properties are used to specify
      when the particular calendar data in the calendar store was
      created and last modified.  This is different than when the
      iCalendar object representation of the calendar service
      information was created or last modified.

Cheers,

Nigel