RFC Errata
Found 4 records.
Status: Verified (1)
RFC 8610, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", June 2019
Source of RFC: cbor (art)
Errata ID: 6526
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-11
Verifier Name: Francesca Palombini
Date Verified: 2021-04-12
Section G.2 says:
The escaping rules of JSON strings are applied equivalently for text-based byte strings, e.g., "\" stands for a single backslash and "'" stands for a single quote. Whitespace is included literally, i.e., the previous section does not apply to text-based byte strings.
It should say:
The escaping rules of JSON strings are applied equivalently for text-based byte strings, e.g., "\\" stands for a single backslash and "\'" stands for a single quote. Whitespace is included literally, i.e., the previous section does not apply to text-based byte strings.
Notes:
"\" and "'" need a backslash to escape them.
Status: Reported (2)
RFC 8610, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", June 2019
Source of RFC: cbor (art)
Errata ID: 6527
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-11
Section B says:
SESC = "\" (%x20-7E / %x80-10FFFD)
It should say:
SESC = "\" (%x22 / %x27 / %x2F / %x5C / %x62 / %x66 / %x6E / %x72 / %x74 / %x75 4HEXDIG )
Notes:
The ABNF rule for string escape codes should specify which escape codes are allowed, and also specify that "\u" must be followed by four hex digits. My suggested correction is based on JSON, but with the addition of "\'" (single quote) for use in text-based byte strings (section G.2). (Presumably, characters outside the BMP must be escaped using a surrogate pair, as in JSON.)
Errata ID: 6543
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-13
Section B says:
bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
It should say:
bytes = %x27 *BCHAR %x27
/ bsqual %x27 *QCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS
Notes:
Section 3.1 states that comments are allowed in prefixed byte strings. This correction explicitly uses WS (which includes comments) in the rule for prefixed byte strings. Although the original ABNF would allow *most* comments, it would prohibit comments including a single quote, or comments with a backslash at the end of the line.
My correction allows prefixed byte strings to use every hex and base64 character. Alternatively, the ABNF could be narrowed down using separate rules for hex and base64, or it could be broadened to allow other characters. The ultimate effect would be the same regardless.
Note that both the original and corrected ABNF allow CRLF in unprefixed bytestrings.
(Note: Unlike my previous two errata, which affected unprefixed byte strings, this one affects prefixed byte strings.)
Status: Held for Document Update (1)
RFC 8610, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", June 2019
Source of RFC: cbor (art)
Errata ID: 6278
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Seppanen
Date Reported: 2020-09-04
Held for Document Update by: Barry Leiba
Date Held: 2020-09-04
Section Appendix B says:
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
It should say:
BCHAR = %x20-26 / %x28-5B / %x5D-7E / %x80-10FFFD / SESC / CRLF
Notes:
Between draft 6 and 7 of the RFC, the ASCII DELETE character 0x7F was excluded from the character set allowed in text literals. I believe it should also be excluded from the character set of bytestring literals.
A 0x7F byte could not be decoded if included in a hex or base64 bytestring, leaving only UTF-8 bytestrings. Since there is no discussion in the text of any reason to allow this character in a UTF-8 bytestring when it was not allowed in a UTF-8 text string, I suspect this was an oversight.
===== Verifier notes =====
It was, indeed, an oversight, but discussion on the CBOR working group list shows that the proper fix is not straightforward, and that it should be handled in the next version of the spec.