Subject: [Ietf-calsify] working group last call comments for draft-ietf-calsify-rfc2445bis-07.txt

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Sep 13 13:19:04 2007

Eliot Lear wrote:
> Dear all,
> 
> Working Group Last Call (WGLC) has now closed for 
> draft-ietf-calsify-rfc2445bis-07.txt.  We received two messages during 
> WGLC.  There are two forms of comments we will address: editorial and 
> substantial changes.  The editor may use his discretion accept or reject 
> editorial comments.  The working group must consider proposals for 
> substantial changes.  What follows is the chair's opinion as to what is 
> editorial and what is substantial:
> 
> On the 3rd of August, Bernard proposed a change to close Issue 63.   I 
> view this change as substantial and requiring working group input.
> 
> Now, breaking up Nigel Swinson's message of the 1st of August (thank 
> you, Nigel):
> 
>> 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."
>>   
> 
> Editorial.

Done.

> 
>> 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."
>>   
> 
> Substantial if reverting means changing the actual text of the invitation.
> 
>> 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
>>   
> 
> Editorial.

Done.

> 
>>       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
>>   
> 
> 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.

> 
>>       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

Done.

>>       "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
>>   
> 
> This seems to be editorial.

Done.

> 
>>       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.
>>
>>   
> Again, editorial.

Done.

> 
>>       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.
>>   
> 
> While some might view this as substantial, I believe this is editorial 
> because the working group discussed the intent here in depth, and Nigel 
> is correct in my opinion as to our interpretation.

Done.

> 
>> 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
>>   
> 
> Editorial.

Done.

> 
>>       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:
>>   
> 
> Substantial.

Not changed.

> 
>>         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.
>>   
> 
> 
> Substantial and editorial.  The combining of boxes is editorial.

Not changed for now.

> 
>> 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.
>>   
> 
> Editorial.

Done.

> 
>> 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.
>>   
> 
> Editorial.

Done.

> 
>> 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
>>   
> 
> Editorial.

Done.

> 
>> 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
>>   
> 
> Editorial.

Done.

> 
>>       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-
>>   
> 
> Editorial.  Suggestion: "this property differs from".

Done.

Nigel: Thanks a lot!

Cheers,
Bernard

> 
>>       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
>>
>>   
> 
> Thanks again,
> 
> Eliot
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: lear at cisco.com (Eliot Lear)
Date: Thu Sep 27 07:57:00 2007

Nigel,

Please wade through the below.  Would others please comment as well?

> The existing text has this:
>
>       ...  In
>       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
>  +      rule part MUST always be specified as a date with UTC time, with the
> Or:
>        time.  If the "DTSTART" property is specified as a date with
> -       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
> +       the UNTIL rule part MUST be specified as a date with UTC time.
> +       If the UNTIL and COUNT rule parts are not

Bernard will propose some cleaned up text to address your issues.

>>>> - Change the example to illustrate what obscurity it was that lead to
>>>>         
> the
>   
>>>> need for the new text.
>>>>
>>>>       occurrence within the set of recurrence instances specified by
>>>>         
> the
>   
>>>> -      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
>   
> 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?
>   

There seems to be agreement.  Bernard will propose text.

>   
>>>> The phrase "special expand" is mentioned nowhere else in the document.
>>>>         
> I
>   
>>>> You merge the "Expand" cells in the Yearly/Monthly columns to
>>>>         
> illustrate
>   
>>>> adequately dealt with in the paragraphs above on ByDay.  So I'd make
>>>>         
> it:
>   
>>>> -   |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|       |
>>>>         
> |
>   
>>>> +
>>>>         
>>>> -      Note 1:  Limit if BYMONTHDAY is present, otherwise special
>>>>         
> expand
>   
>>>> -            for MONTHLY.
>>>> -
> BYDAY work
>>>> +      a range of valid instances, and when used in combination it is
>>>>         
> the union
>   
>>>> +      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
>   
> the first
> 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.
>   

Would people please comment on Nigel's proposed change?

Thanks!

Eliot