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

From: RFC Errata System <[email-masked]>
Date: Tue, 26 Nov 2019 12:50:20 -0800 (PST)

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

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

Section: 3.8.5.3

Original Text
-------------
Every Friday the 13th, forever:

       DTSTART;TZID=America/New_York:19970902T090000
       EXDATE;TZID=America/New_York:19970902T090000
       RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

       ==> (1998 9:00 AM EST) February 13;March 13;November 13
           (1999 9:00 AM EDT) August 13
           (2000 9:00 AM EDT) October 13
           ...

Corrected Text
--------------
Every Friday the 13th, forever:

       DTSTART;TZID=America/New_York:19980213T090000
       RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

       ==> (1998 9:00 AM EST) February 13;March 13;November 13
           (1999 9:00 AM EDT) August 13
           (2000 9:00 AM EDT) October 13
           ...

Notes
-----
The "DTSTART" property is not synchronized with the recurrence rule.

Although it may be removed from the recurrence set by an "EXDATE" property, the description at the start of section 3.8.5.3 leaves no doubt that the "DTSTART" property should still be synchronized with the recurrence rule.

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: Doug Royer <[email-masked]>
Date: Tue, 26 Nov 2019 14:40:37 -0700

> Original Text

Did (do?) some implementations not do this? Why is it a "SHOULD" and not a "MUST"?

And 2445 said the same (and had the same example error):

   2445: The "DTSTART" property defines the first instance in the recurrence set.

5545 Current text (in 3.8.5.3):

The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified.
The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined.

Change To?

The "DTSTART" property value MUST be synchronized with first instance of the recurrence rule, if specified

And update Appendix A: "A.1".

-- 
Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 27 Nov 2019 11:50:18 +1100

On Wed, 27 Nov 2019, at 08:40, Doug Royer wrote:
> Did (do?) some implementations not do this?

Definitely; in my testing in the past I think most clients could be made to generate an RRULE that doesn't match the start date. That's why in JSCalendar we dropped the requirement and defined how to interpret it regardless (I still think your UI will be clearer if you make them align, but that's another matter).

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Wed, 27 Nov 2019 01:01:44 -0500

On 11/26/19 19:50, Neil Jenkins wrote:
> Definitely; in my testing in the past I think most clients could be 
> made to generate an RRULE that doesn't match the start date. That's 
> why in JSCalendar we dropped the requirement and defined how to 
> interpret it regardless (I still think your UI will be clearer if you 
> make them align, but that's another matter).

 From the human perspective I'm not sure.

I suspect the general way of thinking is along the lines of

"I want a meeting every thursday at 14:00 starting next week."

Why should the UI force a user into figuring out the date and time of 
the first instance? What if DST starts that weekend?

Data models should be very encompassing and unambiguous. UIs are the 
translation between the messy human perceptions and the exact world we 
developers live in.

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Nov 2019 11:25:59 +0100

I propose accepting this erratum.  While it is true that the recurrence set would remain unchanged, the text in RFC 5545 is very clear:

> The "DTSTART" property defines
> the first instance in the recurrence set.  The "DTSTART" property
> value SHOULD be synchronized with the recurrence rule, if
> specified.  The recurrence set generated with a "DTSTART" property
> value not synchronized with the recurrence rule is undefined.

Here that wasn’t the case, and there was no good reason for it not to be the case; and in fact the example leads us right into that undefined state.

Eliot

> On 26 Nov 2019, at 21:50, RFC Errata System <[email-masked]> wrote:
>

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 27 Nov 2019 06:58:43 -0500

+1

Bernard

> Le 27 nov. 2019 à 05:26, Eliot Lear <[email-masked]> a écrit :
>

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Nov 2019 07:27:24 -0700

On 11/26/19 11:01 PM, Michael Douglass [Masked] wrote:
> Preview: On 11/26/19 19:50, Neil Jenkins wrote: > On Wed, 27 Nov 2019, --> SPAM? CLICK to BLOCK <https://dnt.abine.com/#/block_email/[email-masked]/[email-masked]>
> 
> This email is Masked using Blur - it was sent from ietf.org to [email-masked] (your reply stays Masked). To protect your privacy <https://www.abine.com/faq.html#caniaddcc>, do not forward this message, or add new recipients like CCs or BCCs.
> 
> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe at a discount. <https://joindeleteme.com/?utm_campaign=blur-offer&utm_source=masked-email-header> ]
> 
> 
> Why should the UI force a user into figuring out the date and time of the first instance? What if DST starts that weekend?
> 
> Data models should be very encompassing and unambiguous. UIs are the translation between the messy human perceptions and the exact world we developers live in.

Let the UI figure it out. The user just picks the pattern. The DTSTAMP would be set to the current date.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Nov 2019 19:23:43 +0100

Lars,

First thanks for reporting this erratum.  Now please see below.

> On 27 Nov 2019, at 18:02, Lars Henriksen <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thank you. It confirms my reading of the document, but leaves me in the dark as
> to why. Is there a good reason why the "DTSTART" property should match the
> recurrence rule? As the text stands, the instance is included in the recurrence
> set twice: by the "DTSTART" property and by the "RRULE" property. Doesn't the
> first suffice?

I may be misinterpreting your question, but DTSTART is needed by RRULE because if you have an event that occurs weekly on Fridays at 3:00pm, only DTSTART will provide the time.  And so the DTSTART is needed for that reason.  To me, at least, it causes cognitive dissidence (if not an actual interoperability problem) to say that an event should start on a Thursday when the RRULE does not permit that date.  Section 3.8.5.3 also explicitly states:

      The "DTSTART" property specified within the iCalendar object
      defines the first instance of the recurrence.

And so no matter what we may say now, I would never want an implementation to violate this statement, which means your erratum is quite important.

Eliot

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Nov 2019 11:48:53 -0700

On 11/27/19 3:25 AM, Eliot Lear wrote:
> I propose *accepting* this erratum.  While it is true that the recurrence set would remain unchanged, the text in RFC 5545 is very clear:

And the SHOULD (below in 5545) needs to be replaced with MUST. Otherwise, it is still a valid object?