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

[Cyrus Daboo <[e-mail]>]

Hi Barry,

--On Thu, 24 Dec 2020 13:40:53 -0500 Barry Leiba <[e-mail]> 
wrote:

> I believe this is incorrect, in that...
>
>       VERSION:2.0\;2.9
>
> ...*is* the only correct way to represent that option in iCalendar.

> 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