Subject: [calsify] [Technical Errata Reported] RFC5545 (6212)

From: RFC Errata System <[email-masked]>
Date: Tue, 23 Jun 2020 07:56:48 -0700 (PDT)

The following errata report has been submitted for RFC5545,
"Internet Calendaring and Scheduling Core Object Specification (iCalendar)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6212

--------------------------------------
Type: Technical
Reported by: Lars Henriksen <[email-masked]>

Section: 3.8.5.3

Original Text
-------------
      Daily until December 24, 1997:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=DAILY;UNTIL=19971224T000000Z

       ==> (1997 9:00 AM EDT) September 2-30;October 1-25
           (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23

Corrected Text
--------------
      Daily until December 24, 1997:

       DTSTART;TZID=America/New_York:19970902T090000
       RRULE:FREQ=DAILY;UNTIL=19971224T140000Z
                                       ^^
       ==> (1997 9:00 AM EDT) September 2-30;October 1-25
           (1997 9:00 AM EST) October 26-31;November 1-30;December 1-24
                                                                     ^^

Notes
-----
The UNTIL rule part has value type DATE-TIME (same as DTSTART), but the introductory text "Daily until December 24, 1997" mentions a DATE only. Assuming that "until", like UNTIL, is inclusive, I would expect

    (1997 9:00 AM EST) December 24

to be the last instance, i.e. the unstated time is 9:00 AM. Translating to UTC you get

    19971224T140000Z

The same error occurs in all examples of section 3.8.5.3 with "December 24, 1997", four in all: pages 123 (above), 125 (twice) and 126. The resulting occurrences are only affected for pages 123 and 125 (second).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5545 (draft-ietf-calsify-rfc2445bis-10)
--------------------------------------
Title               : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Publication Date    : September 2009
Author(s)           : B. Desruisseaux, Ed.
Category            : PROPOSED STANDARD
Source              : Calendaring and Scheduling Standards Simplification
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 24 Jun 2020 11:02:39 +1000

Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it says (the last one will be on Dec 23 as the UNTIL time is before 9am); there's no requirement for the UNTIL to align exactly with an occurrence. However, the English description above says "until December 24", which I would probably interpret as inclusive too. Perhaps this is what should change (to say December 23) rather than the DTSTART/RRULE and dates?

Neil.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jun 2020 09:35:31 +0200

Hiya,

> On 24 Jun 2020, at 03:02, Neil Jenkins <[email-masked]> wrote:
> 

Either change would be fine, but as reported, Lars' corrected text is correct, and since he took the time to report it, I suggest that we mark this erratum as verified because the original text could lead to confusion about what the meaning of UNTIL is.

Eliot

---

From: Lars Henriksen <[email-masked]>
Date: Wed, 24 Jun 2020 09:44:41 +0200

On Wed, Jun 24, 2020 at 11:02:39AM +1000, Neil Jenkins wrote:
> 
>    Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it says
>    (the last one will be on Dec 23 as the UNTIL time is before 9am); there's no
>    requirement for the UNTIL to align exactly with an occurrence. However, the
>    English description above says "until December 24", which I would probably
>    interpret as inclusive too. Perhaps this is what should change (to say
>    December 23) rather than the DTSTART/RRULE and dates?

That wouldn't solve the ambiguity.

The problem is how to convert "December 24, 1997" to a DATE-TIME value type. In
doing that you have to choose a local time. Look at the example on page 124:

    Every day in January, for 3 years:

     DTSTART;TZID=America/New_York:19980101T090000

     RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z;
      BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
     or
     RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1

Here the problem occurs for "January 31, 2000".

Lars

---

From: Lars Henriksen <[email-masked]>
Date: Wed, 24 Jun 2020 13:05:43 +0200

On Wed, Jun 24, 2020 at 09:35:31AM +0200, Eliot Lear wrote:
> 
>    On 24 Jun 2020, at 03:02, Neil Jenkins <[1][email-masked]> wrote:
> 
>    Either  change would be fine,

Hmm, not quite.

The example should illustrate how to interpret an English text like "until
December 24, 1997" for an UNTIL rule part of value type DATE-TIME. In doing
that you have to pick a local time from the context.

The UNTIL value of the example converted to local time is

     7:00 PM EST, December 23, 1997,

which certainly is after 9am and eliminates December 24, but seems completely
arbitrary.

Lars

---

From: Lars Henriksen <[email-masked]>
Date: Tue, 30 Jun 2020 17:26:03 +0200

The erratum hasn't aroused much interest, possibly because it concerns an
example that isn't normative? What purpose do examples then serve? I assume they
are there to illustrate and clarify the use of normative rules and regulations.
The example in question does the opposite. It is confusing and obscure. I'll
explain.

The event

    (1997 9:00 AM EDT) September 2

shall be repeated daily until December 24, 1997. To this end

    (1997 7:00 PM EST) December 23

is used to set the value of the recurrence rule part UNTIL. Because DTSTART is
apecified as a date with time and time zone reference, UNTIL becomes

    UNTIL=19971224T000000Z

Now, please justify the choice of 7pm EST, December 23, 1997.

Lars Henriksen

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 01 Jul 2020 10:07:15 +1000

On Wed, 24 Jun 2020, at 17:35, Eliot Lear wrote:
> Either change would be fine, but as reported, Lars' corrected text is correct, and since he took the time to report it, I suggest that we mark this erratum as *verified*

Sounds reasonable to me.

Neil.