RFC Errata
Found 5 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 (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: 6575
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Laurence Lundblade
Date Reported: 2021-05-06
Section 2.2.3 says:
Where a major type of 6 (Tag) is used, the type of the tagged item can be specified by appending it in parentheses.
It should say:
Where a major type of 6 (Tag) is used, the type of the tagged item can be specified by appending it in parentheses. Additionally, for major type 6 the value of the argument, not the additional info is what follows the dot.
Notes:
The text at the top of page 50 is correct. The examples in 2.2.3 are also correct.
Status: Held for Document Update (3)
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.
Errata ID: 6527
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-11
Held for Document Update by: Francesca Palombini
Date Held: 2021-04-23
Section B says:
text = %x22 *SCHAR %x22 SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC SESC = "\" (%x20-7E / %x80-10FFFD)
It should say:
SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\
%x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t
(%x75 hexchar) ) ; \u
hexchar = non-surrogate / (high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG
Notes:
As discussed during the CBOR interim 2021-04-21 and in the mailing list: https://mailarchive.ietf.org/arch/msg/cbor/ljHAiw-WhNqoIKAzkjZa4WIf56Q/
--
The ABNF used in [RFC8610] for the content of text string literals is rather permissive:
text = %x22 *SCHAR %x22
SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
SESC = "\" (%x20-7E / %x80-10FFFD)
This allows almost any non-C0 character to be escaped by a backslash, but critically misses out on the \uXXXX and \uHHHH\uLLLL forms that JSON allows to specify characters in hex. Both can be solved by updating the SESC production to:
SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\
%x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t
(%x75 hexchar) ) ; \u
hexchar = non-surrogate / (high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG
Now that SESC is more restrictively formulated, this also requires an update to the BCHAR production used in the ABNF syntax for byte string literals:
bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
bsqual = "h" / "b64"
The updated version explicit allows \', which is no longer allowed in the updated SESC:
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / "\'" / CRLF
Errata ID: 6543
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Bartell
Date Reported: 2021-04-13
Held for Document Update by: Francesca Palombini
Date Held: 2021-04-23
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:
As discussed during the CBOR interim 2021-04-21 and in the mailing list: https://mailarchive.ietf.org/arch/msg/cbor/ekFn8a4GbUQAk4nyhc-Il-ZRLZc/
--
The ABNF used in [RFC8610] for the content of byte string literals lumps together byte strings notated as text with byte strings notated in base16 (hex) or base64 (but see also updated BCHAR production above):
bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
Errata report 6543 proposes to handle the two cases in separate productions (where, with an updated SESC, BCHAR obviously needs to be updated as above):
bytes = %x27 *BCHAR %x27
/ bsqual %x27 *QCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS
This potentially causes a subtle change, which is hidden in the WS production:
WS = SP / NL
SP = %x20
NL = COMMENT / CRLF
COMMENT = ";" *PCHAR CRLF
PCHAR = %x20-7E / %x80-10FFFD
CRLF = %x0A / %x0D.0A
This allows any non-C0 character in a comment, so this fragment becomes possible:
foo = h'
43424F52 ; 'CBOR'
0A ; LF, but don't use CR!
'
The current text is not unambiguously saying whether the three apostrophes need to be escaped with a \ or not, as in:
foo = h'
43424F52 ; \'CBOR\'
0A ; LF, but don\'t use CR!
'
... which would be supported by the existing ABNF in [RFC8610].