Re: [calsify] [Technical Errata Reported] RFC5545 (6109)

[Michael H Deckers <[e-mail]>]

On 2020-04-19 06:50, RFC Errata System wrote:
> 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/eid6109
>
> --------------------------------------
> Type: Technical
> Reported by: Lars Henriksen <[e-mail]>
>
> Section: 3.6.1
>
> Original Text
> -------------
> The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND"
> property value is set to a calendar date after the "DTSTART" property value).
>
> Corrected Text
> --------------
> The anniversary type of "VEVENT" can span more than one date (i.e., "DTEND"
> property value is set to a calendar date at least two days after the "DTSTART"
> property value).
>
> Notes
> -----
> "DTEND" comes, by definition (3.8.2.2), always after "DTSTART". The span (duration) is the difference between the two.


     I find the last sentence of the Note misleading.
     The expression
          "span more than one date"
     does not state the duration of the event -- it
     rather is meant to say that the interval contains
     a midnight in its interior (at which the date
     changes).

     Since the DTSTARTs and DTENDs of anniversaries
     are DATEs, the length must be at least two days
     so that a midnight can be in the interior.

     I propose to reword the Note to:

        "DTEND" comes, by definition (3.8.2.2), always after "DTSTART".
        An event spans two or more dates if it contains a midnight
        instant strictly between DTSTART and DTEND. When DTSTART and
        DTEND are DATEs then this can happen only if the length
        of the event is two days or more.

     Michael Deckers.



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