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

From: RFC Errata System <[email-masked]>
Date: Thu, 12 Feb 2015 23:10:57 -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:
http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4271

--------------------------------------
Type: Technical
Reported by: Neil Jenkins <[email-masked]>

Section: 3.3.10

Original Text
-------------
Recurrence rules may generate recurrence instances with an invalid
date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
on a day where the local time is moved forward by an hour at 1:00
AM).  Such recurrence instances MUST be ignored and MUST NOT be
counted as part of the recurrence set.

Corrected Text
--------------
Recurrence rules may generate recurrence instances with an invalid
date (e.g., February 30). Such recurrence instances MUST be ignored
and MUST NOT be counted as part of the recurrence set.

Notes
-----
The section about ignoring times that don't occur in the timezone of the expansion is contradicted by the later passage (p44):

"""If the computed local start time of a recurrence instance does not
exist, or occurs more than once, for the specified time zone, the
time of the recurrence instance is interpreted in the same manner
as an explicit DATE-TIME value describing that date and time, as
specified in Section 3.3.5."""

And this is the behaviour implemented by major clients such as Calendar.app and Google Calendar.

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 (IESG)
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: Barry Leiba <[email-masked]>
Date: Fri, 13 Feb 2015 15:00:13 -0500

This change and explanation does seem right to me.  I think this text
is there from before we had the 45-minute discussion in some calsify
meeting or other about how to handle non-existant-time situations...
and this text never got removed.

Those who might remember more clearly than I do: is that correct?

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 13 Feb 2015 15:09:50 -0500

Hi Barry,

> Those who might remember more clearly than I do: is that correct?

I think that is correct - a non-existent or doubled-up time value should 
not cause a recurrence instance to be discarded during rule processing.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Feb 2015 19:01:38 +0100

Hi,

Something is wrong with this erratum.  It could be that there is really
a problem with the existing text, but what is proposed simply takes out
a quite valid example.  Bernard, can you take a look and see if you spot
a bug?

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Tue, 17 Feb 2015 14:14:51 -0500

> a quite valid example.  Bernard, can you take a look and see if you spot

I've talked with Eliot, who is now sitting next to me, and I've edited
the errata report by adding a second paragraph to the corrected text.
The second paragraph restores the "nonexistent time" statement and
example, and says that it's handled according to Section 3.3.5.

Eliot, others, please take a look and see if you think that's good, or
whether there's something else that needs to be tweaked (that falls
under the errata criteria).  Or, if necessary, tell me that the fix is
more complicated (I don't think it is), and needs to be held for
document update.

Barry

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Feb 2015 11:19:42 -0800

Barry,

I think your proposed change is good.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 17 Feb 2015 15:23:37 -0500

Hi Eliot,

> I think your proposed change is good.

+1

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 17 Feb 2015 16:18:09 -0500

>> I think your proposed change is good.

Off to mark it "Verified" now...

b