Re: [Cbor] [Technical Errata Reported] RFC8610 (6527)

[Carsten Bormann <[e-mail]>]

Hi Francesca,

I must admit that I’m not really comfortable with the errata process.

This errata report points to a problem with the ABNF definition of CDDL that keeps it from upholding the promise in Section 3.1 (top of page 16).
(Note that the note in the same paragraph is also about ABNF, but about how CDDL is different from ABNF, not about details of using the JSON string form and describing that in ABNF.  This stuff is all so meta...)

So is an update necessary?  The problem does not break existing specifications, as far as I know.  I would expect that implementers of CDDL will want to do something similar to what I did for the cddlc tool; the conflict between ABNF spec and text needs to be resolved in some way and a search for a minimal way to do so will come up with a solution similar to mine.
It is less clear that this minimal way is what we actually want to limit ourselves to.
But we *could* apply this hot fix and think about better ways to handle literals later, in CDDL 2.0 — draft-bormann-cbor-cddl-freezer has a Section 3 about literal syntax.

On the other hand, a workaround for this gap will be available with .cat, which I think we will be moving forward even faster than the next CDDL version.  Having an errata report that is not just rejected but acknowledges the problem and possibly points to this workaround for now would be helpful to users.

Grüße, Carsten


> On 2021-04-13, at 15:29, Francesca Palombini <francesca.palombini=[e-mail]> wrote:
> 
> I agree with Barry in that this seems to require more thinking and broader review and consensus. Carsten, you seem to imply that this should instead be rejected, with the motivation that it would need a new document (updating 8610), is that right ?
> 
> (For everybody not familiar with the errata status definition: https://www.rfc-editor.org/errata-definitions/
> Hold for document update: “The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update.”
> Rejected: “The erratum [...] proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list.”)
> 
> Francesca
> 
> On 13/04/2021, 15:07, "Barry Leiba" <[e-mail]> wrote:
> 
>    Indeed, this one screams "Hold for Document Update" to me, as it's
>    something that rather more complex.  It's clear that this isn't just
>    an "oops" when we published, but, rather a (valid) rethinking that
>    needs broader review and consensus on the solution.
> 
>    Barry
> 
>    On Tue, Apr 13, 2021 at 8:13 AM Carsten Bormann <[e-mail]> wrote:
>> 
>> On 2021-04-11, at 18:51, Carsten Bormann <[e-mail]> wrote:
>>> 
>>> However, there is one omission in the ABNF: the \u syntax, which is somewhat complicated in JSON because it is followed either by 4 hex digits that are not in the range d800 to dfff or by 4 hex digits in the range d800 to dbff, another \u, and four more hex digits dc00 to dfff.
>>> Someone needs to sit down and write up the ABNF for that (or find some ABNF that already has done the work).
>> 
>> I was too lazy to find some ABNF so I wrote my own.
>> 
>> 76c76,84
>> < SESC = "\" (%x20-7E / %x80-10FFFD)
>> ---
>>> 
>>> SESC = "\" ( %x22 / %x2F / %x5C / %x62 / %x66 / %x6E / %x72 / %x74 /
>>>             (%x75 hexchar) )
>>> 
>>> hexchar = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
>>>           ("D"
>>>            (( %x30-37 2HEXDIG ) /
>>>             (("8"/"9"/"A"/"B") 2HEXDIG "\" %x75 "D"
>>>              ("C"/"D"/"E"/"F") 2HEXDIG )))
>> 79c87
>> < BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
>> ---
>>> BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / "\'" / CRLF
>> 
>> 
>> The second change is necessary as SESC is now narrowly restricted to the escape combinations that JSON allows in text strings, and \' is not among those.
>> 
>> You can play with this changed grammar in cddlc version 0.0.3 (`gem update` if needed).
>> 
>>> I’m not sure this update should all be put into an errata item; maybe we should pursue writing this up in a document that updates RFC 8610 that could then also add a less unwieldy syntax for non-BMP code points such as the ubiquitous \u{…}.
>> 
>> I’m still not entirely sure we want to handle this as a bog-standard errata item.
>> Opinions welcome.
>> 
>> Grüße, Carsten
>> 
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor