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

From: RFC Errata System <[email-masked]>
Date: Thu, 22 Oct 2020 11:28:44 -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/eid6316

--------------------------------------
Type: Technical
Reported by: Ken Murchison <[email-masked]>

Section: 3.8.5.1

Original Text
-------------
    Value Type:  The default value type for this property is DATE-TIME.
       The value type can be set to DATE.

Corrected Text
--------------
    Value Type:  The default value type for this property is DATE-TIME.
       The value type can be set to DATE.  This property MUST have the same
       value type as the "DTSTART" property contained within the
       recurring component.  Furthermore, this property MUST be specified
       as a date with local time if and only if the "DTSTART" property
       contained within the recurring component is specified as a date
       with local time.

Notes
-----
EXDATE excludes a specific instance of a recurring event and therefore should have the same value type as DTSTART.  This is analogous to RECURRENCE-ID which overrides a specific instance and has the same value type as DTSTART.

I will note however that there is iCalendar data in the wild with DTSTART;VALUE=DATE-TIME and EXDATE;VALUE=DATE.  If this errata is rejected as incorrect, then a new errata should be opened with additional text describing how EXDATE;VALUE=DATE is supposed to be handled when DTSTART;VALUE=DATE-TIME.  For instance, does EXDATE;VALUE=DATE exclude ALL instances of a FREQ=HOURLY recurrence on the given day?

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: Eliot Lear <[email-masked]>
Date: Thu, 22 Oct 2020 21:17:59 +0200

Hi Ken,

Thanks for your erratum.

> On 22 Oct 2020, at 20:28, RFC Errata System <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://www.rfc-editor.org/errata/eid6316 <https://www.rfc-editor.org/errata/eid6316>
> 

First, let’s agree that the text is underspecified.  There are three potential situations:

EXDATE matches DTSTART.  No problem.  Move along.
EXDATE is a DATE-TIME and DTSTART is a DATE.  I can’t imagine anyone having coded this, but perhaps my imagination isn’t good.
EXDATE is a DATE and DTSTART is a DATE-TIME.  This is only a problem if the RRULE has a FREQ < DAILY (MINUTELY, HOURLY, SECONDLY).

Several questions:

What happens with implementations today?  Do we know?  If everyone does one thing, then we should probably note that in the errata, and perhaps think of holding for update.  Your interpretation seems to make sense, but I don’t know what’s in the code.
If there are different behaviors, then we have to decide which one is correct.

Does CalConnect have a view on this?

Eliot

---

From: Ken Murchison <[email-masked]>
Date: Thu, 22 Oct 2020 15:40:29 -0400

Hi Eliot,

On 10/22/20 3:17 PM, Eliot Lear wrote:
> Hi Ken,
>
> Thanks for your erratum.
>
>> On 22 Oct 2020, at 20:28, RFC Errata System 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> <https://www.rfc-editor.org/errata/eid6316>
>>
>> Reported by: Ken Murchison <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> Section: 3.8.5.1
>>
>> Original Text
>> -------------
>> EXDATE excludes a specific instance of a recurring event and 
>> therefore should have the same value type as DTSTART.  This is 
>> analogous to RECURRENCE-ID which overrides a specific instance and 
>> has the same value type as DTSTART.
>>
>> I will note however that there is iCalendar data in the wild with 
>> DTSTART;VALUE=DATE-TIME and EXDATE;VALUE=DATE.  If this errata is 
>> rejected as incorrect, then a new errata should be opened with 
>> additional text describing how EXDATE;VALUE=DATE is supposed to be 
>> handled when DTSTART;VALUE=DATE-TIME.  For instance, does 
>> EXDATE;VALUE=DATE exclude ALL instances of a FREQ=HOURLY recurrence 
>> on the given day?
>
>
>   * EXDATE matches DTSTART.  No problem.  Move along.
>

Agreed.

>   * EXDATE is a DATE-TIME and DTSTART is a DATE.  I can’t imagine
>     anyone having coded this, but perhaps my imagination isn’t good.
>

Agree, this would be weird.

>   * EXDATE is a DATE and DTSTART is a DATE-TIME.  This is only a
>     problem if the RRULE has a FREQ < DAILY (MINUTELY, HOURLY, SECONDLY).
>

No, its also an issue with other frequencies as well.  iCalendar data in 
the wild are using EXDATE as DATE to exclude DAILY and WEEKLY DATE-TIME 
occurrences, as we had a user trying to import such data.  I presume the 
same might be true for YEARLY and MONTHLY as well.

>
> Several questions:
>
>   * What happens with implementations today?  Do we know?  If everyone
>     does one thing, then we should probably note that in the errata,
>     and perhaps think of holding for update.  Your interpretation
>     seems to make sense, but I don’t know what’s in the code.
>

I know for a fact that the code that I work on (libical and Cyrus) 
basically ignores the EXDATE if they don't match DTSTART (I haven't 
looked into which bit of software is responsible yet).

>   * If there are different behaviors, then we have to decide which one
>     is correct.
>
>

I'll let folks reply themselves, but I posed this question to the 
caldeveloper <[email-masked]> list and two 
non-Fastmail CalConnect members stated that they also felt that EXDATE 
should match DTSTART.

My guess is that there is enough of this going on that we need to see 
what the big boys are doing, conform and document accordingly.

Either way, I'm curious what the intent of the original text was.  I 
wasn't involved with calendaring during the initial spec and the update.

-- 

Kenneth Murchison
Senior Software Developer
Fastmail US LLC