Subject: Re: [Jcardcal] [Technical Errata Reported] RFC7265 (6360)

From: Barry Leiba <[email-masked]>
Date: Thu, 24 Dec 2020 13:39:34 -0500

I believe this is incorrect, in that...

      VERSION:2.0\;2.9

...*is* the only correct way to represent that option in iCalendar.
It doesn't help, I guess, that there's no example of a VERSION
property that looks like that, but see RFC 5545 Section ??, which says
this:

      A SEMICOLON character in a "TEXT" property value MUST
      be escaped with a BACKSLASH character.

...and Section 3.8.8.3, which gives this example for REQUEST-STATUS:

       REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
        as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2

Does anyone think this analysis is incorrect?

Barry, ART AD

On Mon, Dec 21, 2020 at 12:40 AM RFC Errata System
<[email-masked]> wrote:
>
> The following errata report has been submitted for RFC7265,
> "jCal: The JSON Format for iCalendar".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6360
>
> --------------------------------------
> Type: Technical
> Reported by: Julian Cowley <[email-masked]>
>
> Section: GLOBAL
>
> Original Text
> -------------
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> In RFC 5545, one of the allowable values for the VERSION property is a minimum version and a maximum version, separated by a semicolon (;).  The value type is TEXT.  When the jCal value is converted back to iCalendar, the text is subject to escape with a backslash.  This yields a result which is not valid for the VERSION property.
>
> Example:
>
> [ "version", {}, "text", "2.0;2.9" ]
>
> becomes
>
> VERSION:2.0\;2.9
>
> which is invalid because it contains the backslash.
>
> 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.
>
> --------------------------------------
> RFC7265 (draft-ietf-jcardcal-jcal-10)
> --------------------------------------
> Title               : jCal: The JSON Format for iCalendar
> Publication Date    : May 2014
> Author(s)           : P. Kewisch, C. Daboo, M. Douglass
> Category            : PROPOSED STANDARD
> Source              : JSON data formats for vCard and iCalendar
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 Dec 2020 13:40:53 -0500

VERSION:2.0\;2.9

...*is* the only correct way to represent that option in iCalendar.
It doesn't help, I guess, that there's no example of a VERSION
property that looks like that, but see RFC 5545 Section 3.3.11, which says
this:

Barry, ART AD

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Dec 2020 16:20:55 -0500

Hi Barry,

> Does anyone think this analysis is incorrect?

It is incorrect.

First off, note that in 5545 §3.3.11:

      The "TEXT" property values may also contain special characters
      that are used to signify delimiters, such as a COMMA character for
      lists of values or a SEMICOLON character for structured values.

The key thing here is that there are "structured" values that use COMMA and 
SEMICOLON as delimiters of TEXT values, and thus each individual TEXT value 
needs to have their own COMMAs and SEMICOLONs escaped.

Next, note that 5545 §3.7.4 defines the VERSION property value as:

    vervalue   = "2.0"         ;This memo
                      / maxver
                      / (minver ";" maxver)

           minver     = <A IANA-registered iCalendar version identifier>
           ;Minimum iCalendar version needed to parse the iCalendar object.

           maxver     = <A IANA-registered iCalendar version identifier>
           ;Maximum iCalendar version needed to parse the iCalendar object.

i.e., the property value is effectively: text *(";" text). 

I think one key problem is the value type definitions of properties like 
this:

    Value Type:  TEXT

That gives the impression that the value should follow the 'text' rule, but 
in fact the format definition has to be used for the actual syntax of the 
value. This could be clearer for such structured values. In fact, the GEO 
property is a good example:

    Value Type:  FLOAT.  The value MUST be two SEMICOLON-separated FLOAT
          values.

If 5545 were ever to be revised, I would suggest fixing the "Value Type" 
descriptions for all the "structured" types.

In any case, as far as the report goes: yes there is a bug in 7265. It 
should have called out VERSION as a special case in §3.4.1, as it did for 
GEO and REQUEST-STATUS. Perhaps it should have been defined it as either a 
single JSON string, or a list of strings. In practice, there is only one 
version value defined for iCalendar today, and I suspect that will likely be 
true for ever more. Plus 7265 should probably be consider historic in light 
of jcal.

-- 
Cyrus Daboo

---

From: RFC Errata System <[email-masked]>
Date: Sun, 20 Dec 2020 21:40:19 -0800 (PST)

Section: GLOBAL

Original Text
-------------

Corrected Text
--------------

Notes
-----

Example:

becomes

VERSION:2.0\;2.9

Instructions:
-------------