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

[Sean Bartell <[e-mail]>]

> >    On Tue, Apr 13, 2021 at 8:13 AM Carsten Bormann <[e-mail]> wrote:
> >> 
> >> 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.
> >> 

This ABNF looks correct to me, but it obfuscates more than it clarifies. I would suggest following the example of the JSON RFC (https://www.rfc-editor.org/rfc/rfc8259.html#section-7). The ABNF there allows arbitrary hex digits (%x75 4HEXDIG), but the text clarifies how non-BMP characters are handled. A similar situation already exists for base64 bytestrings, for which CDDL's ABNF allows invalid base64.

It's also not clear to me whether \' should be allowed in text strings, or whether \" should be allowed in byte strings. Allowing them would make both types of strings consistent with each other, but prohibiting them would let text strings use the exact same syntax as JSON. And one more issue: the ABNF currently allows CRLF in unprefixed byte strings, and I'm not sure whether that's intentional.

> > 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://urldefense.com/v3/__https://www.rfc-editor.org/errata-definitions/__;!!DZ3fjg!soSEF4XBhOUPRdN5wSzvAeVKOyu_4HkZe_d06IEV4huYgnyqgimjYJH9OeHL0LITxA8$ 
> > 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.”)

More guidance on the errata process (https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/): "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update."

As I interpret it, if this is a "small change", and there was no clear "intended consensus" about which escape codes should be allowed, the erratum can be marked as "Hold for Document Update".

FWIW, I'm not actually using CDDL at the moment. I'm using the extended diagnostic notation, and I was using the CDDL ABNF to narrow down my choice of syntax.

Sean