Updates to the Concise Data Definition Language (CDDL) Grammar
updates
- rfc-8610 — Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
Extracted elements (21)
Empty CDDL files are allowed to support the upcoming CDDL modules feature, where a file may consist entirely of directives that resolve to rules only after processing. The at-least-one-rule constraint becomes a semantic check post-directives rather than a syntactic requirement.
Non-literal tag numbers use angle bracket syntax '<' type '>' reusing the generics syntax, which is disambiguated by context: generic parameters follow a rule name (id), while head-number expressions follow a dot character. The document notes this angle bracket reuse may cause human confusion but avoids the disruption of a new character.
Non-printable characters (U+007F–U+009F) and surrogates were excluded from SCHAR, BCHAR, and PCHAR for consistency, but the document deliberately stops short of excluding all non-printable Unicode characters to avoid importing complexity from the ongoing evolution of the Unicode standard.
The non-literal tag number extension was motivated by RFC 9277, which requires a range of tag numbers (0x63740101–0x6374FFFF) that cannot be expressed with RFC 8610's literal-only syntax. The ct-tag example demonstrates expressing such a range via a CDDL type reference.
The \u{hex} brace escape form was added as a backward-compatible extension (existing CDDL files remain valid) but is not forward compatible: CDDL files using this syntax may not be processable by implementations not yet updated to RFC 9682, which is why updating implementations is recommended.
Erratum ID 6278 reports an inconsistency between SCHAR and BCHAR: U+007F (DEL) was excluded from SCHAR but not from BCHAR. This document extends the exclusion to U+007F–U+009F (all C1 control characters) in BCHAR and also in PCHAR (comment characters).
Erratum ID 6526 reports that backslashes were lost during RFC publication in Appendix G.2 of RFC 8610, garbling the text explaining backslash escaping. The updated grammar in this document addresses this by clarifying the SESC rule.
Erratum ID 6527 reports that the original SESC rule in RFC 8610 was too permissive (allowing nearly any non-C0 character after a backslash) and critically omitted the \uXXXX and \uHHHH\uLLLL hex escape forms that CDDL imports from JSON per Section 3.1 item 6 of RFC 8610.
Erratum ID 6543 proposed splitting qualified byte string literals (h'...' and b64'...') from plain UTF-8 byte string literals into separate ABNF rules. This document instead uses a simpler semantic post-processing approach, leaving bsqual handling to a step after syntactic parsing of BCHAR.
Grammar changes in Section 2 (string literal updates) are not forward compatible: CDDL specifications using new hex escape syntax (e.g., \u{hex}) will not be processable by implementations based solely on RFC 8610 until those implementations are updated. Implementors are recommended to update promptly.
Grammar changes in Section 3 (empty models, non-literal tag numbers) are backward compatible — RFC 8610-compliant CDDL files continue to match the updated grammar — but not forward compatible, meaning new constructs require updated implementations to process.
The hexchar rule defines valid arguments to the \u escape: a braced form '{' (1*'0' [hexscalar] / hexscalar) '}', a non-surrogate four-hex-digit form, or a high-surrogate / '\u' / low-surrogate surrogate pair sequence. The hexscalar rule covers all valid Unicode scalar values up to U+10FFFF.
The PCHAR rule (for comment content) is updated to %x20-7E / NONASCII, consistently excluding U+007F and C1 control characters and surrogates from comments, mirroring the treatment in SCHAR and BCHAR.
The top-level cddl grammar rule is relaxed from 'S 1*(rule S)' to 'S *(rule S)', allowing CDDL files with zero rules. The requirement for at least one rule is demoted to a semantic constraint satisfied after all directives are processed, enabling CDDL module files that contain only directives.
The type2 rule is extended with a head-number production (uint / '<' type '>') for tag numbers (#6) and simple values (#7), replacing the prior literal-only uint. This allows tag number ranges and type-parameterized tag/simple-value specifications in CDDL.
The updated BCHAR rule (for byte string literal content) adds explicit inclusion of \' (since the tightened SESC no longer allows it implicitly) and excludes U+007F–U+009F and surrogates, matching SCHAR's exclusions. BCHAR = %x20-26 / %x28-5B / %x5D-7E / NONASCII / SESC / "\'"/CRLF.
The updated SCHAR rule (for text string content) is defined as %x20-21 / %x23-5B / %x5D-7E / NONASCII / SESC, where NONASCII = %xA0-D7FF / %xE000-10FFFD. This excludes C0, DEL (U+007F), C1 controls (U+0080–U+009F), and surrogate code points from unescaped string content.
The updated SESC rule defines valid backslash escape sequences in CDDL string literals: \" \/ \\ \b \f \n \r \t, followed by \uXXXX in three forms: the new \u{hex} brace form (direct Unicode scalar), the four-hex-digit form, and the JSON surrogate-pair form \uHHHH\uLLLL for code points beyond U+FFFF.
During the transition period, environments using a mix of updated and non-updated CDDL tools face an elevated risk of confusion. Attackers may craft CDDL models interpreted differently by different parts of a system, exploiting implementation divergence. Implementations must ascertain provenance, authenticity, and integrity of CDDL models, treating them with the same care as source code.
CDDL byte string literals use the form [bsqual] %x27 *BCHAR %x27 (single-quoted, optionally preceded by 'h' or 'b64'). The updated BCHAR rule explicitly includes \' and excludes U+007F–U+009F and surrogates. Qualified (h/b64) content is processed semantically after syntactic BCHAR parsing.
CDDL text string literals use the form %x22 *SCHAR %x22 (double-quoted). Valid content is defined by the updated SCHAR rule, and escape sequences by the updated SESC rule including the new \u{hex} brace form alongside the JSON-compatible \uXXXX and surrogate-pair forms.