CINXE.COM

RFC 9682: Updates to the Concise Data Definition Language (CDDL) Grammar

<!DOCTYPE html> <html lang="en" class="RFC"> <head> <meta charset="utf-8"> <meta content="Common,Latin" name="scripts"> <meta content="initial-scale=1.0" name="viewport"> <title>RFC 9682: Updates to the Concise Data Definition Language (CDDL) Grammar</title> <meta content="Carsten Bormann" name="author"> <meta content=" The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON. This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. " name="description"> <meta content="xml2rfc 3.24.0" name="generator"> <meta content="Concise Data Definition Language" name="keyword"> <meta content="9682" name="rfc.number"> <!-- Generator version information: xml2rfc 3.24.0 Python 3.9.15 ConfigArgParse 1.5.3 google-i18n-address 3.0.0 intervaltree 3.1.0 Jinja2 3.1.2 lxml 5.3.0 platformdirs 3.8.0 pycountry 22.3.5 pydyf 0.10.0 PyYAML 6.0 requests 2.28.0 setuptools 44.1.1 wcwidth 0.2.5 weasyprint 62.3 --> <link href="rfc9682.xml" rel="alternate" type="application/rfc+xml"> <link href="#copyright" rel="license"> <style type="text/css">/* NOTE: Changes at the bottom of this file overrides some earlier settings. Once the style has stabilized and has been adopted as an official RFC style, this can be consolidated so that style settings occur only in one place, but for now the contents of this file consists first of the initial CSS work as provided to the RFC Formatter (xml2rfc) work, followed by itemized and commented changes found necessary during the development of the v3 formatters. */ /* fonts */ @import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */ @import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */ @import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */ :root { --font-sans: 'Noto Sans', Arial, Helvetica, sans-serif; --font-serif: 'Noto Serif', 'Times', 'Times New Roman', serif; --font-mono: 'Roboto Mono', Courier, 'Courier New', monospace; } @viewport { zoom: 1.0; } @-ms-viewport { width: extend-to-zoom; zoom: 1.0; } /* general and mobile first */ html { } body { max-width: 90%; margin: 1.5em auto; color: #222; background-color: #fff; font-size: 14px; font-family: var(--font-sans); line-height: 1.6; scroll-behavior: smooth; overflow-wrap: break-word; } .ears { display: none; } /* headings */ #title, h1, h2, h3, h4, h5, h6 { margin: 1em 0 0.5em; font-weight: bold; line-height: 1.3; } #title { clear: both; border-bottom: 1px solid #ddd; margin: 0 0 0.5em 0; padding: 1em 0 0.5em; } .author { padding-bottom: 4px; } h1 { font-size: 26px; margin: 1em 0; } h2 { font-size: 22px; margin-top: -20px; /* provide offset for in-page anchors */ padding-top: 33px; } h3 { font-size: 18px; margin-top: -36px; /* provide offset for in-page anchors */ padding-top: 42px; } h4 { font-size: 16px; margin-top: -36px; /* provide offset for in-page anchors */ padding-top: 42px; } h5, h6 { font-size: 14px; } #n-copyright-notice { border-bottom: 1px solid #ddd; padding-bottom: 1em; margin-bottom: 1em; } /* general structure */ p { padding: 0; margin: 0 0 1em 0; text-align: left; } div, span { position: relative; } div { margin: 0; } .alignRight.art-text { background-color: #f9f9f9; border: 1px solid #eee; border-radius: 3px; padding: 1em 1em 0; margin-bottom: 1.5em; } .alignRight.art-text pre { padding: 0; } .alignRight { margin: 1em 0; } .alignRight > *:first-child { border: none; margin: 0; float: right; clear: both; } .alignRight > *:nth-child(2) { clear: both; display: block; border: none; } svg { display: block; } svg[font-family~="serif" i], svg [font-family~="serif" i] { font-family: var(--font-serif); } svg[font-family~="sans-serif" i], svg [font-family~="sans-serif" i] { font-family: var(--font-sans); } svg[font-family~="monospace" i], svg [font-family~="monospace" i] { font-family: var(--font-mono); } .alignCenter.art-text { background-color: #f9f9f9; border: 1px solid #eee; border-radius: 3px; padding: 1em 1em 0; margin-bottom: 1.5em; } .alignCenter.art-text pre { padding: 0; } .alignCenter { margin: 1em 0; } .alignCenter > *:first-child { display: table; border: none; margin: 0 auto; } /* lists */ ol, ul { padding: 0; margin: 0 0 1em 2em; } ol ol, ul ul, ol ul, ul ol { margin-left: 1em; } li { margin: 0 0 0.25em 0; } .ulCompact li { margin: 0; } ul.empty, .ulEmpty { list-style-type: none; } ul.empty li, .ulEmpty li { margin-top: 0.5em; } ul.ulBare, li.ulBare { margin-left: 0em !important; } ul.compact, .ulCompact, ol.compact, .olCompact { line-height: 100%; margin: 0 0 0 2em; } /* definition lists */ dl { } dl > dt { float: left; margin-right: 1em; } /* dl.nohang > dt { float: none; } */ dl > dd { margin-bottom: .8em; min-height: 1.3em; } dl.compact > dd, .dlCompact > dd { margin-bottom: 0em; } dl > dd > dl { margin-top: 0.5em; margin-bottom: 0em; } /* links */ a { text-decoration: none; } a[href] { color: #22e; /* Arlen: WCAG 2019 */ } a[href]:hover { background-color: #f2f2f2; } figcaption a[href], a[href].selfRef { color: #222; } /* XXX probably not this: a.selfRef:hover { background-color: transparent; cursor: default; } */ /* Figures */ tt, code, pre { background-color: #f9f9f9; font-family: var(--font-mono); } pre { border: 1px solid #eee; margin: 0; padding: 1em; } img { max-width: 100%; } figure { margin: 0; } figure blockquote { margin: 0.8em 0.4em 0.4em; } figcaption { font-style: italic; margin: 0 0 1em 0; } @media screen { pre { overflow-x: auto; max-width: 100%; max-width: calc(100% - 22px); } } /* aside, blockquote */ aside, blockquote { margin-left: 0; padding: 1.2em 2em; } blockquote { background-color: #f9f9f9; color: #111; /* Arlen: WCAG 2019 */ border: 1px solid #ddd; border-radius: 3px; margin: 1em 0; } blockquote > *:last-child { margin-bottom: 0; } cite { display: block; text-align: right; font-style: italic; } .xref { overflow-wrap: normal; } /* tables */ table { width: 100%; margin: 0 0 1em; border-collapse: collapse; border: 1px solid #eee; } th, td { text-align: left; vertical-align: top; padding: 0.5em 0.75em; } th { text-align: left; background-color: #e9e9e9; } tr:nth-child(2n+1) > td { background-color: #f5f5f5; } table caption { font-style: italic; margin: 0; padding: 0; text-align: left; } table p { /* XXX to avoid bottom margin on table row signifiers. If paragraphs should be allowed within tables more generally, it would be far better to select on a class. */ margin: 0; } /* pilcrow */ a.pilcrow { color: #666; /* Arlen: AHDJ 2019 */ text-decoration: none; visibility: hidden; user-select: none; -ms-user-select: none; -o-user-select:none; -moz-user-select: none; -khtml-user-select: none; -webkit-user-select: none; -webkit-touch-callout: none; } @media screen { aside:hover > a.pilcrow, p:hover > a.pilcrow, blockquote:hover > a.pilcrow, div:hover > a.pilcrow, li:hover > a.pilcrow, pre:hover > a.pilcrow { visibility: visible; } a.pilcrow:hover { background-color: transparent; } } /* misc */ hr { border: 0; border-top: 1px solid #eee; } .bcp14 { font-variant: small-caps; } .role { font-variant: all-small-caps; } /* info block */ #identifiers { margin: 0; font-size: 0.9em; } #identifiers dt { width: 3em; clear: left; } #identifiers dd { float: left; margin-bottom: 0; } /* Fix PDF info block run off issue */ @media print { #identifiers dd { float: none; } } #identifiers .authors .author { display: inline-block; margin-right: 1.5em; } #identifiers .authors .org { font-style: italic; } /* The prepared/rendered info at the very bottom of the page */ .docInfo { color: #666; /* Arlen: WCAG 2019 */ font-size: 0.9em; font-style: italic; margin-top: 2em; } .docInfo .prepared { float: left; } .docInfo .prepared { float: right; } /* table of contents */ #toc { padding: 0.75em 0 2em 0; margin-bottom: 1em; } nav.toc ul { margin: 0 0.5em 0 0; padding: 0; list-style: none; } nav.toc li { line-height: 1.3em; margin: 0.75em 0; padding-left: 1.2em; text-indent: -1.2em; } /* references */ .references dt { text-align: right; font-weight: bold; min-width: 7em; } .references dd { margin-left: 8em; overflow: auto; } .refInstance { margin-bottom: 1.25em; } .refSubseries { margin-bottom: 1.25em; } .references .ascii { margin-bottom: 0.25em; } /* index */ .index ul { margin: 0 0 0 1em; padding: 0; list-style: none; } .index ul ul { margin: 0; } .index li { margin: 0; text-indent: -2em; padding-left: 2em; padding-bottom: 5px; } .indexIndex { margin: 0.5em 0 1em; } .index a { font-weight: 700; } /* make the index two-column on all but the smallest screens */ @media (min-width: 600px) { .index ul { -moz-column-count: 2; -moz-column-gap: 20px; } .index ul ul { -moz-column-count: 1; -moz-column-gap: 0; } } /* authors */ address.vcard { font-style: normal; margin: 1em 0; } address.vcard .nameRole { font-weight: 700; margin-left: 0; } address.vcard .label { font-family: var(--font-sans); margin: 0.5em 0; } address.vcard .type { display: none; } .alternative-contact { margin: 1.5em 0 1em; } hr.addr { border-top: 1px dashed; margin: 0; color: #ddd; max-width: calc(100% - 16px); } /* temporary notes */ .rfcEditorRemove::before { position: absolute; top: 0.2em; right: 0.2em; padding: 0.2em; content: "The RFC Editor will remove this note"; color: #9e2a00; /* Arlen: WCAG 2019 */ background-color: #ffd; /* Arlen: WCAG 2019 */ } .rfcEditorRemove { position: relative; padding-top: 1.8em; background-color: #ffd; /* Arlen: WCAG 2019 */ border-radius: 3px; } .cref { background-color: #ffd; /* Arlen: WCAG 2019 */ padding: 2px 4px; } .crefSource { font-style: italic; } /* alternative layout for smaller screens */ @media screen and (max-width: 1023px) { body { padding-top: 2em; } #title { padding: 1em 0; } h1 { font-size: 24px; } h2 { font-size: 20px; margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 38px; } #identifiers dd { max-width: 60%; } #toc { position: fixed; z-index: 2; top: 0; right: 0; padding: 0; margin: 0; background-color: inherit; border-bottom: 1px solid #ccc; } #toc h2 { margin: -1px 0 0 0; padding: 4px 0 4px 6px; padding-right: 1em; min-width: 190px; font-size: 1.1em; text-align: right; background-color: #444; color: white; cursor: pointer; } #toc h2::before { /* css hamburger */ float: right; position: relative; width: 1em; height: 1px; left: -164px; margin: 6px 0 0 0; background: white none repeat scroll 0 0; box-shadow: 0 4px 0 0 white, 0 8px 0 0 white; content: ""; } #toc nav { display: none; padding: 0.5em 1em 1em; overflow: auto; height: calc(100vh - 48px); border-left: 1px solid #ddd; } } /* alternative layout for wide screens */ @media screen and (min-width: 1024px) { body { max-width: 724px; margin: 42px auto; padding-left: 1.5em; padding-right: 29em; } #toc { position: fixed; top: 42px; right: 42px; width: 25%; margin: 0; padding: 0 1em; z-index: 1; } #toc h2 { border-top: none; border-bottom: 1px solid #ddd; font-size: 1em; font-weight: normal; margin: 0; padding: 0.25em 1em 1em 0; } #toc nav { display: block; height: calc(90vh - 84px); bottom: 0; padding: 0.5em 0 0; overflow: auto; } img { /* future proofing */ max-width: 100%; height: auto; } } /* pagination */ @media print { body { width: 100%; } p { orphans: 3; widows: 3; } #n-copyright-notice { border-bottom: none; } #toc, #n-introduction { page-break-before: always; } #toc { border-top: none; padding-top: 0; } figure, pre { page-break-inside: avoid; } figure { overflow: scroll; } .breakable pre { break-inside: auto; } h1, h2, h3, h4, h5, h6 { page-break-after: avoid; } h2+*, h3+*, h4+*, h5+*, h6+* { page-break-before: avoid; } pre { white-space: pre-wrap; word-wrap: break-word; font-size: 10pt; } table { border: 1px solid #ddd; } td { border-top: 1px solid #ddd; } } /* This is commented out here, as the string-set: doesn't pass W3C validation currently */ /* .ears thead .left { string-set: ears-top-left content(); } .ears thead .center { string-set: ears-top-center content(); } .ears thead .right { string-set: ears-top-right content(); } .ears tfoot .left { string-set: ears-bottom-left content(); } .ears tfoot .center { string-set: ears-bottom-center content(); } .ears tfoot .right { string-set: ears-bottom-right content(); } */ @page :first { padding-top: 0; @top-left { content: normal; border: none; } @top-center { content: normal; border: none; } @top-right { content: normal; border: none; } } @page { size: A4; margin-bottom: 45mm; padding-top: 20px; /* The following is commented out here, but set appropriately by in code, as the content depends on the document */ /* @top-left { content: 'Internet-Draft'; vertical-align: bottom; border-bottom: solid 1px #ccc; } @top-left { content: string(ears-top-left); vertical-align: bottom; border-bottom: solid 1px #ccc; } @top-center { content: string(ears-top-center); vertical-align: bottom; border-bottom: solid 1px #ccc; } @top-right { content: string(ears-top-right); vertical-align: bottom; border-bottom: solid 1px #ccc; } @bottom-left { content: string(ears-bottom-left); vertical-align: top; border-top: solid 1px #ccc; } @bottom-center { content: string(ears-bottom-center); vertical-align: top; border-top: solid 1px #ccc; } @bottom-right { content: '[Page ' counter(page) ']'; vertical-align: top; border-top: solid 1px #ccc; } */ } /* Changes introduced to fix issues found during implementation */ /* Make sure links are clickable even if overlapped by following H* */ a { z-index: 2; } /* Separate body from document info even without intervening H1 */ section { clear: both; } /* Top align author divs, to avoid names without organization dropping level with org names */ .author { vertical-align: top; } /* Leave room in document info to show Internet-Draft on one line */ #identifiers dt { width: 8em; } /* Don't waste quite as much whitespace between label and value in doc info */ #identifiers dd { margin-left: 1em; } /* Give floating toc a background color (needed when it's a div inside section */ #toc { background-color: white; } /* Make the collapsed ToC header render white on gray also when it's a link */ @media screen and (max-width: 1023px) { #toc h2 a, #toc h2 a:link, #toc h2 a:focus, #toc h2 a:hover, #toc a.toplink, #toc a.toplink:hover { color: white; background-color: #444; text-decoration: none; } } /* Give the bottom of the ToC some whitespace */ @media screen and (min-width: 1024px) { #toc { padding: 0 0 1em 1em; } } /* Style section numbers with more space between number and title */ .section-number { padding-right: 0.5em; } /* prevent monospace from becoming overly large */ tt, code, pre { font-size: 95%; } /* Fix the height/width aspect for ascii art*/ .sourcecode pre, .art-text pre { line-height: 1.12; } /* Add styling for a link in the ToC that points to the top of the document */ a.toplink { float: right; margin-right: 0.5em; } /* Fix the dl styling to match the RFC 7992 attributes */ dl > dt, dl.dlParallel > dt { float: left; margin-right: 1em; } dl.dlNewline > dt { float: none; } /* Provide styling for table cell text alignment */ table td.text-left, table th.text-left { text-align: left; } table td.text-center, table th.text-center { text-align: center; } table td.text-right, table th.text-right { text-align: right; } /* Make the alternative author contact information look less like just another author, and group it closer with the primary author contact information */ .alternative-contact { margin: 0.5em 0 0.25em 0; } address .non-ascii { margin: 0 0 0 2em; } /* With it being possible to set tables with alignment left, center, and right, { width: 100%; } does not make sense */ table { width: auto; } /* Avoid reference text that sits in a block with very wide left margin, because of a long floating dt label.*/ .references dd { overflow: visible; } /* Control caption placement */ caption { caption-side: bottom; } /* Limit the width of the author address vcard, so names in right-to-left script don't end up on the other side of the page. */ address.vcard { max-width: 30em; margin-right: auto; } /* For address alignment dependent on LTR or RTL scripts */ address div.left { text-align: left; } address div.right { text-align: right; } /* Provide table alignment support. We can't use the alignX classes above since they do unwanted things with caption and other styling. */ table.right { margin-left: auto; margin-right: 0; } table.center { margin-left: auto; margin-right: auto; } table.left { margin-left: 0; margin-right: auto; } /* Give the table caption label the same styling as the figcaption */ caption a[href] { color: #222; } @media print { .toplink { display: none; } /* avoid overwriting the top border line with the ToC header */ #toc { padding-top: 1px; } /* Avoid page breaks inside dl and author address entries */ .vcard { page-break-inside: avoid; } } /* Tweak the bcp14 keyword presentation */ .bcp14 { font-variant: small-caps; font-weight: bold; font-size: 0.9em; } /* Tweak the invisible space above H* in order not to overlay links in text above */ h2 { margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 31px; } h3 { margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 24px; } h4 { margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 24px; } /* Float artwork pilcrow to the right */ @media screen { .artwork a.pilcrow { display: block; line-height: 0.7; margin-top: 0.15em; } } /* Make pilcrows on dd visible */ @media screen { dd:hover > a.pilcrow { visibility: visible; } } /* Make the placement of figcaption match that of a table's caption by removing the figure's added bottom margin */ .alignLeft.art-text, .alignCenter.art-text, .alignRight.art-text { margin-bottom: 0; } .alignLeft, .alignCenter, .alignRight { margin: 1em 0 0 0; } /* In print, the pilcrow won't show on hover, so prevent it from taking up space, possibly even requiring a new line */ @media print { a.pilcrow { display: none; } } /* Styling for the external metadata */ div#external-metadata { background-color: #eee; padding: 0.5em; margin-bottom: 0.5em; display: none; } div#internal-metadata { padding: 0.5em; /* to match the external-metadata padding */ } /* Styling for title RFC Number */ h1#rfcnum { clear: both; margin: 0 0 -1em; padding: 1em 0 0 0; } /* Make .olPercent look the same as <ol><li> */ dl.olPercent > dd { margin-bottom: 0.25em; min-height: initial; } /* Give aside some styling to set it apart */ aside { border-left: 1px solid #ddd; margin: 1em 0 1em 2em; padding: 0.2em 2em; } aside > dl, aside > ol, aside > ul, aside > table, aside > p { margin-bottom: 0.5em; } /* Additional page break settings */ @media print { figcaption, table caption { page-break-before: avoid; } } /* Font size adjustments for print */ @media print { body { font-size: 10pt; line-height: normal; max-width: 96%; } h1 { font-size: 1.72em; padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */ h2 { font-size: 1.44em; padding-top: 1.5em; } /* 1*1.2*1.2 */ h3 { font-size: 1.2em; padding-top: 1.5em; } /* 1*1.2 */ h4 { font-size: 1em; padding-top: 1.5em; } h5, h6 { font-size: 1em; margin: initial; padding: 0.5em 0 0.3em; } } /* Sourcecode margin in print, when there's no pilcrow */ @media print { .artwork, .artwork > pre, .sourcecode { margin-bottom: 1em; } } /* Avoid narrow tables forcing too narrow table captions, which may render badly */ table { min-width: 20em; } /* ol type a */ ol.type-a { list-style-type: lower-alpha; } ol.type-A { list-style-type: upper-alpha; } ol.type-i { list-style-type: lower-roman; } ol.type-I { list-style-type: upper-roman; } /* Apply the print table and row borders in general, on request from the RPC, and increase the contrast between border and odd row background slightly */ table { border: 1px solid #ddd; } td { border-top: 1px solid #ddd; } tr { break-inside: avoid; } tr:nth-child(2n+1) > td { background-color: #f8f8f8; } /* Use style rules to govern display of the TOC. */ @media screen and (max-width: 1023px) { #toc nav { display: none; } #toc.active nav { display: block; } } /* Add support for keepWithNext */ .keepWithNext { break-after: avoid-page; break-after: avoid-page; } /* Add support for keepWithPrevious */ .keepWithPrevious { break-before: avoid-page; } /* Change the approach to avoiding breaks inside artwork etc. */ figure, pre, table, .artwork, .sourcecode { break-before: auto; break-after: auto; } /* Avoid breaks between <dt> and <dd> */ dl { break-before: auto; break-inside: auto; } dt { break-before: auto; break-after: avoid-page; } dd { break-before: avoid-page; break-after: auto; orphans: 3; widows: 3 } span.break, dd.break { margin-bottom: 0; min-height: 0; break-before: auto; break-inside: auto; break-after: auto; } /* Undo break-before ToC */ @media print { #toc { break-before: auto; } } /* Text in compact lists should not get extra bottom margin space, since that would makes the list not compact */ ul.compact p, .ulCompact p, ol.compact p, .olCompact p { margin: 0; } /* But the list as a whole needs the extra space at the end */ section ul.compact, section .ulCompact, section ol.compact, section .olCompact { margin-bottom: 1em; /* same as p not within ul.compact etc. */ } /* The tt and code background above interferes with for instance table cell backgrounds. Changed to something a bit more selective. */ tt, code { background-color: transparent; } p tt, p code, li tt, li code, dt tt, dt code { background-color: #f8f8f8; } /* Tweak the pre margin -- 0px doesn't come out well */ pre { margin-top: 0.5px; } /* Tweak the compact list text */ ul.compact, .ulCompact, ol.compact, .olCompact, dl.compact, .dlCompact { line-height: normal; } /* Don't add top margin for nested lists */ li > ul, li > ol, li > dl, dd > ul, dd > ol, dd > dl, dl > dd > dl { margin-top: initial; } /* Elements that should not be rendered on the same line as a <dt> */ /* This should match the element list in writer.text.TextWriter.render_dl() */ dd > div.artwork:first-child, dd > aside:first-child, dd > figure:first-child, dd > ol:first-child, dd > div.sourcecode:first-child, dd > table:first-child, dd > ul:first-child { clear: left; } /* fix for weird browser behaviour when <dd/> is empty */ dt+dd:empty::before{ content: "\00a0"; } /* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */ li > p { margin-bottom: 0.5em } /* Don't let p margin spill out from inside list items */ li > p:last-of-type:only-child { margin-bottom: 0; } </style> <link href="rfc-local.css" rel="stylesheet" type="text/css"> <link href="https://datatracker.ietf.org/doc/draft-ietf-cbor-update-8610-grammar-06" rel="prev"> <link href="https://dx.doi.org/10.17487/rfc9682" rel="alternate"> <link href="urn:issn:2070-1721" rel="alternate"> </head> <body class="xml2rfc"> <script src="https://www.rfc-editor.org/js/metadata.min.js"></script> <table class="ears"> <thead><tr> <td class="left">RFC 9682</td> <td class="center">CDDL grammar updates</td> <td class="right">November 2024</td> </tr></thead> <tfoot><tr> <td class="left">Bormann</td> <td class="center">Standards Track</td> <td class="right">[Page]</td> </tr></tfoot> </table> <div id="external-metadata" class="document-information"></div> <div id="internal-metadata" class="document-information"> <dl id="identifiers"> <dt class="label-stream">Stream:</dt> <dd class="stream">Internet Engineering Task Force (IETF)</dd> <dt class="label-rfc">RFC:</dt> <dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9682" class="eref">9682</a></dd> <dt class="label-updates">Updates:</dt> <dd class="updates"> <a href="https://www.rfc-editor.org/rfc/rfc8610" class="eref">8610</a> </dd> <dt class="label-category">Category:</dt> <dd class="category">Standards Track</dd> <dt class="label-published">Published:</dt> <dd class="published"> <time datetime="2024-11" class="published">November 2024</time> </dd> <dt class="label-issn">ISSN:</dt> <dd class="issn">2070-1721</dd> <dt class="label-authors">Author:</dt> <dd class="authors"> <div class="author"> <div class="author-name">C. Bormann</div> <div class="org">Universität Bremen TZI</div> </div> </dd> </dl> </div> <h1 id="rfcnum">RFC 9682</h1> <h1 id="title">Updates to the Concise Data Definition Language (CDDL) Grammar</h1> <section id="section-abstract"> <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2> <p id="section-abstract-1">The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON.<a href="#section-abstract-1" class="pilcrow">¶</a></p> <p id="section-abstract-2">This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL.<a href="#section-abstract-2" class="pilcrow">¶</a></p> </section> <div id="status-of-memo"> <section id="section-boilerplate.1"> <h2 id="name-status-of-this-memo"> <a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a> </h2> <p id="section-boilerplate.1-1"> This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p> <p id="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p> <p id="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <span><a href="https://www.rfc-editor.org/info/rfc9682">https://www.rfc-editor.org/info/rfc9682</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p> </section> </div> <div id="copyright"> <section id="section-boilerplate.2"> <h2 id="name-copyright-notice"> <a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a> </h2> <p id="section-boilerplate.2-1"> Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p> <p id="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p> </section> </div> <div id="toc"> <section id="section-toc.1"> <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents"> <a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a> </h2> <nav class="toc"><ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1"> <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1"> <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>.  <a href="#name-conventions-and-definitions" class="internal xref">Conventions and Definitions</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2"> <p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-clarifications-and-changes-" class="internal xref">Clarifications and Changes Based on Errata Reports</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1"> <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="auto internal xref">2.1</a>.  <a href="#name-updates-to-string-literal-g" class="internal xref">Updates to String Literal Grammar</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.1"> <p id="section-toc.1-1.2.2.1.2.1.1" class="keepWithNext"><a href="#section-2.1.1" class="auto internal xref">2.1.1</a>.  <a href="#name-erratum-id-6527-text-string" class="internal xref">Erratum ID 6527 (Text String Literals)</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.2"> <p id="section-toc.1-1.2.2.1.2.2.1"><a href="#section-2.1.2" class="auto internal xref">2.1.2</a>.  <a href="#name-erratum-id-6278-consistent-" class="internal xref">Erratum ID 6278 (Consistent String Literals)</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.3"> <p id="section-toc.1-1.2.2.1.2.3.1"><a href="#section-2.1.3" class="auto internal xref">2.1.3</a>.  <a href="#name-addressing-erratum-id-6526-" class="internal xref">Addressing Erratum ID 6526 and Erratum ID 6543</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2"> <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="auto internal xref">2.2</a>.  <a href="#name-examples-demonstrating-the-" class="internal xref">Examples Demonstrating the Updated String Syntaxes</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3"> <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-small-enabling-grammar-chan" class="internal xref">Small Enabling Grammar Changes</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1"> <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-empty-data-models" class="internal xref">Empty Data Models</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2"> <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-non-literal-tag-numbers-and" class="internal xref">Non-Literal Tag Numbers and Simple Values</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4"> <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5"> <p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>.  <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6"> <p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>.  <a href="#name-references" class="internal xref">References</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1"> <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="auto internal xref">6.1</a>.  <a href="#name-normative-references" class="internal xref">Normative References</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2"> <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>.  <a href="#name-informative-references" class="internal xref">Informative References</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7"> <p id="section-toc.1-1.7.1"><a href="#appendix-A" class="auto internal xref">Appendix A</a>.  <a href="#name-updated-collected-abnf-for-" class="internal xref">Updated Collected ABNF for CDDL</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8"> <p id="section-toc.1-1.8.1"><a href="#appendix-B" class="auto internal xref">Appendix B</a>.  <a href="#name-details-about-covering-erra" class="internal xref">Details about Covering Erratum ID 6543</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1"> <p id="section-toc.1-1.8.2.1.1"><a href="#appendix-B.1" class="auto internal xref">B.1</a>.  <a href="#name-change-proposed-by-erratum-" class="internal xref">Change Proposed by Erratum ID 6543</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2"> <p id="section-toc.1-1.8.2.2.1"><a href="#appendix-B.2" class="auto internal xref">B.2</a>.  <a href="#name-no-further-change-needed-af" class="internal xref">No Further Change Needed after Updating String Literal Grammar</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9"> <p id="section-toc.1-1.9.1"><a href="#appendix-C" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10"> <p id="section-toc.1-1.10.1"><a href="#appendix-D" class="auto internal xref"></a><a href="#name-authors-address" class="internal xref">Author's Address</a></p> </li> </ul> </nav> </section> </div> <div id="introduction"> <section id="section-1"> <h2 id="name-introduction"> <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a> </h2> <p id="section-1-1">The Concise Data Definition Language (CDDL), as defined in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> and <span>[<a href="#RFC9165" class="cite xref">RFC9165</a>]</span>, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in CBOR or JSON.<a href="#section-1-1" class="pilcrow">¶</a></p> <p id="section-1-2">This document updates <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> by addressing errata reports and making other small fixes for the ABNF grammar defined for CDDL. The body of this document explains and shows motivation for the updates; the updated collected ABNF syntax in <a href="#collected-abnf" class="auto internal xref">Figure 11</a> in <a href="#collected-abnf-appendix" class="auto internal xref">Appendix A</a> replaces the collected ABNF syntax in <span><a href="https://rfc-editor.org/rfc/rfc8610#appendix-B" class="relref">Appendix B</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p> <div id="conventions-and-definitions"> <section id="section-1.1"> <h3 id="name-conventions-and-definitions"> <a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-conventions-and-definitions" class="section-name selfRef">Conventions and Definitions</a> </h3> <p id="section-1.1-1">The terminology from <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> applies. The grammar in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> is based on ABNF, which is defined in <span>[<a href="#STD68" class="cite xref">STD68</a>]</span> and <span>[<a href="#RFC7405" class="cite xref">RFC7405</a>]</span>.<a href="#section-1.1-1" class="pilcrow">¶</a></p> </section> </div> </section> </div> <div id="clari"> <section id="section-2"> <h2 id="name-clarifications-and-changes-"> <a href="#section-2" class="section-number selfRef">2. </a><a href="#name-clarifications-and-changes-" class="section-name selfRef">Clarifications and Changes Based on Errata Reports</a> </h2> <p id="section-2-1">A number of errata reports have been made regarding some details of text string and byte string literal syntax: for example, <span>[<a href="#Err6527" class="cite xref">Err6527</a>]</span> and <span>[<a href="#Err6543" class="cite xref">Err6543</a>]</span>. These are being addressed in this section, updating details of the ABNF for these literal syntaxes. Also, the changes described in <span>[<a href="#Err6526" class="cite xref">Err6526</a>]</span> need to be applied (backslashes have been lost during the RFC publication process of <span><a href="https://rfc-editor.org/rfc/rfc8610#appendix-G.2" class="relref">Appendix G.2</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>, garbling the text explaining backslash escaping).<a href="#section-2-1" class="pilcrow">¶</a></p> <p id="section-2-2">These changes are intended to mirror the way existing implementations have dealt with the errata reports. This document also uses the opportunity presented by the necessary cleanup of the grammar of string literals for a backward-compatible addition to the syntax for hexadecimal escapes. The latter change is not automatically forward compatible (i.e., CDDL specifications that make use of this syntax do not necessarily work with existing implementations until these are updated, which is recommended by this specification).<a href="#section-2-2" class="pilcrow">¶</a></p> <div id="e6527"> <section id="section-2.1"> <h3 id="name-updates-to-string-literal-g"> <a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-updates-to-string-literal-g" class="section-name selfRef">Updates to String Literal Grammar</a> </h3> <div id="err6527-text-string-literals"> <section id="section-2.1.1"> <h4 id="name-erratum-id-6527-text-string"> <a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-erratum-id-6527-text-string" class="section-name selfRef">Erratum ID 6527 (Text String Literals)</a> </h4> <p id="section-2.1.1-1">The ABNF used in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> for the content of text string literals is rather permissive:<a href="#section-2.1.1-1" class="pilcrow">¶</a></p> <span id="name-original-abnf-from-rfc-8610"></span><div id="e6527-orig1"> <figure id="figure-1"> <div class="lang-abnf sourcecode" id="section-2.1.1-2.1"> <pre> ; ABNF from RFC 8610: text = %x22 *SCHAR %x22 SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC SESC = "\" (%x20-7E / %x80-10FFFD) </pre> </div> <figcaption><a href="#figure-1" class="selfRef">Figure 1</a>: <a href="#name-original-abnf-from-rfc-8610" class="selfRef">Original ABNF from RFC 8610 for Strings with Permissive ABNF for SESC (Which Did Not Allow Hex Escapes)</a> </figcaption></figure> </div> <p id="section-2.1.1-3">This allows almost any non-C0 character to be escaped by a backslash, but critically misses out on the <code>\uXXXX</code> and <code>\uHHHH\uLLLL</code> forms that JSON allows to specify characters in hex (which should apply here according to item 6 of <span><a href="https://rfc-editor.org/rfc/rfc8610#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>). (Note that CDDL imports from JSON the unwieldy <code>\uHHHH\uLLLL</code> syntax, which represents Unicode code points beyond U+FFFF by making them look like UTF-16 surrogate pairs; CDDL text strings do not use UTF-16 or surrogates.)<a href="#section-2.1.1-3" class="pilcrow">¶</a></p> <p id="section-2.1.1-4">Both can be solved by updating the SESC rule. This document uses the opportunity to add a popular form of directly specifying characters in strings using hexadecimal escape sequences of the form <code>\u{hex}</code>, where <code>hex</code> is the hexadecimal representation of the Unicode scalar value. The result is the new set of rules defining SESC in <a href="#e6527-new1" class="auto internal xref">Figure 2</a>.<a href="#section-2.1.1-4" class="pilcrow">¶</a></p> <span id="name-update-to-string-abnf-in-al"></span><div id="e6527-new1"> <figure id="figure-2"> <div class="lang-abnf sourcecode" id="section-2.1.1-5.1"> <pre> ; new rules collectively defining SESC: SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\ %x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t (%x75 hexchar) ) ; \uXXXX hexchar = "{" (1*"0" [ hexscalar ] / hexscalar) "}" / 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 hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG / non-surrogate / 1*3HEXDIG HEXDIG1 = DIGIT1 / "A" / "B" / "C" / "D" / "E" / "F" </pre> </div> <figcaption><a href="#figure-2" class="selfRef">Figure 2</a>: <a href="#name-update-to-string-abnf-in-al" class="selfRef">Update to String ABNF in <span><a href="https://rfc-editor.org/rfc/rfc8610#appendix-B" class="relref">Appendix B</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>: Allow Hex Escapes</a> </figcaption></figure> </div> <aside id="section-2.1.1-6"> <p id="section-2.1.1-6.1">Notes: In ABNF, strings such as <code>"A"</code>, <code>"B"</code>, etc., are case insensitive, as is intended here. The rules above could have also used <code>%s"b"</code>, etc., instead of <code>%x62</code>, but didn't, in order to maximize compatibility with ABNF tools.<a href="#section-2.1.1-6.1" class="pilcrow">¶</a></p> </aside> <p id="section-2.1.1-7">Now that SESC is more restrictively formulated, an update to the BCHAR rule used in the ABNF syntax for byte string literals is also required:<a href="#section-2.1.1-7" class="pilcrow">¶</a></p> <span id="name-abnf-from-rfc-8610-for-bcha"></span><div id="e6527-orig2"> <figure id="figure-3"> <div class="lang-abnf sourcecode" id="section-2.1.1-8.1"> <pre> ; ABNF from RFC 8610: bytes = [bsqual] %x27 *BCHAR %x27 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF bsqual = "h" / "b64" </pre> </div> <figcaption><a href="#figure-3" class="selfRef">Figure 3</a>: <a href="#name-abnf-from-rfc-8610-for-bcha" class="selfRef">ABNF from RFC 8610 for BCHAR</a> </figcaption></figure> </div> <p id="section-2.1.1-9">With the SESC updated as above, <code>\'</code> is no longer allowed in BCHAR and now needs to be explicitly included there; see <a href="#e6527-new2" class="auto internal xref">Figure 4</a>.<a href="#section-2.1.1-9" class="pilcrow">¶</a></p> </section> </div> <div id="e6278"> <section id="section-2.1.2"> <h4 id="name-erratum-id-6278-consistent-"> <a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-erratum-id-6278-consistent-" class="section-name selfRef">Erratum ID 6278 (Consistent String Literals)</a> </h4> <p id="section-2.1.2-1">Updating BCHAR also provides an opportunity to address <span>[<a href="#Err6278" class="cite xref">Err6278</a>]</span>, which points to an inconsistency in treating U+007F (DEL) between SCHAR and BCHAR. As U+007F is not printable, including it in a byte string literal is as confusing as for a text string literal; therefore, it should be excluded from BCHAR as it is from SCHAR. The same reasoning also applies to the C1 control characters, so the updated ABNF actually excludes the entire range from U+007F to U+009F. The same reasoning also applies to text in comments (PCHAR). For completeness, all these rules should also explicitly exclude the code points that have been set aside for UTF-16 surrogates.<a href="#section-2.1.2-1" class="pilcrow">¶</a></p> <span id="name-update-to-abnf-in-bchar-sch"></span><div id="e6527-new2"> <figure id="figure-4"> <div class="lang-abnf sourcecode" id="section-2.1.2-2.1"> <pre> ; new rules for SCHAR, BCHAR, and PCHAR: SCHAR = %x20-21 / %x23-5B / %x5D-7E / NONASCII / SESC BCHAR = %x20-26 / %x28-5B / %x5D-7E / NONASCII / SESC / "\'" / CRLF PCHAR = %x20-7E / NONASCII NONASCII = %xA0-D7FF / %xE000-10FFFD </pre> </div> <figcaption><a href="#figure-4" class="selfRef">Figure 4</a>: <a href="#name-update-to-abnf-in-bchar-sch" class="selfRef">Update to ABNF in <span><a href="https://rfc-editor.org/rfc/rfc8610#appendix-B" class="relref">Appendix B</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>: BCHAR, SCHAR, and PCHAR</a> </figcaption></figure> </div> <p id="section-2.1.2-3">(Note that, apart from addressing the inconsistencies, there is no attempt to further exclude non-printable characters from the ABNF; doing this properly would draw in complexity from the ongoing evolution of the Unicode standard <span>[<a href="#UNICODE" class="cite xref">UNICODE</a>]</span> that is not needed here.)<a href="#section-2.1.2-3" class="pilcrow">¶</a></p> </section> </div> <div id="addressing-err6526-err6543"> <section id="section-2.1.3"> <h4 id="name-addressing-erratum-id-6526-"> <a href="#section-2.1.3" class="section-number selfRef">2.1.3. </a><a href="#name-addressing-erratum-id-6526-" class="section-name selfRef">Addressing Erratum ID 6526 and Erratum ID 6543</a> </h4> <p id="section-2.1.3-1">The above changes also cover <span>[<a href="#Err6543" class="cite xref">Err6543</a>]</span> (a proposal to split off qualified byte string literals from UTF-8 byte string literals) and <span>[<a href="#Err6526" class="cite xref">Err6526</a>]</span> (lost backslashes); see <a href="#Err6543-covered" class="auto internal xref">Appendix B</a> for details.<a href="#section-2.1.3-1" class="pilcrow">¶</a></p> </section> </div> </section> </div> <div id="examples-demonstrating-the-updated-string-syntaxes"> <section id="section-2.2"> <h3 id="name-examples-demonstrating-the-"> <a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-examples-demonstrating-the-" class="section-name selfRef">Examples Demonstrating the Updated String Syntaxes</a> </h3> <p id="section-2.2-1">The CDDL example in <a href="#string-examples" class="auto internal xref">Figure 5</a> demonstrates various escaping techniques now available for (byte and text) strings in CDDL. Obviously, in the literals for <code>a</code> and <code>x</code>, there is no need to escape the second character, an <code>o</code>, as <code>\u{6f}</code>; this is just for demonstration. Similarly, as shown in <code>c</code> and <code>z</code>, there also is no need to escape the <span class="unicode">"🁳" (DOMINO TILE VERTICAL-02-02, U+1F073)</span> or <span class="unicode">"⌘" (PLACE OF INTEREST SIGN, U+2318)</span>; however, escaping them may be convenient in order to limit the character repertoire of a CDDL file itself to ASCII <span>[<a href="#STD80" class="cite xref">STD80</a>]</span>.<a href="#section-2.2-1" class="pilcrow">¶</a></p> <span id="name-example-text-and-byte-strin"></span><div id="string-examples"> <figure id="figure-5"> <div class="lang-cddl sourcecode" id="section-2.2-2.1"> <pre> start = [a, b, c, x, y, z] ; "🁳", DOMINO TILE VERTICAL-02-02, and ; "⌘", PLACE OF INTEREST SIGN, in a text string: a = "D\u{6f}mino's \u{1F073} + \u{2318}" ; \u{}-escape 3 chars b = "Domino's \uD83C\uDC73 + \u2318" ; escape JSON-like c = "Domino's 🁳 + ⌘" ; unescaped ; in a byte string given as text, the ' needs to be escaped: x = 'D\u{6f}mino\u{27}s \u{1F073} + \u{2318}' ; \u{}-escape 4 chars y = 'Domino\'s \uD83C\uDC73 + \u2318' ; escape JSON-like z = 'Domino\'s 🁳 + ⌘' ; escape ' only </pre> </div> <figcaption><a href="#figure-5" class="selfRef">Figure 5</a>: <a href="#name-example-text-and-byte-strin" class="selfRef">Example Text and Byte String Literals with Various Escaping Techniques</a> </figcaption></figure> </div> <p id="section-2.2-3">In this example, the rules a to c and x to z all produce strings with byte-wise identical content: a to c are text strings and x to z are byte strings. <a href="#string-examples-pretty" class="auto internal xref">Figure 6</a> illustrates this by showing the output generated from the <code>start</code> rule in <a href="#string-examples" class="auto internal xref">Figure 5</a>, using pretty-printed hexadecimal.<a href="#section-2.2-3" class="pilcrow">¶</a></p> <span id="name-generated-cbor-from-cddl-ex"></span><div id="string-examples-pretty"> <figure id="figure-6"> <div class="lang-cbor-pretty sourcecode" id="section-2.2-4.1"> <pre> 86 # array(6) 73 # text(19) 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 73 # text(19) 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 73 # text(19) 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 53 # bytes(19) 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 53 # bytes(19) 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 53 # bytes(19) 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" </pre> </div> <figcaption><a href="#figure-6" class="selfRef">Figure 6</a>: <a href="#name-generated-cbor-from-cddl-ex" class="selfRef">Generated CBOR from CDDL Example (Pretty-Printed Hexadecimal)</a> </figcaption></figure> </div> </section> </div> </section> </div> <div id="small-enabling-grammar-changes"> <section id="section-3"> <h2 id="name-small-enabling-grammar-chan"> <a href="#section-3" class="section-number selfRef">3. </a><a href="#name-small-enabling-grammar-chan" class="section-name selfRef">Small Enabling Grammar Changes</a> </h2> <p id="section-3-1">Each subsection that follows specifies a small change to the grammar that is intended to enable certain kinds of specifications. These changes are backward compatible (i.e., CDDL files that comply with <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> continue to match the updated grammar) but not necessarily forward compatible (i.e., CDDL specifications that make use of these changes cannot necessarily be processed by existing implementations of <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>).<a href="#section-3-1" class="pilcrow">¶</a></p> <div id="empty"> <section id="section-3.1"> <h3 id="name-empty-data-models"> <a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-empty-data-models" class="section-name selfRef">Empty Data Models</a> </h3> <p id="section-3.1-1"><span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> requires a CDDL file to have at least one rule.<a href="#section-3.1-1" class="pilcrow">¶</a></p> <span id="name-abnf-from-rfc-8610-for-top-"></span><div id="empty-orig"> <figure id="figure-7"> <div class="lang-abnf sourcecode" id="section-3.1-2.1"> <pre> ; ABNF from RFC 8610: cddl = S 1*(rule S) </pre> </div> <figcaption><a href="#figure-7" class="selfRef">Figure 7</a>: <a href="#name-abnf-from-rfc-8610-for-top-" class="selfRef">ABNF from RFC 8610 for Top-Level Rule <code>cddl</code></a> </figcaption></figure> </div> <p id="section-3.1-3">This makes sense when the file has to stand alone, as a CDDL data model needs to have at least one rule to provide an entry point (i.e., a start rule).<a href="#section-3.1-3" class="pilcrow">¶</a></p> <p id="section-3.1-4">With CDDL modules <span>[<a href="#I-D.ietf-cbor-cddl-modules" class="cite xref">CDDL-MODULES</a>]</span>, CDDL files can also include directives, and these might be the source of all the rules that ultimately make up the module created by the file. Any other rule content in the file has to be available for directive processing, making the requirement for at least one rule cumbersome.<a href="#section-3.1-4" class="pilcrow">¶</a></p> <p id="section-3.1-5">Therefore, the present update extends the grammar as in <a href="#empty-new" class="auto internal xref">Figure 8</a> and turns the existence of at least one rule into a semantic constraint, to be fulfilled after processing of all directives.<a href="#section-3.1-5" class="pilcrow">¶</a></p> <span id="name-update-to-top-level-abnf-in"></span><div id="empty-new"> <figure id="figure-8"> <div class="lang-abnf sourcecode" id="section-3.1-6.1"> <pre> ; new top-level rule: cddl = S *(rule S) </pre> </div> <figcaption><a href="#figure-8" class="selfRef">Figure 8</a>: <a href="#name-update-to-top-level-abnf-in" class="selfRef">Update to Top-Level ABNF in Appendices B and C of RFC 8610</a> </figcaption></figure> </div> </section> </div> <div id="tagnum"> <section id="section-3.2"> <h3 id="name-non-literal-tag-numbers-and"> <a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-non-literal-tag-numbers-and" class="section-name selfRef">Non-Literal Tag Numbers and Simple Values</a> </h3> <p id="section-3.2-1">The existing ABNF syntax for expressing tags in CDDL is as follows:<a href="#section-3.2-1" class="pilcrow">¶</a></p> <span id="name-original-abnf-from-rfc-8610-"></span><div id="tag-orig"> <figure id="figure-9"> <div class="lang-abnf sourcecode" id="section-3.2-2.1"> <pre> ; extracted from the ABNF in RFC 8610: type2 =/ "#" "6" ["." uint] "(" S type S ")" </pre> </div> <figcaption><a href="#figure-9" class="selfRef">Figure 9</a>: <a href="#name-original-abnf-from-rfc-8610-" class="selfRef">Original ABNF from RFC 8610 for Tag Syntax</a> </figcaption></figure> </div> <p id="section-3.2-3">This means tag numbers can only be given as literal numbers (uints). Some specifications operate on ranges of tag numbers; for example, <span>[<a href="#RFC9277" class="cite xref">RFC9277</a>]</span> has a range of tag numbers 1668546817 (0x63740101) to 1668612095 (0x6374FFFF) to tag specific content formats. This cannot currently be expressed in CDDL. Similar considerations apply to simple values (<code>#7.</code>xx).<a href="#section-3.2-3" class="pilcrow">¶</a></p> <p id="section-3.2-4">This update extends the syntax to the following:<a href="#section-3.2-4" class="pilcrow">¶</a></p> <span id="name-update-to-tag-and-simple-va"></span><div id="tag-new"> <figure id="figure-10"> <div class="lang-abnf sourcecode" id="section-3.2-5.1"> <pre> ; new rules collectively defining the tagged case: type2 =/ "#" "6" ["." head-number] "(" S type S ")" / "#" "7" ["." head-number] head-number = uint / ("&lt;" type "&gt;") </pre> </div> <figcaption><a href="#figure-10" class="selfRef">Figure 10</a>: <a href="#name-update-to-tag-and-simple-va" class="selfRef">Update to Tag and Simple Value ABNF in Appendices B and C of RFC 8610</a> </figcaption></figure> </div> <p id="section-3.2-6">For <code>#6</code>, the <code>head-number</code> stands for the tag number. For <code>#7</code>, the <code>head-number</code> stands for the simple value if it is in the ranges 0..23 or 32..255 (as per Section <a href="https://rfc-editor.org/rfc/rfc8949#section-3.3" class="relref">3.3</a> of RFC 8949 <span>[<a href="#STD94" class="cite xref">STD94</a>]</span>, the simple values 24..31 are not used). For 24..31, the <code>head-number</code> stands for the "additional information", e.g., <code>#7.25</code> or <code>#7.&lt;25&gt;</code> is a float16, etc. (All ranges mentioned here are inclusive.)<a href="#section-3.2-6" class="pilcrow">¶</a></p> <p id="section-3.2-7">So the above range can be expressed in a CDDL fragment such as:<a href="#section-3.2-7" class="pilcrow">¶</a></p> <div class="lang-cddl sourcecode" id="section-3.2-8"> <pre> ct-tag&lt;content&gt; = #6.&lt;ct-tag-number&gt;(content) ct-tag-number = 1668546817..1668612095 ; or use 0x63740101..0x6374FFFF </pre><a href="#section-3.2-8" class="pilcrow">¶</a> </div> <aside id="section-3.2-9"> <p id="section-3.2-9.1">Notes:<a href="#section-3.2-9.1" class="pilcrow">¶</a></p> <ol start="1" type="1" class="normal type-1" id="section-3.2-9.2"> <li id="section-3.2-9.2.1"> <p id="section-3.2-9.2.1.1">This syntax reuses the angle bracket syntax for generics; this reuse is innocuous because a generic parameter or argument only ever occurs after a rule name (<code>id</code>), while it occurs after the "<code>.</code>" (dot) character here. (Whether there is potential for human confusion can be debated; the above example deliberately uses generics as well.)<a href="#section-3.2-9.2.1.1" class="pilcrow">¶</a></p> </li> <li id="section-3.2-9.2.2"> <p id="section-3.2-9.2.2.1">The updated ABNF grammar makes it a bit more explicit that the number given after the optional dot is the value of the argument: for tags and simple values, it is not giving the CBOR "additional information”, as it is with other uses of <code>#</code> in CDDL. (Adding this observation to <span><a href="https://rfc-editor.org/rfc/rfc8610#section-2.2.3" class="relref">Section 2.2.3</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> is the subject of <span>[<a href="#Err6575" class="cite xref">Err6575</a>]</span>; it is correctly noted in <span><a href="https://rfc-editor.org/rfc/rfc8610#section-3.6" class="relref">Section 3.6</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>.) In hindsight, maybe a different character than the dot should have been chosen for this special case; however, changing the grammar in the current document would have been too disruptive.<a href="#section-3.2-9.2.2.1" class="pilcrow">¶</a></p> </li> </ol> </aside> </section> </div> </section> </div> <div id="security-considerations"> <section id="section-4"> <h2 id="name-security-considerations"> <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a> </h2> <p id="section-4-1">The grammar fixes and updates in this document are not believed to create additional security considerations. The security considerations in <span><a href="https://rfc-editor.org/rfc/rfc8610#section-5" class="relref">Section 5</a> of [<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> apply. Specifically, the potential for confusion is increased in an environment that uses a combination of CDDL tools, some of which have been updated and some of which have not, in particular based on <a href="#clari" class="auto internal xref">Section 2</a>.<a href="#section-4-1" class="pilcrow">¶</a></p> <p id="section-4-2">Attackers may want to exploit such potential confusion by crafting CDDL models that are interpreted differently by different parts of a system. There will be a period of transition from the details that the grammar in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> handled in a less well-defined way, to the updated grammar defined in the present document. This transition might offer one (but not the only) type of opportunity for the kind of attack that relies on differences between implementations. Implementations that make use of CDDL models operationally already need to ascertain the provenance (and thus authenticity and integrity) and applicability of models they employ. At the time of writing, it is expected that the models will generally be processed by a software developer, within a software development environment. Therefore, developers are advised to treat CDDL models with the same care as any other source code.<a href="#section-4-2" class="pilcrow">¶</a></p> </section> </div> <div id="iana-considerations"> <section id="section-5"> <h2 id="name-iana-considerations"> <a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a> </h2> <p id="section-5-1">This document has no IANA actions.<a href="#section-5-1" class="pilcrow">¶</a></p> </section> </div> <section id="section-6"> <h2 id="name-references"> <a href="#section-6" class="section-number selfRef">6. </a><a href="#name-references" class="section-name selfRef">References</a> </h2> <div id="sec-normative-references"> <section id="section-6.1"> <h3 id="name-normative-references"> <a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a> </h3> <dl class="references"> <dt id="RFC8610">[RFC8610]</dt> <dd> <span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Vigano, C.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"</span>, <span class="seriesInfo">RFC 8610</span>, <span class="seriesInfo">DOI 10.17487/RFC8610</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8610">https://www.rfc-editor.org/info/rfc8610</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="STD68">[STD68]</dt> <dd> <div class="refInstance">Internet Standard 68, <span>&lt;<a href="https://www.rfc-editor.org/info/std68">https://www.rfc-editor.org/info/std68</a>&gt;</span>.<br><span>At the time of writing, this STD comprises the following:</span> </div> <div class="refInstance" id="RFC5234"> <span class="refAuthor">Crocker, D., Ed.</span> and <span class="refAuthor">P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </div> </dd> <dd class="break"></dd> <dt id="STD94">[STD94]</dt> <dd> <div class="refInstance">Internet Standard 94, <span>&lt;<a href="https://www.rfc-editor.org/info/std94">https://www.rfc-editor.org/info/std94</a>&gt;</span>.<br><span>At the time of writing, this STD comprises the following:</span> </div> <div class="refInstance" id="RFC8949"> <span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </div> </dd> <dd class="break"></dd> </dl> </section> </div> <div id="sec-informative-references"> <section id="section-6.2"> <h3 id="name-informative-references"> <a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a> </h3> <dl class="references"> <dt id="I-D.ietf-cbor-cddl-modules">[CDDL-MODULES]</dt> <dd> <span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">B. Moran</span>, <span class="refTitle">"CDDL Module Structure"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-cbor-cddl-modules-03</span>, <time datetime="2024-09-01" class="refDate">1 September 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-modules-03">https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-modules-03</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="I-D.ietf-cbor-edn-literals">[EDN-LITERALS]</dt> <dd> <span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"CBOR Extended Diagnostic Notation (EDN)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-cbor-edn-literals-13</span>, <time datetime="2024-11-03" class="refDate">3 November 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-cbor-edn-literals-13">https://datatracker.ietf.org/doc/html/draft-ietf-cbor-edn-literals-13</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="Err6278">[Err6278]</dt> <dd> <span class="refAuthor">RFC Errata</span>, <span class="refTitle">Erratum ID 6278</span>, <span class="refContent">RFC 8610</span>, <span>&lt;<a href="https://www.rfc-editor.org/errata/eid6278">https://www.rfc-editor.org/errata/eid6278</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="Err6526">[Err6526]</dt> <dd> <span class="refAuthor">RFC Errata</span>, <span class="refTitle">Erratum ID 6526</span>, <span class="refContent">RFC 8610</span>, <span>&lt;<a href="https://www.rfc-editor.org/errata/eid6526">https://www.rfc-editor.org/errata/eid6526</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="Err6527">[Err6527]</dt> <dd> <span class="refAuthor">RFC Errata</span>, <span class="refTitle">Erratum ID 6527</span>, <span class="refContent">RFC 8610</span>, <span>&lt;<a href="https://www.rfc-editor.org/errata/eid6527">https://www.rfc-editor.org/errata/eid6527</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="Err6543">[Err6543]</dt> <dd> <span class="refAuthor">RFC Errata</span>, <span class="refTitle">Erratum ID 6543</span>, <span class="refContent">RFC 8610</span>, <span>&lt;<a href="https://www.rfc-editor.org/errata/eid6543">https://www.rfc-editor.org/errata/eid6543</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="Err6575">[Err6575]</dt> <dd> <span class="refAuthor">RFC Errata</span>, <span class="refTitle">Erratum ID 6575</span>, <span class="refContent">RFC 8610</span>, <span>&lt;<a href="https://www.rfc-editor.org/errata/eid6575">https://www.rfc-editor.org/errata/eid6575</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="RFC7405">[RFC7405]</dt> <dd> <span class="refAuthor">Kyzivat, P.</span>, <span class="refTitle">"Case-Sensitive String Support in ABNF"</span>, <span class="seriesInfo">RFC 7405</span>, <span class="seriesInfo">DOI 10.17487/RFC7405</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7405">https://www.rfc-editor.org/info/rfc7405</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="RFC9165">[RFC9165]</dt> <dd> <span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"Additional Control Operators for the Concise Data Definition Language (CDDL)"</span>, <span class="seriesInfo">RFC 9165</span>, <span class="seriesInfo">DOI 10.17487/RFC9165</span>, <time datetime="2021-12" class="refDate">December 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9165">https://www.rfc-editor.org/info/rfc9165</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="RFC9277">[RFC9277]</dt> <dd> <span class="refAuthor">Richardson, M.</span> and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"On Stable Storage for Items in Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">RFC 9277</span>, <span class="seriesInfo">DOI 10.17487/RFC9277</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9277">https://www.rfc-editor.org/info/rfc9277</a>&gt;</span>. </dd> <dd class="break"></dd> <dt id="STD80">[STD80]</dt> <dd> <div class="refInstance">Internet Standard 80, <span>&lt;<a href="https://www.rfc-editor.org/info/std80">https://www.rfc-editor.org/info/std80</a>&gt;</span>.<br><span>At the time of writing, this STD comprises the following:</span> </div> <div class="refInstance" id="RFC0020"> <span class="refAuthor">Cerf, V.</span>, <span class="refTitle">"ASCII format for network interchange"</span>, <span class="seriesInfo">STD 80</span>, <span class="seriesInfo">RFC 20</span>, <span class="seriesInfo">DOI 10.17487/RFC0020</span>, <time datetime="1969-10" class="refDate">October 1969</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc20">https://www.rfc-editor.org/info/rfc20</a>&gt;</span>. </div> </dd> <dd class="break"></dd> <dt id="UNICODE">[UNICODE]</dt> <dd> <span class="refAuthor">The Unicode Consortium</span>, <span class="refTitle">"The Unicode Standard"</span>, <span>&lt;<a href="https://www.unicode.org/versions/latest/">https://www.unicode.org/versions/latest/</a>&gt;</span>. </dd> <dd class="break"></dd> </dl> </section> </div> </section> <div id="collected-abnf-appendix"> <section id="appendix-A"> <h2 id="name-updated-collected-abnf-for-"> <a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-updated-collected-abnf-for-" class="section-name selfRef">Updated Collected ABNF for CDDL</a> </h2> <p id="appendix-A-1">This appendix is normative.<a href="#appendix-A-1" class="pilcrow">¶</a></p> <p id="appendix-A-2">It provides the full ABNF from <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> as updated by the present document.<a href="#appendix-A-2" class="pilcrow">¶</a></p> <span id="name-abnf-for-cddl-as-updated"></span><div id="collected-abnf"> <figure id="figure-11"> <div class="breakable lang-abnf sourcecode" id="appendix-A-3.1"> <pre> cddl = S *(rule S) rule = typename [genericparm] S assignt S type / groupname [genericparm] S assigng S grpent typename = id groupname = id assignt = "=" / "/=" assigng = "=" / "//=" genericparm = "&lt;" S id S *("," S id S ) "&gt;" genericarg = "&lt;" S type1 S *("," S type1 S ) "&gt;" type = type1 *(S "/" S type1) type1 = type2 [S (rangeop / ctlop) S type2] ; space may be needed before the operator if type2 ends in a name type2 = value / typename [genericarg] / "(" S type S ")" / "{" S group S "}" / "[" S group S "]" / "~" S typename [genericarg] / "&amp;" S "(" S group S ")" / "&amp;" S groupname [genericarg] / "#" "6" ["." head-number] "(" S type S ")" / "#" "7" ["." head-number] / "#" DIGIT ["." uint] ; major/ai / "#" ; any head-number = uint / ("&lt;" type "&gt;") rangeop = "..." / ".." ctlop = "." id group = grpchoice *(S "//" S grpchoice) grpchoice = *(grpent optcom) grpent = [occur S] [memberkey S] type / [occur S] groupname [genericarg] ; preempted by above / [occur S] "(" S group S ")" memberkey = type1 S ["^" S] "=&gt;" / bareword S ":" / value S ":" bareword = id optcom = S ["," S] occur = [uint] "*" [uint] / "+" / "?" uint = DIGIT1 *DIGIT / "0x" 1*HEXDIG / "0b" 1*BINDIG / "0" value = number / text / bytes int = ["-"] uint ; This is a float if it has fraction or exponent; int otherwise number = hexfloat / (int ["." fraction] ["e" exponent ]) hexfloat = ["-"] "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent fraction = 1*DIGIT exponent = ["+"/"-"] 1*DIGIT text = %x22 *SCHAR %x22 SCHAR = %x20-21 / %x23-5B / %x5D-7E / NONASCII / SESC SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\ %x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t (%x75 hexchar) ) ; \uXXXX hexchar = "{" (1*"0" [ hexscalar ] / hexscalar) "}" / 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 hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG / non-surrogate / 1*3HEXDIG bytes = [bsqual] %x27 *BCHAR %x27 BCHAR = %x20-26 / %x28-5B / %x5D-7E / NONASCII / SESC / "\'" / CRLF bsqual = "h" / "b64" id = EALPHA *(*("-" / ".") (EALPHA / DIGIT)) ALPHA = %x41-5A / %x61-7A EALPHA = ALPHA / "@" / "_" / "$" DIGIT = %x30-39 DIGIT1 = %x31-39 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEXDIG1 = DIGIT1 / "A" / "B" / "C" / "D" / "E" / "F" BINDIG = %x30-31 S = *WS WS = SP / NL SP = %x20 NL = COMMENT / CRLF COMMENT = ";" *PCHAR CRLF PCHAR = %x20-7E / NONASCII NONASCII = %xA0-D7FF / %xE000-10FFFD CRLF = %x0A / %x0D.0A </pre> </div> <figcaption><a href="#figure-11" class="selfRef">Figure 11</a>: <a href="#name-abnf-for-cddl-as-updated" class="selfRef">ABNF for CDDL as Updated</a> </figcaption></figure> </div> </section> </div> <div id="Err6543-covered"> <section id="appendix-B"> <h2 id="name-details-about-covering-erra"> <a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-details-about-covering-erra" class="section-name selfRef">Details about Covering Erratum ID 6543</a> </h2> <p id="appendix-B-1">This appendix is informative.<a href="#appendix-B-1" class="pilcrow">¶</a></p> <p id="appendix-B-2"><span>[<a href="#Err6543" class="cite xref">Err6543</a>]</span> notes that the ABNF used in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> 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 rule in <a href="#e6527-new2" class="auto internal xref">Figure 4</a>):<a href="#appendix-B-2" class="pilcrow">¶</a></p> <span id="name-original-abnf-from-rfc-8610-f"></span><div id="e6527-orig2a"> <figure id="figure-12"> <div class="lang-abnf sourcecode" id="appendix-B-3.1"> <pre> ; ABNF from RFC 8610: bytes = [bsqual] %x27 *BCHAR %x27 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF </pre> </div> <figcaption><a href="#figure-12" class="selfRef">Figure 12</a>: <a href="#name-original-abnf-from-rfc-8610-f" class="selfRef">Original ABNF from RFC 8610 for BCHAR</a> </figcaption></figure> </div> <div id="change-proposed-by-errata-report-6543"> <section id="appendix-B.1"> <h3 id="name-change-proposed-by-erratum-"> <a href="#appendix-B.1" class="section-number selfRef">B.1. </a><a href="#name-change-proposed-by-erratum-" class="section-name selfRef">Change Proposed by Erratum ID 6543</a> </h3> <p id="appendix-B.1-1">Erratum ID 6543 proposes handling the two cases in separate ABNF rules (where, with an updated SESC, BCHAR obviously needs to be updated as above):<a href="#appendix-B.1-1" class="pilcrow">¶</a></p> <span id="name-proposal-from-erratum-id-65"></span><div id="e6543-1"> <figure id="figure-13"> <div class="lang-abnf sourcecode" id="appendix-B.1-2.1"> <pre> ; Proposal from Erratum ID 6543: bytes = %x27 *BCHAR %x27 / bsqual %x27 *QCHAR %x27 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS </pre> </div> <figcaption><a href="#figure-13" class="selfRef">Figure 13</a>: <a href="#name-proposal-from-erratum-id-65" class="selfRef">Proposal from Erratum ID 6543 to Split the Byte String Rules</a> </figcaption></figure> </div> <p id="appendix-B.1-3">This potentially causes a subtle change, which is hidden in the WS rule:<a href="#appendix-B.1-3" class="pilcrow">¶</a></p> <span id="name-abnf-definition-of-ws-from-"></span><div id="e6543-2"> <figure id="figure-14"> <div class="lang-abnf sourcecode" id="appendix-B.1-4.1"> <pre> ; ABNF from RFC 8610: WS = SP / NL SP = %x20 NL = COMMENT / CRLF COMMENT = ";" *PCHAR CRLF PCHAR = %x20-7E / %x80-10FFFD CRLF = %x0A / %x0D.0A </pre> </div> <figcaption><a href="#figure-14" class="selfRef">Figure 14</a>: <a href="#name-abnf-definition-of-ws-from-" class="selfRef">ABNF Definition of WS from RFC 8610</a> </figcaption></figure> </div> <p id="appendix-B.1-5">This allows any non-C0 character in a comment, so this fragment becomes possible:<a href="#appendix-B.1-5" class="pilcrow">¶</a></p> <div class="lang-cddl sourcecode" id="appendix-B.1-6"> <pre> foo = h' 43424F52 ; 'CBOR' 0A ; LF, but don't use CR! ' </pre><a href="#appendix-B.1-6" class="pilcrow">¶</a> </div> <p id="appendix-B.1-7">The current text is not unambiguously saying whether the three apostrophes need to be escaped with a <code>\</code> or not, as in:<a href="#appendix-B.1-7" class="pilcrow">¶</a></p> <div class="lang-cddl sourcecode" id="appendix-B.1-8"> <pre> foo = h' 43424F52 ; \'CBOR\' 0A ; LF, but don\'t use CR! ' </pre><a href="#appendix-B.1-8" class="pilcrow">¶</a> </div> <p id="appendix-B.1-9">... which would be supported by the existing ABNF in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>.<a href="#appendix-B.1-9" class="pilcrow">¶</a></p> </section> </div> <div id="no-further-change-needed-after-updating-string-literal-grammar-e6527"> <section id="appendix-B.2"> <h3 id="name-no-further-change-needed-af"> <a href="#appendix-B.2" class="section-number selfRef">B.2. </a><a href="#name-no-further-change-needed-af" class="section-name selfRef">No Further Change Needed after Updating String Literal Grammar</a> </h3> <p id="appendix-B.2-1">This document takes the simpler approach of leaving the processing of the content of the byte string literal to a semantic step after processing the syntax of the <code>bytes</code> and <code>BCHAR</code> rules, as updated by Figures <a href="#e6527-new1" class="auto internal xref">2</a> and <a href="#e6527-new2" class="auto internal xref">4</a> in <a href="#e6527" class="auto internal xref">Section 2.1</a> (updates prompted by the combination of <span>[<a href="#Err6527" class="cite xref">Err6527</a>]</span> and <span>[<a href="#Err6278" class="cite xref">Err6278</a>]</span>).<a href="#appendix-B.2-1" class="pilcrow">¶</a></p> <p id="appendix-B.2-2">Therefore, the rules in <a href="#e6543-2" class="auto internal xref">Figure 14</a> (as updated by <a href="#e6527-new2" class="auto internal xref">Figure 4</a>) are applied to the result of this processing where <code>bsqual</code> is given as <code>h</code> or <code>b64</code>.<a href="#appendix-B.2-2" class="pilcrow">¶</a></p> <p id="appendix-B.2-3">Note that this approach also works well with the use of byte strings in <span><a href="https://rfc-editor.org/rfc/rfc9165#section-3" class="relref">Section 3</a> of [<a href="#RFC9165" class="cite xref">RFC9165</a>]</span>. It does require some care when copying-and-pasting into CDDL models from ABNF that contains single quotes (which may also hide as apostrophes in comments); these need to be escaped or possibly replaced by <code>%x27</code>.<a href="#appendix-B.2-3" class="pilcrow">¶</a></p> <p id="appendix-B.2-4">Finally, the approach taken lends support to extending <code>bsqual</code> in CDDL similar to the way this is done for CBOR diagnostic notation in <span>[<a href="#I-D.ietf-cbor-edn-literals" class="cite xref">EDN-LITERALS</a>]</span>. (Note that, at the time of writing, the processing of string literals is quite similar for both CDDL and Extended Diagnostic Notation (EDN), except that CDDL has end-of-line comments that are "<code>;</code>" based and EDN has two comment syntaxes: one in-line "<code>/</code>" based and one end-of-line "<code>#</code>" based.)<a href="#appendix-B.2-4" class="pilcrow">¶</a></p> </section> </div> </section> </div> <div id="acknowledgments"> <section id="appendix-C"> <h2 id="name-acknowledgments"> <a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a> </h2> <p id="appendix-C-1">Many thanks go to the submitters of the errata reports addressed in this document. In one of the ensuing discussions, <span class="contact-name">Doug Ewell</span> proposed defining an ABNF rule "NONASCII", of which we have included the essence. Special thanks to the reviewers <span class="contact-name">Marco Tiloca</span>, <span class="contact-name">Christian Amsüss</span> (Shepherd Review and further guidance), <span class="contact-name">Orie Steele</span> (AD Review and further guidance), and <span class="contact-name">Éric Vyncke</span> (detailed IESG review).<a href="#appendix-C-1" class="pilcrow">¶</a></p> </section> </div> <div id="authors-addresses"> <section id="appendix-D"> <h2 id="name-authors-address"> <a href="#name-authors-address" class="section-name selfRef">Author's Address</a> </h2> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">Carsten Bormann</span></div> <div dir="auto" class="left"><span class="org">Universität Bremen TZI</span></div> <div dir="auto" class="left"><span class="street-address">Postfach 330440</span></div> <div dir="auto" class="left"> <span class="postal-code">D-28359</span> <span class="locality">Bremen</span> </div> <div dir="auto" class="left"><span class="country-name">Germany</span></div> <div class="tel"> <span>Phone:</span> <a href="tel:+49-421-218-63921" class="tel">+49-421-218-63921</a> </div> <div class="email"> <span>Email:</span> <a href="mailto:cabo@tzi.org" class="email">cabo@tzi.org</a> </div> </address> </section> </div> <script>const toc = document.getElementById("toc"); toc.querySelector("h2").addEventListener("click", e => { toc.classList.toggle("active"); }); toc.querySelector("nav").addEventListener("click", e => { toc.classList.remove("active"); }); </script> </body> </html>

Pages: 1 2 3 4 5 6 7 8 9 10