<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!-- draft submitted in xml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-cbor-update-8610-grammar-06" number="9682" category="std" consensus="true" submissionType="IETF" updates="8610" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.21.0 -->version="3" xml:lang="en"> <front> <title abbrev="CDDL grammar updates">Updates to the Concise Data Definition Language (CDDL) Grammar of RFC 8610</title> <!-- [rfced] Please note that the title of the document has been updated as follows: -Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: Updates to the CDDL grammar of RFC8610</title>8610 Current: Updates to the Concise Data Definition Language (CDDL) Grammar of RFC 8610 Is it necessary to specify the RFC number in the title? Perhaps the title could be updated as follows: Updates to the Concise Data Definition Language (CDDL) Grammar --> <seriesInfoname="Internet-Draft" value="draft-ietf-cbor-update-8610-grammar-06"/>name="RFC" value="9682"/> <author initials="C." surname="Bormann" fullname="Carsten Bormann"> <organization>Universität Bremen TZI</organization> <address> <postal> <street>Postfach 330440</street> <city>Bremen</city> <code>D-28359</code> <country>Germany</country> </postal> <phone>+49-421-218-63921</phone> <email>cabo@tzi.org</email> </address> </author> <date year="2024"month="June" day="24"/>month="October"/> <area>ART</area><workgroup>CBOR</workgroup><workgroup>cbor</workgroup> <keyword>Concise Data Definition Language</keyword> <abstract><?line 82?><t>The Concise Data Definition Language (CDDL), as defined inRFC 8610RFCs 8610 andRFC 9165,9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented inCBORConcise Binary Object Representation (CBOR) or JSON.</t><t>The present<t>This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined forCDDL there.</t>CDDL.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> The latest revision of this draft can be found at <eref target="https://cbor-wg.github.io/update-8610-grammar/"/>. Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-cbor-update-8610-grammar/"/>. </t> <t> Discussion of this document takes place on the CBOR Working Group mailing list (<eref target="mailto:cbor@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cbor/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cbor/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/cbor-wg/update-8610-grammar"/>.</t> </note></front> <middle><?line 93?><section anchor="introduction"> <name>Introduction</name> <t>The Concise Data Definition Language (CDDL), as defined in <xref target="RFC8610"/> and <xref target="RFC9165"/>, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in CBOR or JSON.</t><t>The present<t>This document updates <xref target="RFC8610"/> by addressing errata and making other small fixes for the ABNF grammar defined forCDDL there.CDDL. The body of this documentmotivates andexplains and shows motivation for the updates; the updated collected ABNF syntax in <xref target="collected-abnf"/> in <xref target="collected-abnf-appendix"/> replaces the collected ABNF syntax in <xref section="B" sectionFormat="of" target="RFC8610"/>.</t> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>TheTerminologyterminology from <xref target="RFC8610"/> applies. The grammar in <xref target="RFC8610"/> is based on ABNF, which is defined in <xref target="STD68"/> and <xref target="RFC7405"/>.</t> </section> </section> <section anchor="clari"> <name>Clarifications and ChangesbasedBased on Errata Reports</name> <!--[rfced] We had the following questions about text in Section 2: a) In the following text, are the errata reports mentioned just a few examples of the many reports (we see 5 total errata reports for RFC 8610)? We believe the intention is to say that these two reports address the text and byte string syntax issues. Is that correct? Because the subsections that follow also address other errata reports, perhaps updating this text for the ease of the reader would be desirable. Original: A number of errata reports have been made around some details of text string and byte string literal syntax: [Err6527] and [Err6543]. Perhaps (if these are two of several): A number of errata reports have been made regarding some details of text string and byte string literal syntax: for example, [Err6527] and [Err6543]. Or perhaps (blending with the sentence that follows): At the time of writing, errata reports have been made about some details of text string and byte string literal syntax. This section discusses [Err6527] and [Err6543] (among others) and updates details of the ABNF for these literal syntaxes. b) The following text implies that the changes in Errata Report 6526 have not been included in this document. Is that accurate? If so, is there a reason not to apply the fix? Should the reader be made aware of it? In addition, perhaps "backslashes were mistakenly lost in some text explaining backslash escaping during the RFC publication process" would be more clear for the reader than "RFC processing"? Original: Also,[Err6526] needs to be applied (backslashes have been lost during RFC processing in some text explaining backslash escaping). --> <t>A number of errata reports have been made around some details of text string and byte string literal syntax: <xref target="Err6527"/> and <xref target="Err6543"/>. These are being addressed in this section, updating details of the ABNF for these literal syntaxes. Also, the changes described in <xref target="Err6526"/>needsneed to be applied (backslashes have been lost during RFC processing in some text explaining backslash escaping).</t> <t>These changes are intended to mirror the way existing implementations have dealt with the errata.TheyThis document alsouseuses the opportunity presentedbyfor the necessary cleanup of the grammar of string literals for abackward compatiblebackward-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 in thisspecification recommends).</t>specification).</t> <section anchor="e6527"> <name>Updates to String Literal Grammar</name> <sectionnumbered="false"numbered="true" anchor="err6527-text-string-literals"><name>Err6527<name>Erratum ID 6527 (Text String Literals)</name> <!--Begin quoted Errata report EID 6527 https://www.rfc-editor.org/errata_search.php?eid=6527 (which further mentions this is from a CBOR mailing list).--> <t>The ABNF used in <xref target="RFC8610"/> for the content of text string literals is rather permissive:</t><figure anchor="e6527-orig1"> <name>Original<!--[rfced] Does this suggested rewrite of the title of Figure 1 capture your intent? Original: Figure 1: Original RFC 8610 ABNF for strings with permissive ABNF for SESC, but not allowing hexescapes</name>escapes Perhaps: Figure 1: Original RFC 8610 ABNF for Strings with Permissive ABNF for SESC (but That Do Not Allow Hex Escapes) --> <figure anchor="e6527-orig1"> <name>ABNF from RFC 8610 for Strings with Permissive ABNF for SESC, but Not Allowing Hex Escapes</name> <sourcecode type="abnf"><![CDATA[ ; ABNF from RFC8610 ABNF:8610: text = %x22 *SCHAR %x22 SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC SESC = "\" (%x20-7E / %x80-10FFFD) ]]></sourcecode> </figure> <!--[rfced] Please review the citation "Bullet 6 of Section 3.1 of [RFC8610]" as: a) we don't see a mention of backslash or non-C0 in Section 3.1, and b) there is bulleted list nesting, which makes this tough to be certain the reader thinks the same bullet is bullet 6. Original: 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 (which should be applying here according to Bullet 6 of Section 3.1 of [RFC8610]). --> <t>This allows almost any non-C0 character to be escaped by a backslash, but critically misses out on the <tt>\uXXXX</tt> and <tt>\uHHHH\uLLLL</tt> forms that JSON allows to specify characters in hex <!--end quoted material--> (which should beapplyingapplied here according to Bullet 6 of <xref section="3.1" sectionFormat="of" target="RFC8610"/>). <!-- [rfced] Please review whether any of the notes in this document should appear in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> (Note that CDDL imports from JSON the unwieldy <tt>\uHHHH\uLLLL</tt> syntax, which represents Unicode code points beyond U+FFFF by making them look like UTF-16 surrogate pairs; CDDL text stringsaredo notusinguse UTF-16 or surrogates.)</t> <!--Begin quoted errata report--> <t>Both can be solved by updating the SESC rule. <!--End quoted errata report--> This document uses the opportunity to add a popular form of directly specifying characters in strings using hexadecimal escape sequences of the form <tt>\u{hex}</tt>, where <tt>hex</tt> is the hexadecimal representation of the Unicode scalar value. The result is the new set of rules defining SESC in <xreftarget="e6527-new1"/>:</t>target="e6527-new1"/>.</t> <figure anchor="e6527-new1"> <name>Update tostringString ABNF in Appendix B ofRFC 8610: allow hex escapes</name><xref target="RFC8610"/>: Allow Hex Escapes</name> <sourcecode type="abnf" name="cddl-new-sesc.abnf"><![CDATA[ ; 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" ]]></sourcecode> </figure> <t>(Notes: In ABNF, strings such as <tt>"A"</tt>,<tt>"B"</tt> etc.<tt>"B"</tt>, etc., arecase-insensitive,case insensitive, as is intended here. The rules abovecould, instead of <tt>%x62</tt>, alsocould have also used<tt>%s"b"</tt><tt>%s"b"</tt>, etc., instead of <tt>%x62</tt>, but didn't, in order to maximize compatibility of ABNFtool compatibility.)</t>tools.)</t> <t>Now that SESC is more restrictively formulated,this also requiresan update to the BCHAR rule used in the ABNF syntax for byte stringliterals:</t>literals is also required:</t> <figure anchor="e6527-orig2"><name>Original<name>ABNF from RFC 8610ABNFfor BCHAR</name> <sourcecode type="abnf"><![CDATA[ ; ABNF from RFC8610 ABNF:8610: bytes = [bsqual] %x27 *BCHAR %x27 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF bsqual = "h" / "b64" ]]></sourcecode> </figure> <!--[rfced] Please let us know what "this" refers to in the following text. Original: With the SESC updated as above, \' is no longer allowed in BCHAR; this now needs to be explicitly included; see below. --> <t>With the SESC updated as above, <tt>\'</tt> is no longer allowed in BCHAR; this now needs to be explicitly included; see below.</t> </section> <sectionnumbered="false"numbered="true" anchor="e6278"><name>Err6278<name>Erratum ID 6278 (Consistent String Literals)</name> <t>Updating BCHAR also provides an opportunity to address <xref target="Err6278"/>, 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 stringliteral, andliteral; therefore, it shouldthereforebe 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 reasoningthenalso applies to text in comments (PCHAR). <!--[rfced] For the ease of the reader, should the antecedent of "these" be clarified? Original: For completeness, all these should also explicitly exclude the code points that have been set aside for UTF-16's surrogates. --> For completeness, all these should also explicitly exclude the code points that have been set aside for UTF-16 surrogates.</t> <figure anchor="e6527-new2"> <name>Update to ABNF in Appendix B ofRFC 8610:<xref target="RFC8610"/>: BCHAR, SCHAR, and PCHAR</name> <sourcecode type="abnf" name="cddl-new-bchar.abnf"><![CDATA[ ; 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 ]]></sourcecode> </figure> <!--[rfced] Might it be helpful to the reader to include a citation/reference to "the Unicode standard" here? If so, please provide the desired reference entry (we assume it would be listed in the Informative References section). Original: ...doing this properly would draw in complexity from the ongoing evolution of the Unicode standard that is not needed here.) --> <t>(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 that is not needed here.)</t> </section> <sectionnumbered="false"numbered="true" anchor="addressing-err6526-err6543"> <name>AddressingErr6526, Err6543</name>Erratum ID 6526 and Erratum ID 6543</name> <t>The above changes also cover <xref target="Err6543"/> (a proposal to split off qualified byte string literals from UTF-8 byte string literals) and <xref target="Err6526"/> (lost backslashes); see <xref target="Err6543-covered"/> for details.</t> </section> </section> <section anchor="examples-demonstrating-the-updated-string-syntaxes"> <name>Examples Demonstrating the Updated String Syntaxes</name> <!-- [rfced] Section 2.2: While the use of <u> is not required, we added it upon first use for 🁳 and ⌘ as we believe it will be helpful to readers in this context. Original: Similarly, as shown in c and z there also is no need to escape the 🁳 or ⌘, but escaping them may be convenient in order to limit the character repertoire of a CDDL file itself to ASCII [STD80]. Current: Similarly, as shown in c and z, there also is no need to escape the "🁳" (DOMINO TILE VERTICAL-02-02, U+1F073) or "⌘" (PLACE OF INTEREST SIGN, U+2318); however, escaping them may be convenient in order to limit the character repertoire of a CDDL file itself to ASCII [STD80]. --> <t>The CDDL example in <xref target="string-examples"/> demonstrates various escaping techniques now available for (byte and text) strings in CDDL.ObviouslyObviously, in the literals for <tt>a</tt> and <tt>x</tt>, there is no need to escape the second character, an <tt>o</tt>, as <tt>\u{6f}</tt>; this is just for demonstration. Similarly, as shown in <tt>c</tt> and<tt>z</tt><tt>z</tt>, there also is no need to escape the<tt>🁳</tt><u>🁳</u> or<tt>⌘</tt>, but<u>⌘</u>; however, escaping them may be convenient in order to limit the character repertoire of a CDDL file itself to ASCII <xref target="STD80"/>.</t> <figure anchor="string-examples"> <name>ExampletextText andbyte string literalsByte String Literals withvarious escaping techniques</name>Various Escaping Techniques</name> <sourcecode type="cddl"><![CDATA[ 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 ]]></sourcecode> </figure> <t>In this example, the rules a to c and x to z all produce strings with byte-wise identicalcontent, wherecontent: a to c are textstrings,strings and x to z are byte strings. <xref target="string-examples-pretty"/> illustrates this by showing the output generated from the <tt>start</tt> rule in <xref target="string-examples"/>, using pretty-printed hexadecimal.</t> <figure anchor="string-examples-pretty"> <name>Generated CBOR from CDDLexampleExample (Pretty-Printed Hexadecimal)</name> <sourcecode type="cbor-pretty"><![CDATA[ 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 🁳 + ⌘" ]]></sourcecode> </figure> <!--[rfced] We note that some comments from authors remained in the submitted XML file. Please review each of these and confirm that they have been addressed as desired. The notes will be removed from the XML prior to publication of the RFC. --> <!-- cddl sourcecode/cddl/no-change-needed-after-addr.cddl g | diag2pretty.rb | diff - sourcecode/cbor-pretty/no-change-needed-after-addr.cbor-pretty --> </section> </section> <section anchor="small-enabling-grammar-changes"> <name>Small Enabling Grammar Changes</name><t>The two subsections in this section specify two<t>Each subsection that follows specifies a smallchangeschange to the grammar thatareis intended to enable certain kinds of specifications. These changes are backwardcompatible, i.e.,compatible (i.e., CDDL files that complytowith <xref target="RFC8610"/> continue to match the updatedgrammar,grammar) but not necessarily forwardcompatible, i.e.,compatible (i.e., CDDL specifications that make use of these changes cannot necessarily be processed by existing implementations of <xreftarget="RFC8610"/> implementations.</t>target="RFC8610"/>).</t> <section anchor="empty"> <name>Emptydata models</name>Data Models</name> <t><xref target="RFC8610"/> requires a CDDL file to have at least one rule.</t> <figure anchor="empty-orig"><name>Original<name>ABNF from RFC 8610ABNFfortop-level ruleTop-Level Rule cddl</name> <sourcecode type="abnf"><![CDATA[ ; ABNF from RFC8610 ABNF:8610: cddl = S 1*(rule S) ]]></sourcecode> </figure> <t>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(start(i.e., a start rule).</t> <t>With CDDL modules <xref target="I-D.ietf-cbor-cddl-modules"/>, 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.</t> <t>Therefore, the present update extends the grammar as in <xref target="empty-new"/> and turns the existence of at least one rule into a semantic constraint, to be fulfilled after processing of all directives.</t> <figure anchor="empty-new"> <name>Update totop-levelTop-Level ABNF in Appendices B and C of RFC 8610</name> <sourcecode type="abnf" name="cddl-new-cddl.abnf"><![CDATA[ ; new top-level rule: cddl = S *(rule S) ]]></sourcecode> </figure> </section> <section anchor="tagnum"> <!--[rfced] How may we update the punctuation in the title of Section 3.2? Original: 3.2. Non-literal Tag Numbers, Simple Values Perhaps: 3.2. Non-literal Tag Numbers and Simple Values --> <name>Non-literal Tag Numbers, Simple Values</name> <t>The existing ABNF syntax for expressing tags in CDDLis:</t>is as follows:</t> <figure anchor="tag-orig"> <name>Original ABNF from RFC 8610ABNFfortag syntax</name>Tag Syntax</name> <sourcecode type="abnf"><![CDATA[ ; extracted from the ABNF in RFC8610 ABNF:8610: type2 =/ "#" "6" ["." uint] "(" S type S ")" ]]></sourcecode> </figure> <t>This means tag numbers can only be given as literal numbers (uints). Some specifications operate on ranges of tagnumbers, e.g.,numbers; for example, <xref target="RFC9277"/> has a range of tag numbers 1668546817 (0x63740101) to 1668612095 (0x6374FFFF) to tag specific content formats. This can currently not be expressed in CDDL. Similar considerations apply to simple values (<tt>#7.</tt>xx).</t> <t>This update extends the syntaxto:</t>to the following:</t> <figure anchor="tag-new"> <name>Update totagTag andsimple valueSimple Value ABNF in Appendices B and C of RFC 8610</name> <sourcecode type="abnf" name="cddl-new-tag.abnf"><![CDATA[ ; new rules collectively defining the tagged case: type2 =/ "#" "6" ["." head-number] "(" S type S ")" / "#" "7" ["." head-number] head-number = uint / ("<" type ">") ]]></sourcecode> </figure> <t>For <tt>#6</tt>, the <tt>head-number</tt> stands for the tag number. For <tt>#7</tt>, the <tt>head-number</tt> stands for the simple value if it is in the ranges 0..23 or 32..255 (as per Section <xref target="RFC8949" section="3.3" sectionFormat="bare"/> of RFC 8949 <xreftarget="STD94"/>target="STD94"/>, the simple values 24..31 are not used). For 24..31, the <tt>head-number</tt> stands for the "additional information", e.g., <tt>#7.25</tt> or <tt>#7.<25></tt> is a float16, etc. (All ranges mentioned here are inclusive.)</t> <t>So the above range can be expressed in a CDDL fragment such as:</t> <sourcecode type="cddl"><![CDATA[ ct-tag<content> = #6.<ct-tag-number>(content) ct-tag-number = 1668546817..1668612095 ; or use 0x63740101..0x6374FFFF ]]></sourcecode> <t>Notes:</t> <ol spacing="normal" type="1"><li> <!--[rfced] We had a few questions regarding the following text: Original: 1. This syntax reuses the angle bracket syntax for generics; this reuse is innocuous as a generic parameter/argument only ever occurs after a rule name (id), while it occurs after . here. a) Please clarify how "only ever occurs" relates to the text before it (perhaps "and" is missing)? b) Is "This syntax reuses...syntax" intentional? Please review. c) Should the "." character be written in text as well (i.e., "...while it occurs after the "." (dot) character here."? This is how it is referred to later in the text. d) Might this use of the slash character be clarified using "and", "or", or "and/or"? --> <t>This syntax reuses the angle bracket syntax for generics; this reuse is innocuous as a generic parameter/argument only ever occurs after a rule name (<tt>id</tt>), while it occurs after <tt>.</tt> here. (Whether there is potential for human confusion can be debated; the above example deliberately uses generics as well.)</t> </li> <li> <!--[rfced] In EID 6575, the suggested text uses "the value of the argument". Should similar language be used here? Original: 2. The updated ABNF grammar makes it a bit more explicit that the number given after the optional dot is special, not giving the CBOR "additional information" for tags and simple values as it is with other uses of # in CDDL. Perhaps: 2. The updated ABNF grammar makes it a bit more explicit that the number given after the optional dot is the value of the argument: it is not giving the CBOR "additional information" for tags and simple values, as it is with other uses of # in CDDL. --> <t>The updated ABNF grammar makes it a bit more explicit that the number given after the optional dot is special, not giving the CBOR "additional information" for tags and simple values as it is with other uses of <tt>#</tt> in CDDL. (Adding this observation to <xref section="2.2.3" sectionFormat="of" target="RFC8610"/> is the subject of <xref target="Err6575"/>; it is correctly noted in <xref section="3.6" sectionFormat="of" target="RFC8610"/>.) In hindsight, maybe a different character than the dot should have been chosen for this specialcase, howevercase; however, changing the grammarnowin the current document would have been too disruptive.</t> </li> </ol> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>The grammar fixes and updates in this document are not believed to create additional security considerations. The security considerations in <xref section="5" sectionFormat="of" target="RFC8610"/>do apply, and specificallyapply. Specifically, the potential for confusion is increased in an environment that uses a combination of CDDLtoolstools, some of which have been updated and some of which havenot been,not, in particular based on <xref target="clari"/>.</t> <t>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 <xref target="RFC8610"/>grammarhandled in aless well-definedless-well-defined way, to the updated grammar defined in the present document. <!--[rfced] Does this rephrase capture your intended meaning? Original: This transition might offer one, but not the only kind of opportunity for the kind of attack that relies on differences between implementations. Perhaps: This transition might offer one (but not the only) type of opportunity for the kind of attack that relies on differences between implementations. --> This transition might offer one, but not the only kind 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 asoftware developmentsoftware-development environment.DevelopersTherefore, developers arethereforeadvised to treat CDDL models with the same care as any other source code.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-cbor-cddl-modules" to="CDDL-MODULES"/> <displayreference target="I-D.ietf-cbor-edn-literals" to="EDN-LITERALS"/> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/> <author fullname="C. Vigano" initials="C." surname="Vigano"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2019"/> <abstract> <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t> </abstract> </front> <seriesInfo name="RFC" value="8610"/> <seriesInfo name="DOI" value="10.17487/RFC8610"/> </reference> <referencegroup anchor="STD68" target="https://www.rfc-editor.org/info/std68"> <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234"> <front> <title>Augmented BNF for Syntax Specifications: ABNF</title> <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/> <author fullname="P. Overell" initials="P." surname="Overell"/> <date month="January" year="2008"/> <abstract> <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="68"/> <seriesInfo name="RFC" value="5234"/> <seriesInfo name="DOI" value="10.17487/RFC5234"/> </reference> </referencegroup> <referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94"> <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949"> <front> <title>Concise Binary Object Representation (CBOR)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="December" year="2020"/> <abstract> <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> </referencegroup><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0068.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0094.xml" /> </references> <references anchor="sec-informative-references"> <name>Informative References</name><referencegroup anchor="STD80" target="https://www.rfc-editor.org/info/std80"> <reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc20"> <front> <title>ASCII format for network interchange</title> <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/> <date month="October" year="1969"/> </front> <seriesInfo name="STD" value="80"/> <seriesInfo name="RFC" value="20"/> <seriesInfo name="DOI" value="10.17487/RFC0020"/> </reference> </referencegroup> <reference anchor="RFC7405"> <front> <title>Case-Sensitive String Support in ABNF</title> <author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/> <date month="December" year="2014"/> <abstract> <t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t> </abstract> </front> <seriesInfo name="RFC" value="7405"/> <seriesInfo name="DOI" value="10.17487/RFC7405"/> </reference> <reference anchor="RFC9165"> <front> <title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="December" year="2021"/> <abstract> <t>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators"<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0080.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9165.xml"/> <!-- [I-D.ietf-cbor-cddl-modules];I-D exists asits main language extension point.</t> <t>The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:,, and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance.</t> </abstract> </front> <seriesInfo name="RFC" value="9165"/> <seriesInfo name="DOI" value="10.17487/RFC9165"/> </reference> <reference anchor="I-D.ietf-cbor-cddl-modules"> <front> <title>CDDL Module Structure</title> <author fullname="Carsten Bormann" initials="C." surname="Bormann"> <organization>Universität Bremen TZI</organization> </author> <author fullname="Brendan Moran" initials="B." surname="Moran"> <organization>Arm Limited</organization> </author> <date day="4" month="March" year="2024"/> <abstract> <t> At the timeofwriting, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-cddl-modules-02"/> </reference> <reference anchor="I-D.ietf-cbor-edn-literals"> <front> <title>CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals, ABNF, and Media Type</title> <author fullname="Carsten Bormann" initials="C." surname="Bormann"> <organization>Universität Bremen TZI</organization> </author> <date day="18" month="May" year="2024"/> <abstract> <t> The Concise Binary Object Representation, CBOR (STD 94, RFC 8949), defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. This document specifies how to add application-oriented extensions to the diagnostic notation. It then defines two such extensions9/5/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cbor-cddl-modules.xml"/> <!-- [I-D.ietf-cbor-edn-literals];Waiting fortext representations of epoch-based date/times andAD go-ahead as ofIP addresses and prefixes (RFC 9164). A few further additions close some gaps in usability. To facilitate tool interoperation, this document specifies a formal ABNF definition for extended diagnostic notation (EDN) that accommodates application- oriented literals. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-edn-literals-09"/> </reference>9/5/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cbor-edn-literals.xml"/> <reference anchor="Err6278"target="https://www.rfc-editor.org/errata/eid6278">target="https://www.rfc-editor.org/errata/eid6278" quote-title="false"> <front><title>Errata Report<title>Erratum ID 6278</title> <author><organization/><organization>RFC Errata</organization> </author><date/></front><seriesInfo name="RFC" value="8610"/><refcontent>RFC 8610</refcontent> </reference> <reference anchor="Err6526"target="https://www.rfc-editor.org/errata/eid6526">target="https://www.rfc-editor.org/errata/eid6526" quote-title="false"> <front><title>Errata Report<title>Erratum ID 6526</title> <author><organization/><organization>RFC Errata</organization> </author><date/></front><seriesInfo name="RFC" value="8610"/><refcontent>RFC 8610</refcontent> </reference> <reference anchor="Err6527"target="https://www.rfc-editor.org/errata/eid6527">target="https://www.rfc-editor.org/errata/eid6527" quote-title="false"> <front><title>Errata Report<title>Erratum ID 6527</title> <author><organization/><organization>RFC Errata</organization> </author> <date/> </front><seriesInfo name="RFC" value="8610"/><refcontent>RFC 8610</refcontent> </reference> <reference anchor="Err6543"target="https://www.rfc-editor.org/errata/eid6543">target="https://www.rfc-editor.org/errata/eid6543" quote-title="false"> <front><title>Errata Report<title>Erratum ID 6543</title> <author><organization/><organization>RFC Errata</organization> </author><date/></front><seriesInfo name="RFC" value="8610"/><refcontent>RFC 8610</refcontent> </reference> <reference anchor="Err6575"target="https://www.rfc-editor.org/errata/eid6575">target="https://www.rfc-editor.org/errata/eid6575" quote-title="false"> <front><title>Errata Report<title>Erratum ID 6575</title> <author><organization/><organization>RFC Errata</organization> </author><date/> </front> <seriesInfo name="RFC" value="8610"/> </reference> <reference anchor="RFC9277"> <front> <title>On Stable Storage for Items in Concise Binary Object Representation (CBOR)</title> <author fullname="M. Richardson" initials="M." surname="Richardson"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="August" year="2022"/> <abstract> <t>This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.</t> </abstract></front><seriesInfo name="RFC" value="9277"/> <seriesInfo name="DOI" value="10.17487/RFC9277"/><refcontent>RFC 8610</refcontent> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9277.xml"/> </references> </references><?line 440?><section anchor="collected-abnf-appendix"> <name>Updated Collected ABNF for CDDL</name> <t>This appendix is normative.</t> <t>It provides the full ABNF from <xref target="RFC8610"/>with the updates applied inas updated by the present document.</t> <figure anchor="collected-abnf"> <name>ABNF for CDDL asupdated</name>Updated</name> <sourcecode type="abnf" name="cddl-updated-complete.abnf"><![CDATA[ cddl = S *(rule S) rule = typename [genericparm] S assignt S type / groupname [genericparm] S assigng S grpent typename = id groupname = id assignt = "=" / "/=" assigng = "=" / "//=" genericparm = "<" S id S *("," S id S ) ">" genericarg = "<" S type1 S *("," S type1 S ) ">" 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] / "&" S "(" S group S ")" / "&" S groupname [genericarg] / "#" "6" ["." head-number] "(" S type S ")" / "#" "7" ["." head-number] / "#" DIGIT ["." uint] ; major/ai / "#" ; any head-number = uint / ("<" type ">") 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] "=>" / 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 ]]></sourcecode> </figure> </section> <section anchor="Err6543-covered"> <name>Details about CoveringErrata ReportErratum ID 6543</name> <t>This appendix is informative.</t> <t><xref target="Err6543"/>observesnotes that the ABNF used in <xref target="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 rule in <xref target="e6527-new2"/>):</t> <figure anchor="e6527-orig2a"> <name>Original ABNF from RFC 8610ABNFfor BCHAR</name> <sourcecode type="abnf"><![CDATA[ ; ABNF from RFC8610 ABNF:8610: bytes = [bsqual] %x27 *BCHAR %x27 BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF ]]></sourcecode> </figure> <sectionnumbered="false"numbered="true" anchor="change-proposed-by-errata-report-6543"> <name>Change ProposedBy Errata Reportby Erratum ID 6543</name><t>Errata report<t>Erratum ID 6543 proposesto handlehandling the two cases in separate ABNF rules (where, with an updated SESC, BCHAR obviously needs to be updated as above):</t> <figure anchor="e6543-1"><name>Errata Report 8653 Proposal<name>Proposal from Erratum ID 6543 to Split the Byte String Rules</name> <sourcecode type="abnf"><![CDATA[ ;Err6543 proposal: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 ]]></sourcecode> </figure> <t>This potentially causes a subtle change, which is hidden in the WS rule:</t> <figure anchor="e6543-2"> <name>ABNFdefinitionDefinition of WS from RFC 8610</name> <sourcecode type="abnf"><![CDATA[ ; ABNF from RFC8610 ABNF:8610: WS = SP / NL SP = %x20 NL = COMMENT / CRLF COMMENT = ";" *PCHAR CRLF PCHAR = %x20-7E / %x80-10FFFD CRLF = %x0A / %x0D.0A ]]></sourcecode> </figure> <t>This allows any non-C0 character in a comment, so this fragment becomes possible:</t> <sourcecode type="cddl"><![CDATA[ foo = h' 43424F52 ; 'CBOR' 0A ; LF, but don't use CR! ' ]]></sourcecode> <t>The current text is not unambiguously saying whether the three apostrophes need to be escaped with a <tt>\</tt> or not, as in:</t> <sourcecode type="cddl"><![CDATA[ foo = h' 43424F52 ; \'CBOR\' 0A ; LF, but don\'t use CR! ' ]]></sourcecode> <t>... which would be supported by the existing ABNF in <xref target="RFC8610"/>.</t> </section> <sectionnumbered="false"numbered="true" anchor="no-further-change-needed-after-updating-string-literal-grammar-e6527"> <name>No Further Change NeededAfterafter Updating String LiteralGrammar (<xref target="e6527"/>)</name>Grammar</name> <!--[rfced] Please review if replacing this slash with "and", "or", or "and/or" would be clearer for the reader. Original: 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 bytes/BCHAR rules... --> <t>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 <tt>bytes</tt>/<tt>BCHAR</tt> rules, as updated by Figures <xreftarget="e6527-new1"/>target="e6527-new1" format="counter"/> and <xreftarget="e6527-new2"/>target="e6527-new2" format="counter"/> in <xref target="e6527"/> (updates prompted by the combination of <xref target="Err6527"/> and <xref target="Err6278"/>).</t><t>The<t>Therefore, the rules in <xref target="e6543-2"/> (as updated by <xref target="e6527-new2"/>) arethereforeapplied to the result of this processing where <tt>bsqual</tt> is given as <tt>h</tt> or <tt>b64</tt>.</t> <t>Note that this approach also works well with the use of byte strings in <xref section="3" sectionFormat="of" target="RFC9165"/>. It does require some care whencopy-pastingcopying-and-pasting into CDDL models from ABNF thatcontainscontain single quotes (which may also hide as apostrophes in comments); these need to be escaped or possibly replaced by <tt>%x27</tt>.</t> <t>Finally, the approach taken lends support to extending <tt>bsqual</tt> in CDDL similar to the way this is done for CBOR diagnostic notation in <xref target="I-D.ietf-cbor-edn-literals"/>. (Notethatthat, at the time of writing, the processing of string literalsnowis quite similarbetweenfor both CDDL andEDN,Extended Diagnostic Notation (EDN), except that CDDL has"<tt>;</tt>"-basedend-of-linecomments, whilecomments that are "<tt>;</tt>" based and EDN has two commentsyntaxes,syntaxes: those that are in-line"<tt>/</tt>"-based"<tt>/</tt>" based and those that are end-of-line"<tt>#</tt>"-based.)</t>"<tt>#</tt>" based.)</t> </section> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Many thanks go to the submitters of the errata reports addressed in this document. In one of the ensuing discussions, <contact fullname="Doug Ewell"/> proposedto definedefining an ABNF ruleNONASCII,"NONASCII", of which we have included the essence. Special thanks to the reviewers <contact fullname="Marco Tiloca"/>, <contact fullname="Christian Amsüss"/>(shepherd review( Shepherd Review and further guidance), <contact fullname="Orie Steele"/> (ADreviewReview and further guidance), andÉric Vyncke<contact fullname="Éric Vyncke"/> (detailed IESG review).</t> </section></back><!--[rfced] A general note: throughout the document, we see several instances where "errata" is used in a sense that could use clarification/rewriting. For example: Original: These changes are intended to mirror the way existing implementations have dealt with the errata. Perhaps: These changes are intended to mirror the way existing implementations have dealt with the errors. --> <!-- [rfced] We expanded the following abbreviations. Please review and let us know any objections to how they've been expanded. CBOR - Concise Binary Object Representation EDN - Extended Diagnostic Notation --> <!--[rfced] The list of terms enclosed in <tt> in this document is in the file below: https://www.rfc-editor.org/authors/rfc9682-tt.txt a) Some of these terms appear both with and without <tt>. Please review to ensure the usage of <tt> is consistent and appears in all output files as desired. b) We note that sometimes quotes are included within the <tt> tags and sometimes they appear outside the <tt> tags. Should this be made consistent? c) Some of the items that appear in <tt> tags might be something we would expect a textual description of as well (i.e., the document uses "." and dot or a Unicode equivalent). Please review and let us know if/how updates should be made. --> <!--##markdown-source: H4sIAAAAAAAAA+0823IbyXXv/RXtYWwBWgxIgCRIUcv1UrzsMqWlZJHrdUVU gsFMAxhrMAPPhSBW4VblMVX5gLwlD/mDvOYp/pN8QT4h59ZzAUGuVrYrccUs iQSmb6dPn/s5Pa7rqpsDva1UHuaROdDOt/PAy02m80TnU6OPT05e6knqzWZe qpOxfnN2rPcHvS1HeaNRamCs0+hS8HBHqSDxY28GUwapN87d0ORj1x8lqctd XJzFlWFuhINyleWp8WYH+vz06kzJVAe0ntrQ+O1A+V5+oLM8UH4SZybOCuiQ p4VRHgw90EdvrtQiSd9P0qSYH+jjF6/eqPdmCY+CA6VdfZzEfpgZfeLlnj4x 4zAO8zCJ9UsvnhTexKgbExewjNb1GbSeeWF0oBH+L3En3SSdYJ8wnxYjwAFt bDHZXLM3B/rx9g70NM/n2cHmpnTv8vhumKwbuKmUV+TTJEVoXPivNSP02Euz 3MT6RZLOvDimFoDnQH8bhzcmzcL89/+W6xepmUGnq785pw6IWgMgvE6yfOz5 U729vbWzs0VtfpgvD2QAP0gCWOfE7e9v7z6TJ0Wcp9DrK4OLLunhfJrE0O+z nWfuTr/n9nv77mD7Wb9HjUZQ5o2SL/PvQ8KYUjHCnAOYuCkgJtwwdAqCCL5f Xp0M9g+0N4rH/O3ZDuNcqTAe10dC2z6M8zI/DHmivZ2tXR7q+l5m+OGz3gAe AqXkaRIhWOfuSbeiRFzWnSVBESGZyYd7vUwQu1GYm9SLoBd8A1pcP1FqXFkL Z6u+4YAiM+MiOsCPWudeOjE1ehA68JOZJY1NnHJzEb4PN7+lkS6ymYxmVuXn xKEA82maDvp7+weqPr9jF1gsFt107MNewjxJ8Sw2TZoCD2yaMMBxjqrNfEpN +o2ZJ2musZlJyKShyfAkeBVCsbAnfiMG1WNAkxGAdvuDTwIIxj0GEDR/MkB7 nwjQ3uMA7X0qQDvbnwbQzvajAO1sfypAe7ufBtDe7qMA7e3+ZICUcl0XWBpE l+fnSl2hPvoR+a1byA/tDogGHWCzCXQYK1jkP/8VF9FeHGj6hrKho+ZpchMG oO+8WBsvW1J7AXJ2FE6KpMj0wluiLjS389RkGYrRws8L+KxBIOHwPPGTSM+g EZbPaHyAwLG8AkU69XINykmnBqcwcU4gkWIBsa3++vLVRZc3J+0aVGcxww+i Akutq0cAYBAgJGE80Yx+WnLmvYcnKgGdneps5kWRHoe3DCUp8qMXF2ellraY wUZS3zjMdBnhsxBED2B/Q5+j9Apgv4DhPwj9Hz6QiLy7I1jxm4jku7s/lyOo tvAnPgOEYpQES7S28mmYVaDMElB/BAyuBuiIvDDOaGaB8jl+EcMpAL0XRcbH T7Rwtoxz7xb3/eFD2eSixoRN0SE1n7refG7iILyFZkBc5PmGF3toXpjhSIbo Fwi+YAxQu7GBpAO2FVILw19RT8aovwLLIoyTKJks9ThNZjWUAyQRiA1GjkUg bcT2ADyNQO0HGogRoeroxTQEKyes0yH25/0qocPSXmAo9XHkpeE4BCOzhPN4 CrRtatM3JBsQxoaPg+6UOtJxMRsZspOFLFLpNPVu4FQN2GMzLzBAi2BOBTpL ZgbAy8FQyui4zS3ZwEhXuPRomRst38UCEWwfAPCiz0qmEnWCOwE0ZYYofmRo MqZXRgIRVWaIqztMOdinDgcQER2tEC7M1Vwej+IoypJOCcYAwIiNCchxGBk5 sUC3Rp7/Pou8DGapYSECK1QHBe4MZTOwXeILQwGEhBdEhiVyfF5OpE3me3N4 1GaeBeh8OSPccQjcHQewNAAyC9NUeA+FiLkNM9prOJtHaOzmfM6KAAuMF+V6 AaYYDeAT7GoNSwDHw27RhqOmZI6nWgD1LnUpUBTIBWyMDe7ES5faj4wXF3PB aN2Lap4pCwhP4Q4XXoqMO5sDZKPI4MmxhBV/TJgNB0zNLdCSH4KgYZRYBgFv A+YVpCAHxAmIvyJP0H72QSwtcfzqSq2wa7odNiezOcxbsQHJT5BuhjBg5ZKA EiQ0v912CLOjA6YIkQ9hHOR7HkZCW3hqIrMs2+ICTSiAlQBYmCHI2ixQap7q JePzpRDpV4LpDxuGOAS7b1j7T7eukLKaQ7K2+nAAQDEDm+CORRIxQZFZ4SH+ CpC6leiox1A0C/OuHqwCNAEVoT6Yo3QDCkf/Rf3www/s5TyvVDuudaBolkP9 89t+Xz+9PP766A19VvyRGrbA0dKb+Gnb3X1Bn3ZP3L1T+rS/5fa2zs7OTuDb 5enlscJfMM65dnSLBq92bCM0uHtGlpuk4aTHVtyh8wq+hDGgtAEmbZ+3mjHD VLsrO9DKHT0qcqa/KEoWiBsgW0uuDqEZcESN+GeGcgHcSxgSu8dbSMNo+wH+ WKzwwIB0cCUROgpX8dPQkjfCApSRwFNkHTio4XXxG/gZkqyEL1/Dz3XxEn6G ZCZkiogcLQELDazIFLiswMiQEHAHLabTbJoUEYBjFAq8Je8PyNnz/SQN8CvM 8qIAfQk2MFLJhw+XLHn1drdX05FA062LJDfMa2QPAMuQ7iBdSICRpo8XoYnA PFjZBHNjRzFcpaGTYVAA3Xny6fU8CfHZyCwTwMO3nwEBnCEy2XTBBWYgm5P3 KgqB27+9OnN7A50VIEUnwGt67oUpGBlsrlT0zoIXT7kgES7jgAbKoVm3rdQL MI20D2YenGSWRDd8kKUGwu0Ruabgh3eZMio7LBProy58AbkgIIEU5sm8AC1M R4lYDUIQFzlQgpwg6pnmIVrIGeL7shQ05O8KE6PNI/Ib51aA9Q/Q+W6IkgpP egjfhihksUt9mvIIWHyJWrWnAWsgvDdeVIjNB50L0D8yU2wWAAEJFsSGWDEI KmGIxBHzK/QEM7opVHA0DxNbDRgTkNGY46AhGljibGpn08Hf1/h79ee5hsfX m/r6WjWe//x20CeZMhjwH5Ywe/xwbwf+wNCRvh7r61hfp/o6b04AgmlvF5GH R9TW7Xsr09rEwEp6IdwfAO7eU2fL0W9xsKD0HSxXfmtr5w62UlsOBUtF0Ju6 NQ0n09oT3DqBAzKgetxWzXGHutU6Of/q/AqRdQRIewH/jwl1p/DpzGnr7a9P fwNd2o3VZb/OCS6yveVu7+k+99NttQIJ7BC6tZx9mPAZ/Odl2naAagBY9j6G Xifw34Jhe1cIgp49wNmOrLup+UPPPqmBu3kPXb2nsi9lRx1qQkSPMYG/X9Bv xsaJ4AR/nzkrqgZJ12oa1uYkdFmHkh4BOm+6FFYPHbCUbmgTlSVF6hvkLxcj pYcOxeVgFReEh99F5kCVQ4I2O1Dn1lWwsiArQHSC5zqEjQCDD2EnQ21yv0vy Dd0EN6Sgc4gMRU4umCmlwVn5b8x73ii5QbkLGqIDO8ly4wW4hyEyDMxPNiWZ nmRiDH+eOSNZkPVmEAbxkxzHgiwNSAmqmXcbzsLvRc/mCTi+1ogLwexYopy9 AMSQHmFZkVEwEgUM7NPKApRmRcQ2V846GKBJQeiFKXmY4kZaw/MFGSC4sdIg Kl3amlFac1lUGTR9zODBARkQ0dtR9rvCi96hINrTT19Y02dPvWiYPixi+vs1 06dh8MCf4zcvzxRPh8Q+JeIbDXZWyQ8tnf5HWDoEABLOd9Y3oIWsm+3JSQPB XD8Zsr0N0gNs75SJlLFFszxXhOsYDqjuLaGbE/ohKqww9qMCqOk5iH90lmB8 t7Jf+3v7ugWedBZmZHeuWrFk8kKnO9hmw5r91ipZxiYddj3wcl+rUqyF3Tuc 8M6aFmJCYKcYobXA+EuiidTwOt9+trW1d6ZbJ6cv27CNfIFuH1uxYILxoYIT mdmO4qbMYT+5B/5IRzBBzkOOU3tr/WFgQA/VXDxmTe6JN7XOHu+Q9QezidlG EZdxQm6yAr1CiGd7S9CU0dpig10yzMjgGYgXYBYvS0ifEjolSFFmzno28VAz Hzsgo2oBG4mgQFtBdqvAwCYABkuQbcmLIwAEVbAAfnp2thYWGBrfBwiRAThk FwqOr/UaNwNW5xkgCwUIWKgmhiNHsWQdM0ETTVYjUYFSHKDAKEsSKHIqHx/N Fy8DAqMDYZvwSaZrJuEDNgt2J1x3+Bj42Ajgg490hC5eXRxdHp+fWy/oR2XI ulFkCD1xrER5XZ+j0V+VA7H1aMs92QOzGmc+3dqyftZ93de/r/t+TOkJPi5X 0PKY6hsh9TV1H50UDJ97ac6UVQto4qnW2RooqMOcwjyqMLowm+cI7rhIybm1 FIHWQsnBda+JFrH64rkKEl4JJgQhBM4jBQ2Q1oLUWwihAkneojgqx4JIxXHK 3CRRUTOqSxcnywEjGNYgShSJgnLWKmfQjSRKj6rtSviqY7Mxq4ITOUwUuQ0y ITv48CStB910y6O9JBkIJXIdQegAgGOFeigch2ZtPE9Qg9yxv7a9TeKyHmZr UfCsFldrs64ogXEJOICe4xQS2OOgyemth4jN9ImZwRHnaeV6fSsiSXTKpUT6 JPCPLp/hwex9MJyuPMtgsaCcEua/8dIQg/c2WKdy40/jEHwqVn/eDQBFZIIw tmjrSM8oqdqlRYZBeli5q16NbnC6aGkNj0bsbOiJY387bNAqHT7lDshEVBRB Ay6BriVxIhvpYTIkcw7du8H4bviciRP+/bYAZDMaS4QlcVddghUG1nS0pHEg KReoDfXQF0i+HwogRC7roCF/cPjf//IP/z7UuIf/+qd/HrLdZ3HG/vjMW6KN 4FP8PEStX7MHAQ8zoDMSxXZHClxPk+YJag/gEI8PbxziyeWZicYkaUheYQgc c+gU/kZhTJl44KMUo1BvPYCno/2Ovu1o2Oj37xQIagdBdjr65NU35xev9NX5 y1P969M3V+fHRy/drT78I8mEPWFL0PH1y6PjU/3qTJ9fXJ2+Ob280pfnX110 WKfX1PSB8siN4TPAXACoC/jSO9va277Tn+Hn/nZvHzy60if8cOcKNrcJAZka 0RxJOfxkf/sYfh/vbdMMOIFT9ytlOAZYXIx6KL8xAW4WBuJO1ril5SxFLKEp xNA9Y2UCNneMdIK7JQrVT5oGIA8+ULew+JMaBnDLe3fr0fBkBQM7goElzUEb uH4IBU8ew8D3zQkqFDx5BAMyyxMQ09GyVHYrUsJqPBFDfPoPpDoktCiCRFVM UQoSVGjnktCQFRi54n8hcn2a/hY/fk+mzZxSmqYRvyQvxF1gZhPslZjCiDa2 awM9drbUNEJfndr8ijIu1U5A5t6Tk6AfTZ4vMWUVRYWVlrSF0ZLkiJXHSZHP QRhMwCxLSTCjpiARNiQGHbI3tl4YdySwxauxUiYtWAaoLMNjvQn3UvuDh0m8 /rMBWEi9ZWvQxlgBUNXHDEGktXrP2hJe2NkZjAfB4NnADMb9vb3t/tZ469l4 vzeCT/1Rf8v09/1n+zBuLSv+f1x39+PWJYf6Lwt/+sIPiC5hEivBvirZkqoI yIqrG0mq9ZpZ77Ww3tcV67VRcH3+M9cldasr252rvuLEZVvTZdvV9cYgEF20 0bs0YKL/XgehN+kzSN10RA/GY+02JqtY+/E5q35au+4XmAi/pPKF0xgsNBQj NqMmyXC2CfMFmLnFSFLJ2WpuucyeUD+az5rQ7CIrmxEt6zPquVsTsxMBlowH M78P44BC8c3cZHdNBnhNHhWMjTK7SZYQe6uK3AyKeFSlBCj3w7ggf2zm5f60 4bALzGViS9UTn/fTqo2FH0qrqjKtWt+K78WridWRsZlyTp2U6dUSerWSaAUp fwrO2pILYmZAFhGWLKADt7zDcp/mj6qV6lSxwJoBmUvEEiCPjJdhfs1Ivuax KB+R7aG+1L2nLdJal7W0I8JCwbiPiMXlydyNzI2JWPnhvMhMnCxCXCL5xYDF BYZBKG2DYE89zuehgwhWAABNZrvsDHGjCDeVUbZ+l9giYTMqV8KaWI6I6RYp ZYW9MEFNsUKaXepK8YzkI6rnGiViRoy9BI79SfYKbMasQ4UqTBezcDLNkQTI iyE2J/OewzVi8xBVF1EOYibHMC9n7efUg1fXPobomH4sfrrqKF5qLlxivEpe O7yPQyzuaPhuJbSqquLo1DKKlpAojUexuXtY9cnfxrIPLungqBzbcrYiS8LR oFWxBqBRUeFlkhAjSorNQgp88iKV+ihiFMzmEcburQ/nlwAxZGbmofGH20fL LETrL08UbHlcRICECMO9KDjrBStyBtWh3Y9rNam2xg4PcQMNWg0OVbOshIkw SfmCi5WaNfoPR4XwQxkUwoxBWeOsr7yJvuAD6ehLkif615inRMGRe5O4mK2R HGt/WE+UUmo1WSAVfUQnXuXtg7fcTBnAmZNnK7HZ1ZKJ5dz09eGmdjYc7Qwc /dbpOrqAw3unnZYDWMYe8MdpV8od1vtokQP4YKDLeoWZ8ZCwoIEjRczD6Pgg e5TensWo7dRCoLB85RILnFa0AYbB8KCx1IUVAGqEaomONt1JFyuufomV7WDY AJVPSYhxiLjZXfcGg/3dncF+b0+3tm4H23s7W72tXhsJCZsGvf7Ws10lTVgH QE20WQGslAJSRykpedyqX6QptERLCrFxBqOqMOOQjURIiJlAXqa2pm4uGjdj 0rph0moNN/a6w9tbLuqCZdbwu5BOnvy0bDcOhX1NsCTSy8xDFDM1XuAy9tYQ jlibMmZvzRhV+wLMjWeN+WXnc4fncb5w2g36W8/kHtf+1bGzlt/VT+J3mLZk dwz5DzcGHCrDAoYS7CFryKpitSKorgzb+5hhDeDDsSRRwpi8V6HurW63v42B r+0+fNrd1S2g5TkFVasSmW3Z3/6znWdf0l0LIPrVFTLd3+l2t3u1KhQTSGqD Wz4CZMdW2nlRddkkiR3Ldkie/V2O1MHHz/u7X1Cuz9PjKPHy3qBDiVvVOgJd IFuccb2rRJ/FwgUVj3VSGIu+5FwQh5eZiaU6psFO1v5KvQnpUElTH9Qidn6O J/y5MOwXQH4bg+7n/FR2/EVLWtuq8Rz6VqKi263Jhue4WTRNK/HR7VbygmhZ SS5d9br6qlYVmJqyYAf2BSc1Agn+3uR18U+RjdDPJClKQ5hO4sSnym+SbtJN zz1Q9wYk6qaXTrgoiCQuaMRUJT6IpEyUs8daHVkA5EoYDNtUV0jxT93oOewO JW3f+m5qyP4pw8fzBLEVgvymastihnKP84xAm3JQgRmhMcWF13yQNkoO5mQ4 IpkOQBI27IZxXwsTRUgDfcTbSj7Q2jVszwLMnh6FOWfxbR6OvQdcFaSSnKQo HtoZl0oxQesgIQYkwY5pUGQS6GyFo9xxq/OArvOAVYPZPcmUVSlSiqPBJGxF 0n6x1mFjWGkEaG0dBUGZ+0nAd0xvPFvfWjF+v9tn1q+VdxPXF6PfQhdaZmwT Hnu7d3fPBQg/SaXwC7ZoyzYrcTKoV6VTuOA81lP0LNG2RqN1ieYt+dIGFVy9 ABHcMgICkSmZUXQScBbKd/rTBAxVESgVtknndPQ0WSChsndnES8HTUeYLCQF VmVQ8yQBULK0mKNKowJ12EuRYlbsuKFVVaMynm8d0DUKqZG1rnlZTmdF5QiI 1NyQx63YMdA1Isjsak0dLnnn9Y1NnO/WTzHgnPSS8wOl/YOZb7L0GwxXsRqJ BATOysNYmfgmTJOYtkKMQPTmoeM9AjPOJge5UDFJwOelmnJ4xEUMdHCE47KK w9bjN/oIjkxM2QrMl4Y+FRra2wB4a4LK/zGBcpTnKOTSjHI2Cy/O5d5KlIQi tqs9VvsDR8zHO7KYJbMeI7rpjbBIigEaWLIkTbQ1lzVKReCI5TyVLcHZmXXZ kwLGBI1EZA3aNUyoBAnsaapigtXL9Kq9AFAKlnrBsyUtoN4gsmopwhIRFGSu vWOx8JYdWwAhmFWrF17Ep1y9aSPWZQ0ydngT3KAmj93WEnMyGBCAQSHcTq16 RVmFbts8OhTeVWqoIALmtnhDU0qqU+6HTs5Xitbv1cHXT4vtd+KbCO8LAL0G S2VTfl5mA1m8d1AUsYf+aIsdfFR2BZZu5Cjc+Q4UHvsEOaxNth6Vc/gel3nh 6iWZGFCCAGqyBD+esQP+P1My1kSjO87iEUiRL+7YM7ZzEI1wpgGgV6txJnCN k3G+QFoM0AHFvXZI4hMdrDYiyuos2lUndhRH6KrCGy+4CTNGEZUONVBKKiW3 JS4+jkSLoAxVSBAE7V0SjudHF0drBGNd7qHDFCfc0/NtiIzuvWHYEGexefDj 5jWn8p7Wh42H7knZanZbvEFZX7m1DKuc51XJFUVVikhc+ZXrTuUdFBHfyt6m eZB1KndoTWiB/h6SE0Im0VuxQ0BizN5BTw9c8AkWk1EXJX4O3X9/pP8EPk3S OR61Kqc+1CEyvB1JX5Wd/1A7h1SLt3noKDtJ9RCfqtpS2PQ5emFhQNtxOuWX NjpTti9Yg2VXBKRX622/8wCCUzDRgz6XVO4svdrc3JP2vn57qVtklCdzgA+M imTels79d2AcZ3MPiE+y81JlMmKqZuMLaRCIBvwfnpD8WGIYRI6ybihbUsr6 l/eOCfb3rmx9wC/dpGroSz40bLmrtbxttLyrtfxgJ3tkwV9gH162nKO+7i/K lkcm+al+9mNudr0H12DXAj4rP8/hfH6bgMcQNob92M9zFDIf5c8rSyFAgd1u lygZ/ihF9EJPHWICxt0hsgwYiuDCC/1tMvrkYRs72g6H0IU5DC15MG241RAr vSU/Rl++029nBkF8D1oAvlUsjJuteq0/IdwqSBMMOoqkRxdm3fj7FKCqdQ9L Rnvr/K1D3Q+/KGMmNNMIpDe+hQMHHzSbOEzAz1XZj2UHb5wE2lti6XeKfT1E gcT4njrysTrjz2qE9EuYlQ6vrFR/Sn+toHO2bh3de1ovfseHI3z44vyi8RCm YmgPxeeq2BbvbpabxYwkvrSCTspxnXdEPlgbciV1RRI3kOgIqqVxygpJc2QU LJ44x1qSnLUdVieokhqn5pbHA0ViF2IBOwPQhGOcchL9rq3K/haexq55uP0G jfNqtCrhOoQejLlyZpztMxCiOKNt/APvsK2Wbv55XlP5yz2V/yv3VP4YNww+ ojp47X0DFaIcOz16+frrIxDmYJW4rCFgwy15vMlSqd1W/B3B2Om5u0dMpD13 70id2iY7xPmS5vk7+v1XjuIzPpTDeqZE0NGDHj4QJIoI/Ki7Op90wYcFZglJ D9gX9dh3l+o7/HD5GhH5UsFfRre6eAmfjl99883pxZXFpf0KyHzu6KdceP1H qcHGSajDFqN366S7dVQG5Zt2vY3NN61/z2YmgofC7dLs2qr6Mu6+oU/ExQYt C67sMZbpSg3yystbwMlYLeZd41zUXorUVapejMyRNZsPLi/qfORV5nXFeCoq ZnNMAE84TFovc0On3F6FIeFPDsy6HqASKXTSG4BAM7dt1HX4fbCjW+jdYx0z X7UXJ6x27ah557F/d9f+X7lYtOYOkfdTLhHhqzD4Zv5rKhfHTS7Xvb9npRD9 tP5GCSYSrjc3Uq+AgRl2/hcJBR35nqvBuHkuL3TgNFmLKhrZgccyBotsvrHN aEnKgutanapavfO0cgRCgGUhfHUK95BfmkosN7n9V3/o4fxKRlkpV8rLz5zK anBrspN8T5BOP9SOFZiuvJbYPJf9we62HBtX+V9SlT/dj0Nql9L5N4jlMllc hvwAl74ngcqsGOWRrfWpvaxkGgaBia2jDzKTCwYeofM/kVytvSHgR6QmY6zf EJdB9WogkCcAYiNxf+/e/7oL/+Qoy32ljqZrU3QRi5NgaoSvgzCI3SzDQqt6 NmycJGgiP0Ei29ne6e+c7fbBNHuCeQ56CPuw9trLM7lrmcRPKIwMCPmZesLJ LQxzS6pbrlDxnZLa24nwjrlHF/8XVQIJ/qcoyQC4HKhlCs6ADQTWXmLA7KeH 15RVhHn5Rmn8EVu5pr1cP7KZ6/u7Af9UCG0hby0AMqTIaVUN1KzVqL9ih++P XCT6TC79iBS74MjHEWWdymuGD7yRoyUSHIT3/Ys29ThdTqmvKtObouJLE3xx IRBUZLwyedWoxFGrL+WYmrW3BpvlPllu5pw2q5Uw1SsOZKYhSbPh5pCEE9df Z52aSQBrqea9fHk3T11t1RQZ3uaxKRpYufTCeRdlKkNVya6V9/3QzUx5D44I dzs78iRdS6pDt6pBm9HYMs4oEXx5JYG88KWOG3n3AQtvyoOXRS/DKSfJwQAe djk/bMPNbL7wKZKWxxfFcAahFvPk0HrdelDNNB6nlMo3iHUxsBokJrOFZpzH oXAxVQH6yXzpzj15EQ2WetWDzCSZkNr5DSA4L71WC/cJEvp3BSa47fs+MNrH 17apAjBrsHjtfmX7uRTtrWF7QI4IraV9rxYdzRD1HqLsLKQcAhctlAhDjoiB 8jGIKGzL2SWsj8GdVacRy1t8pABHTpNeoybRhwBL38imxeJlrCWOYR/ACmSn UdKNWN8EMSK4VT/FFZa7d2sDM5mwBBxFTtxLMNgcC9vQQL+nJxcdvDdo5pLB oxaMgzjD50PH5QQbbM1Nxm4UxqbErc3lwwzYX5G5w23l66kwXcejHGBXOxu9 Nq02ozPcsG18NVAf+e8B/MgEpGQykFFWQh069FJCVF3foL7CdDDQ7iQp38xU jGZhTrcdRVysvAOs/hIu1cjGdvEWC56IHRhnBb2SK8z8IsMcYYZ1Xx9OkgKc BWSXO+DsuTUfAQDOrWFmtDTzSs+oU6U0F4azmvaSOa8GMMU+eBCXkrCWrZVC 4CY0C9wWQPCNl/qJvgqjxPfusIwVnh1PU9QZuPYs+/1/ZBkC18qmBpgiDWQ8 4d5eF50UYYDJrzaNB6MZLSdjIkMjj07U42Pw8e//EUtCfr2M/fdGtTh1Cfs5 P738SlYEqfg/nFxdKN5YAAA=[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>