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

From: RFC Errata System <[email-masked]>
Date: Sat, 18 Apr 2020 23:50:46 -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/eid6109

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

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.

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: Michael H Deckers <[email-masked]>
Date: Sun, 19 Apr 2020 10:42:19 +0000

> "Internet Calendaring and Scheduling Core Object Specification (iCalendar)".

     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.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Apr 2020 14:07:22 +0200

Hi Lars and Michael

Please see below.

> On 19 Apr 2020, at 08:50, RFC Errata System <[email-masked]> wrote:
> 
> Type: Technical

It is important to review the wider context of this text:

      The "VEVENT" is also the calendar component used to specify an
      anniversary or daily reminder within a calendar.  These events
      have a DATE value type for the "DTSTART" property instead of the
      default value type of DATE-TIME.  If such a "VEVENT" has a "DTEND"
      property, it MUST be specified as a DATE value also.  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).  If such a "VEVENT" has a "DURATION"
      property, it MUST be specified as a "dur-day" or "dur-week" value.

What this says to me is that DTSTART and DTEND  MUST use DATE values and that DTEND value MAY be greater than that of DTSTART, but it doesn’t have to be with regard to VEVENT.  This situation is a little different with VFREEBUSY.  The text in Section 3.8.2.2 states the following:

   Property Name:  DTEND

   Purpose:  This property specifies the date and time that a calendar
      component ends.

   Value Type:  The default value type is DATE-TIME.  The value type can
      be set to a DATE value type.

   Property Parameters:  IANA, non-standard, value data type, and time
      zone identifier property parameters can be specified on this
      property.

   Conformance:  This property can be specified in "VEVENT" or
      "VFREEBUSY" calendar components.

   Description:  Within the "VEVENT" calendar component, this property
      defines the date and time by which the event ends.  The value type
      of this property MUST be the same as the "DTSTART" property, and
      its value 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.

      Within the "VFREEBUSY" calendar component, this property defines
      the end date and time for the free or busy time information.  The
      time MUST be specified in the UTC time format.  The value MUST be
      later in time than the value of the "DTSTART" property.

What is clear is that a VEVENT may include a DATE in both DTSTART and DTEND, and that the value MAY be the same.  What is LESS clear is whether a VFREEBUSY can include a date.  The grammar for DTSTART and DTEND makes clear that either DATE or DATE-TIME may be specified, but the text in Section 3.6.2 is also prescriptive, where as the text in Section 3.6.4 on VFREEBUSY is not quite so clear.

I would suggest that if there is an erratum here, then it is in either Section 3.6.4 or in 3.8.2.2 in which it should be made clear whether DATE can be used with DTSTART/DTEND in a VFREEBUSY clause.  For certain, if a DATE value is used, my view is that the DTSTART and DTEND values MAY be the same, and that the emboldened text above would be erroneous.

Eliot

---

From: Michael H Deckers <[email-masked]>
Date: Sun, 19 Apr 2020 12:58:53 +0000

On 2020-04-19 12:07, Eliot Lear wrote:

> What this says to me is that DTSTART and DTEND  MUST use DATE values and that DTEND value MAY be greater than that of DTSTART, but it doesn’t have to be with regard to VEVENT. ..[snip]

    In my opinion, a DTEND value can _never_ be the same
    as a DTSTART value, by:

        3.8.2.2. Date-Time End
        ...
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
        property.

    This applies to all DTENDs within a VEVENT, and the same text is
    used in the next paragraph for DTENDs within VFREEBUSY. I do not
    see that anniversaries or daily reminders (being VEVENTs) take
    exception to this MUST rule.

    Regards
    Michael Deckers.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Apr 2020 15:24:12 +0200

Hi Michael

>        its value MUST be later in time than the value of the "DTSTART"

If this is the case, then how would you express the holiday “New Year’s Day” such that it applies to everyone in their respective wall clock times?

Eliot

---

From: "Bron Gondwana" <[email-masked]>
Date: Sun, 19 Apr 2020 23:24:11 +1000

>  its value MUST be later in time than the value of the "DTSTART"

DTEND is so much worse than DURATION for many reasons, and this mess is one of them. We see enough events with DTEND before DTSTART in the real world, let alone zero-length events (though the 10-year-long event which recurred every day was one of the more impressive horror shows to cause discomfort in the recurrence expansion code).

Sadly as with any "MUST" on an archival data format, there are really two choices when you receive one of these - treat it as malformed and reject it, or try to make sense of it. We make sense of backwards DTEND and DTSTART by switching them - and handle zero length events as occurring at the moment - because that generally makes the user happier than an error message.

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Apr 2020 16:23:53 +0200

Hi Bron,

Lots of horror stories.  So long as a DATE is taken to mean DDDDDDDDT000000, and that events begin on that moment and end the second before that moment, then the text is okay.  This is how I believe Apple interprets it and I think is common.

Eliot

---

From: Michael H Deckers <[email-masked]>
Date: Sun, 19 Apr 2020 14:26:35 +0000

On 2020-04-19 13:24, Eliot Lear asked,
    under the condition that DTEND values must

> If this is the case, then how would you express the holiday “New Year’s Day” such that it applies to everyone in their respective wall clock times?

    [This is no longer related with the original question.]

    It suffices to give the DTSTART value as a DATE without any
    DTEND or DURATION since the default duration is 1 d in this
    case ([3.6.1 Event component, p 54]); but one can also give
    explicitly either the DURATION value "P1D" or the "non-inclusive"
    DTEND value such as "2020-01-02".

    Michael Deckers.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 19 Apr 2020 14:17:50 -0400

It strikes me that this is not an erratum, and that the report is a
request for an update, rather than a report of an actual editing error
at the time of publication.

My inclination is to mark it "Rejected", though I can be convinced
that "Held for Document Update" is the right answer, based on the
discussion.  Bernard and Eliot, do you think HFDU is appropriate here?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 19 Apr 2020 15:34:12 -0400

Errata reports are meant to report errors that were missed during
publication. Specifically, they’re things that would have been fixed at the
time, had they been caught then.

We often get reports about things that we now realize are wrong, but we did
not consider them wrong at the time.

We also often get reports about things that people wish were written
differently, for various reason.

In both of those cases, the document says what it was intended to say: no
errata are involved.

Here, we have something more on the edge: the document says exactly what
was meant at the time.  You are pointing out an issue,which, as I see from
the discussion, is a valid discussion point.  Had you brought it up in the
working group, it might very well have resulted in different text in the
RFC.

That’s why I’m considering “Held for Document Update”: any fix for this is
out of the limited scope for errata, and will need more discussion to
resolve the correct text.

See the IESG statement about errata handling for more information about all
this:
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

Barry

On Sun, Apr 19, 2020 at 3:23 PM Lars Henriksen <[email-masked]>
wrote:

> On Sun, Apr 19, 2020 at 02:17:50PM -0400, Barry Leiba wrote:
> What's the difference between "an erratum", "a request for an update" and
> "an actual editing error"?
>
> > My inclination is to mark it "Rejected", ...
>
> The RFC contains a false statement. How else am I supposed to report it?
>
> Lars Henriksen
>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 19 Apr 2020 23:32:56 +0200

Barry,

Having had a second, third, and fourth read, I think the text should be marked hold for update. 

Lars is correct that the text in that section does not support the case where an event is 2 days long.  Is this a serious interoperability problem?  In order for it to be so, a calendar agent would have to improperly represent all anniversaries, and that would be spotted pretty quickly against any other calendar agent.

This having been said, were we to open the document, I would probably unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that talks about DATE DTENDs and copy that into Section 3.8.2.2 and make it plainly normative.

The issue here is the use of the term "non-inclusive” makes perfect intuitive sense for a DATE-TIME event but less so for DATE events.  We should clean that up.

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Sun, 19 Apr 2020 20:07:15 -0400

Ok, that sounds reasonable.  Does anyone object to HFDU here?

Barry

On Sun, Apr 19, 2020 at 5:33 PM Eliot Lear <[email-masked]> wrote:

> Lars is correct that the text in that section does not support the case
> where an event is 2 days long.  Is this a serious interoperability
> problem?  In order for it to be so, a calendar agent would have to
> improperly represent all anniversaries, and that would be spotted pretty
> quickly against any other calendar agent.
>
> This having been said, were we to open the document, I would probably
> unbury text out of Section 3.6.1 (see Our Blissful Anniversary) that talks
> about DATE DTENDs and copy that into Section 3.8.2.2 and make it plainly
> normative.
>
> The issue here is the use of the term "non-inclusive” makes perfect
> intuitive sense for a DATE-TIME event but less so for DATE events.  We
> should clean that up.
>
> Eliot
>
>

---

From: Michael Douglass <[email-masked]>
Date: Sun, 19 Apr 2020 21:42:37 -0400

> If this is the case, then how would you express the holiday “New Year’s Day” such that it applies to everyone in their respective wall clock times?

That's the only possibility with VALUE=DATE, it's a floating value - i.e 
no timezone so always interpreted locally.

And there's two ways (ignoring duration):

DTSTART;VALUE=DATE: 20210101

DTEND;VALUE=DATE:20210102

or just

DTSTART;VALUE=DATE: 20210101

Start is inclusive, end exclusive

>
> Eliot
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Sun, 19 Apr 2020 21:57:28 -0400

This text has been in place since 2445.

On 4/19/20 20:07, Barry Leiba wrote:
> On Sun, Apr 19, 2020 at 5:33 PM Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Barry,
>
>     Lars is correct that the text in that section does not support the
>     case where an event is 2 days long.  Is this a serious
>     interoperability problem?  In order for it to be so, a calendar
>     agent would have to improperly represent all anniversaries, and
>     that would be spotted pretty quickly against any other calendar agent.
>
>     This having been said, were we to open the document, I would
>     probably unbury text out of Section 3.6.1 (see Our Blissful
>     Anniversary) that talks about DATE DTENDs and copy that into
>     Section 3.8.2.2 and make it plainly normative.
>
>     The issue here is the use of the term "non-inclusive” makes
>     perfect intuitive sense for a DATE-TIME event but less so for DATE
>     events.  We should clean that up.
>
Why?

Makes perfect sense to me - as in the 1 day example.

As it stands it's all consistent. Doesn't mean people get it right but 
that's a different problem.

Going back to the original text:

> The
>        "DTSTART" property value).

The biggest problem as I see it is that it's a completely meaningless 
addition to the explanation. All it's trying to say is that a recurring 
event with VALUE=DATE can be more than one day long - which should come 
as no surprise to anybody. I suspect they dug their own hole by 
referring to them as anniversary events rather than all-day - then 
realisd people think of anniversaries as a single day thing.

I'd say:

1. The attempted explanation is wrong.

2. It's pointless.

So we could just remove it.

However - it's been around for 22 years and we've just noticed.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Apr 2020 14:06:26 +0200

Michael,

> On 20 Apr 2020, at 03:57, Michael Douglass <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> As it stands it's all consistent. Doesn't mean people get it right but that's a different problem.
> 
> 

Think about it in human language terms:

When we say that a meeting has a start time of 2:00pm and an end time of 3:00pm, people understand that they can schedule another event at 3:00pm.  But when we say that an event has a start date of January 1 and an end date of January 2, people don’t think automagically that the event will run from January 1 00:00:00 to January 2 00:00:00 minus one second.  And when you tell them that the event will be January 1, they understand it to mean just that.

I am not suggesting a normative behavior change, just better explanatory text when the document opens up again.

Eliot