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

From: RFC Errata System <[email-masked]>
Date: Wed, 26 Sep 2018 02:09:58 -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:
http://www.rfc-editor.org/errata/eid5505

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

Section: 3.2.19

Original Text
-------------
       tzidparam  = "TZID" "=" [tzidprefix] paramtext

Corrected Text
--------------
       tzidparam  = "TZID" "=" [tzidprefix] param-value

Notes
-----
TZID appears to be the only parameter defined 5545 whose value can not be a quoted string.  This is problematic in that time zone IDs such as "GMT-03:00" are beginning to appear (note the embedded colon).  RFC 6868 has no mechanism to quote a colon character, as it relies on such characters appearing within a quoted string.  I see no technical reason why a TZID parameter can not be quoted, and existing implementations already accept quoted TZIDs.

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: Wed, 26 Sep 2018 11:16:09 +0200

While I agree with Ken in principle, I'm a little nervous about the
backward compatibility implications here, if parsers are now not
expecting quoted text.

---

From: Michael Douglass <[email-masked]>
Date: Wed, 26 Sep 2018 13:00:02 +0200

> backward compatibility implications here, if parsers are now not
My belief is that parsers are already expecting this. Certainly ical4j 
and libical already accept quoted values.

In any case it's broken as it stands. Parameter escaping isn't an option 
as it assumes parameter value quoting is an option.
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Sep 2018 13:01:16 +0200

Would it make sense for folks at Calconnect to chime in on this?

On 26.09.18 13:00, Michael Douglass wrote:
> In any case it's broken as it stands. Parameter escaping isn't an
> option as it assumes parameter value quoting is an option.

---

From: Keith Harris <[email-masked]>
Date: Wed, 26 Sep 2018 13:34:31 +0200

Actually, this topic is one that came up as part of a conversation this
morning at the CalConnect confernce here in Germany this week.

I had been asking the group for help about how to solve a problem (parsing
the line DTSTART;TZID=GMT-03:00:20180822T075501 from a partner
organisation). We had a small group discussion and Ken and Mike were
advising me to tell our partner to quote the timezone when they spotted the
issue.

Thanks,

Keith Harris
https://youcanbook.me

On Wed, 26 Sep 2018 at 13:01, Eliot Lear <[email-masked]> wrote:

> My belief is that parsers are already expecting this. Certainly ical4j and
> libical already accept quoted values.
>
> You may review the report below and at:http://www.rfc-editor.org/errata/eid5505
>
> Reported by: Ken Murchison <[email-masked]> <[email-masked]>
>
> Section: 3.2.19
>
> Original Text
> -------------
> calsify mailing [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
>
>
>
> calsify mailing [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
>

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 26 Sep 2018 10:27:33 -0400

Hi Michael,

> as it assumes parameter value quoting is an option.

I agree this should be fixed, but the proposed change in the erratum is 
wrong. This was the proposed new definition:

That does not work because it would allow the optional tzidprefix (which is 
a single "/" character) to appear before the first quote of any quoted 
string. I think you really need:

tzidparam  = "TZID" "=" ([tzidprefix] paramtext) /
                        (DQUOTE [tzidprefix] *QSAFE-CHAR DQUOTE)

That ensures the tzidprefix appears inside the quoted string, if that 
construct is used.

That said, I don't think I have ever seen tzidprefix being used. It was 
meant to be used to indicate the the ID was from a globally defined 
registry - well we have that now (IANA tzdb) and we aren't using the 
prefix. I would suggest any future revision of 5545 should drop tzidprefix 
as a formal syntax element, and instead just mention that the tzid value 
may be prefixed.

FYI I checked my 5545 code and all implementations parse and generate 
paramaters based on the generic definition of a parameter:

     param         = param-name "=" param-value *("," param-value)

So a quoted TZID would be fine.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Wed, 26 Sep 2018 10:33:14 -0400

On 9/26/18 10:27 AM, Cyrus Daboo wrote:
> I agree this should be fixed, but the proposed change in the erratum 
> is wrong. This was the proposed new definition:
>
> That does not work because it would allow the optional tzidprefix 
> (which is a single "/" character) to appear before the first quote of 
> any quoted string. I think you really need:
>

Correct.  I was careless in not considering the prefix when I posted the 
errata.  Can the errata be augmented as suggested by Cyrus, or does it 
need to be rejected and a new errata submitted?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 27 Sep 2018 11:09:02 -0400

Hi Cyrus,

Should TZID allow quoted values?  One could easily answer: Why not!   In 2018, though I’m more tempted to ask: Why?

As you rightly mentioned, we now have the IANA Time Zone Database.

Why would someone want / need to specify   TZID=GMT-03:00  instead of  TZID=Etc/GMT-3?

Perhaps this iCalendar inconsistency is actually a good thing for interoperability!

Finally, for the record only, not that it matters, Mozilla.org did use the tzprefix at some point.  See:

	https://www.google.ca/search?q=TZID=/mozilla.org

Cheers,
Bernard

> Le 26 sept. 2018 à 10:27, Cyrus Daboo <[email-masked]> a écrit :
> 
> Hi Michael,
> 
> --On September 26, 2018 at 1:00:02 PM +0200 Michael Douglass <[email-masked]> wrote:
> 
> I agree this should be fixed, but the proposed change in the erratum is wrong. This was the proposed new definition:
> 
> That does not work because it would allow the optional tzidprefix (which is a single "/" character) to appear before the first quote of any quoted string. I think you really need:
> 
> That ensures the tzidprefix appears inside the quoted string, if that construct is used.
> 
> That said, I don't think I have ever seen tzidprefix being used. It was meant to be used to indicate the the ID was from a globally defined registry - well we have that now (IANA tzdb) and we aren't using the prefix. I would suggest any future revision of 5545 should drop tzidprefix as a formal syntax element, and instead just mention that the tzid value may be prefixed.
> 
> FYI I checked my 5545 code and all implementations parse and generate paramaters based on the generic definition of a parameter:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_calsify&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=1KWjrk6WfltMq-xNvZw71GcUXlVStaOFvtc__OOO9f8&m=BvqZ3mUPlLxPK4dmzAOgTYiPUSywS7v8KV8Ybm3XBbI&s=6mggIoTabdhZqrS4rxdSdbK9RHlUdSEx7oHg6CNppKE&e=

---

From: Steve Allen <[email-masked]>
Date: Thu, 27 Sep 2018 09:29:23 -0700

> Why would someone want / need to specify   TZID=GMT-03:00  instead of  TZID=Etc/GMT-3?

I would specify TZID=GMT-20:00 and TZID=GMT-23:00, and those are
not found in IANA Time Zone database.

For practical purposes, the first is the time zone in which the
astronomical calendar for Lick Observatory has always been expressed.
The astronomical day begins at noon local time.  The lack of
availability of those means that modern computing systems do not
recognize the traditional day boundaries, so the calendars are
presented with footnotes to be interpreted by humans.

The second is the time zone in which the calendar for Keck Observatory
is expressed.

> Perhaps this iCalendar inconsistency is actually a good thing for interoperability!

It is a bad thing for situations which are not common enough to be
accommodated by the widely-used interfaces.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m

---

From: Keith Harris <[email-masked]>
Date: Fri, 28 Sep 2018 12:16:39 +0100

Perhaps TZID=GMT-03:30 is another example of a offset defined zone that can
not neatly be done without a colon.

(Though I agree that there could be a signal here regarding
interoperability, but for me it would be to steer away offset zones and
towards geographic names: TZID=America/St_Johns)
<https://youcanbook.me>