[Ietf-calsify] working group last call commentsfor
draft-ietf-calsify-rfc2445bis-07.txt
Eliot Lear
lear at cisco.com
Thu Sep 27 07:55:25 PDT 2007
Nigel,
Please wade through the below. Would others please comment as well?
>
>> 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.
>
>
Bernard will propose some cleaned up text to address your issues.
>>>> 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?
>
There seems to be agreement. Bernard will propose text.
>
>>>> 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.
>
Would people please comment on Nigel's proposed change?
Thanks!
Eliot
More information about the Ietf-calsify
mailing list