Subject: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY

From: lear at cisco.com (Eliot Lear)
Date: Fri Aug 10 00:24:33 2007

Please send your comments to the list.

Thanks,

Eliot

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Aug 13 08:57:40 2007

I'm very sorry -- I should have sent these comments earlier.  (I was sick on
Friday, and did not see the reminder e-mail until this morning.)

I have several comments on section 3.3.6 (DURATION).

First of all, one of the items in the text I sent in May (in the message
<http://lists.osafoundation.org/pipermail/ietf-calsify/2007-May/001707.html>)
didn't get applied to this draft; I think it's uncontroversial but a fairly
important corner case.

Add the text (wordsmithing as appropriate):

+      If the local time when a nominal duration would end does not exist,
+      or occurs more than once, in the duration's timezone, it is
+      interpreted in the same manner as an explicit DATE-TIME value
+      describing that date and time, as specified in section 3.3.5.

Editorially, this section has the problem that it uses the terms "nominal
duration", "accurate duration", and "exact duration" without defining them.
The definitions can be semi-inferred from context, but I'd be curious if
someone who hasn't wrestled with these issues as much as I have can
understand the text.

I also think that the discussion of adding weeks, days, hours, minutes, and
seconds in that strict order -- when actually all that matters is that
nominal durations (weeks + days) be added before accurate durations (hours,
minutes, and seconds) -- is confusing; it leads the reader to think there's
some significance to the order of the arithmetic operations within each section.

I have two spelling/grammar fixes in this section as well:

       The duration of a week or a day depends on its position in the
       calendar.  In the case of discontinuities in the time scale, such
       as the change from standard time to daylight time and back, the
-      computation of the exact duration requires the substraction or
+      computation of the exact duration requires the subtraction or
       addition of the change of duration of the discontinuity.  Leap
       seconds MUST NOT be considered when computing an exact duration.

...

       No additional content value encoding (i.e., BACKSLASH character
-      encoding) are defined for this value type.
+      encoding) is defined for this value type.

The one other stylistic comment I'd make on the changes introduced in
version -07 is that it's not usually appropriate to use contractions
("don't", "doesn't", etc.) in formal standards writing.  These should be
expanded to "do not", "does not", etc.

-- 
Jonathan Lennox
[email-masked]

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Aug 13 09:09:41 2007

One other issue occured to me on exact vs. nominal durations.

The definition of RRULE says:

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.

This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I think
it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE.  In
this latter case, I think it's clear that the desired outcome is always
for the event to last a nominal number of days, not the exact duration of
time of the first instance of the recurrence set.

Is this worth addressing?

-- 
Jonathan Lennox
[email-masked]

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Aug 13 10:52:41 2007

There's one other comment I had that Bernard asked me about at the Chicago
IETF.

The section on RRULE says that

      The "DTSTART" property
      value SHOULD match the pattern of the recurrence rule, if
      specified.  The recurrence set generated with a "DTSTART" property
      value that doesn't match the pattern of the rule is undefined.

(For some reason I don't understand, this text also appears in the RDATE and
EXDATE sections, but leave that aside for now.)

The question is whether the DTSTART can match "the pattern of the recurrence
rule" if the rule specifies BYSETPOS values not including the value 1.  If
"the pattern" has its obvious definition, I think that it can't.

The obvious fix would be to change the above to

    The "DTSTART" property value SHOULD match the pattern of the recurrence
    rule (not including any BYSETPOS value), if specified.

-- 
Jonathan Lennox
[email-masked]

---

From: lear at cisco.com (Eliot Lear)
Date: Tue Aug 14 05:15:10 2007

Jonathan,

Thank you for your comments.  So long as there are no objections I see 
no reason not to include them as part of last call comments.  Let's just 
go through this set as I did the others.

Please see below.

> +      describing that date and time, as specified in section 3.3.5.

Substantial.
>        seconds MUST NOT be considered when computing an exact duration.

Editorial.

> +      encoding) is defined for this value type.

Editorial.
> expanded to "do not", "does not", etc.

Editorial.

Eliot

---

From: lear at cisco.com (Eliot Lear)
Date: Tue Aug 14 05:16:52 2007

> Is this worth addressing?

Substantial

---

From: lear at cisco.com (Eliot Lear)
Date: Tue Aug 14 05:17:23 2007

Substantial.