rfc9682.original.xml   rfc9682.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
3) --> -ietf-cbor-update-8610-grammar-06" number="9682" category="std" consensus="true"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft submissionType="IETF" updates="8610" obsoletes="" tocInclude="true" sortRefs="t
-ietf-cbor-update-8610-grammar-06" category="std" consensus="true" submissionTyp rue" symRefs="true" version="3" xml:lang="en">
e="IETF" updates="8610" tocInclude="true" sortRefs="true" symRefs="true" version
="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title abbrev="CDDL grammar updates">Updates to the CDDL grammar of RFC 8610 <title abbrev="CDDL grammar updates">Updates to the Concise Data Definition
</title> Language (CDDL) Grammar of RFC 8610</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-update-8610-grammar
-06"/> <!-- [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 RFC 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
-->
<seriesInfo name="RFC" value="9682"/>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2024" month="June" day="24"/> <date year="2024" month="October"/>
<area>ART</area> <area>ART</area>
<workgroup>CBOR</workgroup> <workgroup>cbor</workgroup>
<keyword>Concise Data Definition Language</keyword> <keyword>Concise Data Definition Language</keyword>
<abstract> <abstract>
<?line 82?>
<t>The Concise Data Definition Language (CDDL), as defined in <t>The Concise Data Definition Language (CDDL), as defined in
RFC 8610 and RFC 9165, RFCs 8610 and 9165,
provides an easy and unambiguous way to express structures for provides an easy and unambiguous way to express structures for
protocol messages and data formats that are represented in CBOR or protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or
JSON.</t> JSON.</t>
<t>The present document updates RFC 8610 by addressing errata and making <t>This document updates RFC 8610 by addressing related errata reports and
other small fixes for the ABNF grammar defined for CDDL there.</t> making
other small fixes for the ABNF grammar defined for CDDL.</t>
</abstract> </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/bro
wse/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> </front>
<middle> <middle>
<?line 93?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Concise Data Definition Language (CDDL), as defined in <t>The Concise Data Definition Language (CDDL), as defined in
<xref target="RFC8610"/> and <xref target="RFC9165"/>, <xref target="RFC8610"/> and <xref target="RFC9165"/>,
provides an easy and unambiguous way to express structures for provides an easy and unambiguous way to express structures for
protocol messages and data formats that are represented in CBOR or protocol messages and data formats that are represented in CBOR or
JSON.</t> JSON.</t>
<t>The present document updates <xref target="RFC8610"/> by addressing err <t>This document updates <xref target="RFC8610"/> by addressing errata and
ata and making making
other small fixes for the ABNF grammar defined for CDDL there. other small fixes for the ABNF grammar defined for CDDL.
The body of this document motivates and explains the updates; the The body of this document explains and shows motivation for the updates; the
updated collected ABNF syntax in <xref target="collected-abnf"/> in updated collected ABNF syntax in <xref target="collected-abnf"/> in
<xref target="collected-abnf-appendix"/> replaces the collected ABNF syntax in <xref target="collected-abnf-appendix"/> replaces the collected ABNF syntax in
<xref section="B" sectionFormat="of" target="RFC8610"/>.</t> <xref section="B" sectionFormat="of" target="RFC8610"/>.</t>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The Terminology from <xref target="RFC8610"/> applies. <t>The terminology from <xref target="RFC8610"/> applies.
The grammar in <xref target="RFC8610"/> is based on ABNF, which is defined in <x ref target="STD68"/> The grammar in <xref target="RFC8610"/> is based on ABNF, which is defined in <x ref target="STD68"/>
and <xref target="RFC7405"/>.</t> and <xref target="RFC7405"/>.</t>
</section> </section>
</section> </section>
<section anchor="clari"> <section anchor="clari">
<name>Clarifications and Changes based on Errata Reports</name> <name>Clarifications and Changes Based 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 expl
aining backslash escaping during the RFC publication process" would be more clea
r 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 <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"/>. string and byte string literal syntax: <xref target="Err6527"/> and <xref target ="Err6543"/>.
These are being addressed in this section, updating details of the These are being addressed in this section, updating details of the
ABNF for these literal syntaxes. ABNF for these literal syntaxes.
Also, <xref target="Err6526"/> needs to be applied (backslashes have been lost d uring Also, the changes described in <xref target="Err6526"/> need to be applied (back slashes have been lost during
RFC processing in some text explaining backslash escaping).</t> RFC processing in some text explaining backslash escaping).</t>
<t>These changes are intended to mirror the way existing implementations <t>These changes are intended to mirror the way existing implementations
have dealt with the errata. They also use the opportunity presented have dealt with the errata. This document also uses the opportunity presented
by the necessary cleanup of the grammar of string literals for a for the necessary cleanup of the grammar of string literals for a
backward compatible addition to the syntax for hexadecimal escapes. backward-compatible addition to the syntax for hexadecimal escapes.
The latter change is not automatically forward compatible (i.e., CDDL The latter change is not automatically forward compatible (i.e., CDDL
specifications that make use of this syntax do not necessarily work specifications that make use of this syntax do not necessarily work
with existing implementations until these are updated, which this with existing implementations until these are updated, which is recommended in t
specification recommends).</t> his
specification).</t>
<section anchor="e6527"> <section anchor="e6527">
<name>Updates to String Literal Grammar</name> <name>Updates to String Literal Grammar</name>
<section numbered="false" anchor="err6527-text-string-literals"> <section numbered="true" anchor="err6527-text-string-literals">
<name>Err6527 (Text String Literals)</name> <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 s tring literals <t>The ABNF used in <xref target="RFC8610"/> for the content of text s tring literals
is rather permissive:</t> is rather permissive:</t>
<!--[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 hex 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"> <figure anchor="e6527-orig1">
<name>Original RFC 8610 ABNF for strings with permissive ABNF for SE SC, but not allowing hex escapes</name> <name>ABNF from RFC 8610 for Strings with Permissive ABNF for SESC, but Not Allowing Hex Escapes</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; RFC 8610 ABNF: ; ABNF from RFC 8610:
text = %x22 *SCHAR %x22 text = %x22 *SCHAR %x22
SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
SESC = "\" (%x20-7E / %x80-10FFFD) SESC = "\" (%x20-7E / %x80-10FFFD)
]]></sourcecode> ]]></sourcecode>
</figure> </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 backslas h, <t>This allows almost any non-C0 character to be escaped by a backslas h,
but critically misses out on the <tt>\uXXXX</tt> and <tt>\uHHHH\uLLLL</tt> forms but critically misses out on the <tt>\uXXXX</tt> and <tt>\uHHHH\uLLLL</tt> forms
that JSON allows to specify characters in hex (which should be that JSON allows to specify characters in hex
applying here according to Bullet 6 of <xref section="3.1" sectionFormat="of" ta <!--end quoted material-->
rget="RFC8610"/>). (which should be
applied here according to Bullet 6 of <xref section="3.1" sectionFormat="of" tar
get="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, (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 which represents Unicode code points beyond U+FFFF by making them look
like UTF-16 surrogate pairs; CDDL text strings are not using UTF-16 or like UTF-16 surrogate pairs; CDDL text strings do not use UTF-16 or
surrogates.)</t> surrogates.)</t>
<t>Both can be solved by updating the SESC rule. <!--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 This document uses the opportunity to add a popular form of directly specifying
characters in strings using hexadecimal escape sequences of the form characters in strings using hexadecimal escape sequences of the form
<tt>\u{hex}</tt>, where <tt>hex</tt> is the hexadecimal representation of the <tt>\u{hex}</tt>, where <tt>hex</tt> is the hexadecimal representation of the
Unicode scalar value. Unicode scalar value.
The result is the new set of rules defining SESC in <xref target="e6527-new1"/>: </t> The result is the new set of rules defining SESC in <xref target="e6527-new1"/>. </t>
<figure anchor="e6527-new1"> <figure anchor="e6527-new1">
<name>Update to string ABNF in Appendix B of RFC 8610: allow hex esc <name>Update to String ABNF in Appendix B of <xref target="RFC8610"/
apes</name> >: Allow Hex Escapes</name>
<sourcecode type="abnf" name="cddl-new-sesc.abnf"><![CDATA[ <sourcecode type="abnf" name="cddl-new-sesc.abnf"><![CDATA[
; new rules collectively defining SESC: ; new rules collectively defining SESC:
SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\ SESC = "\" ( %x22 / "/" / "\" / ; \" \/ \\
%x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t %x62 / %x66 / %x6E / %x72 / %x74 / ; \b \f \n \r \t
(%x75 hexchar) ) ; \uXXXX (%x75 hexchar) ) ; \uXXXX
hexchar = "{" (1*"0" [ hexscalar ] / hexscalar) "}" / hexchar = "{" (1*"0" [ hexscalar ] / hexscalar) "}" /
non-surrogate / (high-surrogate "\" %x75 low-surrogate) non-surrogate / (high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) / non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG ) ("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG
hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG hexscalar = "10" 4HEXDIG / HEXDIG1 4HEXDIG
/ non-surrogate / 1*3HEXDIG / non-surrogate / 1*3HEXDIG
HEXDIG1 = DIGIT1 / "A" / "B" / "C" / "D" / "E" / "F" HEXDIG1 = DIGIT1 / "A" / "B" / "C" / "D" / "E" / "F"
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>(Notes: <t>(Notes:
In ABNF, strings such as <tt>"A"</tt>, <tt>"B"</tt> etc. are case-insensitive, a s is In ABNF, strings such as <tt>"A"</tt>, <tt>"B"</tt>, etc., are case insensitive, as is
intended here. intended here.
The rules above could, instead of <tt>%x62</tt>, also have used <tt>%s"b"</tt> e The rules above could have also used <tt>%s"b"</tt>, etc., instead of <tt>%x62</
tc., but didn't, in order to tt>, but didn't, in order to
maximize ABNF tool compatibility.)</t> maximize compatibility of ABNF tools.)</t>
<t>Now that SESC is more restrictively formulated, this also requires <t>Now that SESC is more restrictively formulated, an
an
update to the BCHAR rule used in the ABNF syntax for byte string update to the BCHAR rule used in the ABNF syntax for byte string
literals:</t> literals is also required:</t>
<figure anchor="e6527-orig2"> <figure anchor="e6527-orig2">
<name>Original RFC 8610 ABNF for BCHAR</name> <name>ABNF from RFC 8610 for BCHAR</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; RFC 8610 ABNF: ; ABNF from RFC 8610:
bytes = [bsqual] %x27 *BCHAR %x27 bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
bsqual = "h" / "b64" bsqual = "h" / "b64"
]]></sourcecode> ]]></sourcecode>
</figure> </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; <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> this now needs to be explicitly included; see below.</t>
</section> </section>
<section numbered="false" anchor="e6278"> <section numbered="true" anchor="e6278">
<name>Err6278 (Consistent String Literals)</name> <name>Erratum ID 6278 (Consistent String Literals)</name>
<t>Updating BCHAR also provides an opportunity to address <xref target ="Err6278"/>, <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 which points to an inconsistency in treating U+007F (DEL) between SCHAR and
BCHAR. BCHAR.
As U+007F is not printable, including it in a byte string literal is As U+007F is not printable, including it in a byte string literal is
as confusing as for a text string literal, and it should therefore be as confusing as for a text string literal; therefore, it should be
excluded from BCHAR as it is from SCHAR. excluded from BCHAR as it is from SCHAR.
The same reasoning also applies to the C1 control characters, 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. so the updated ABNF actually excludes the entire range from U+007F to U+009F.
The same reasoning then also applies to text in comments (PCHAR). The same reasoning also applies to text in comments (PCHAR).
<!--[rfced] For the ease of the reader, should the antecedent of "these" be clar
ified?
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 For completeness, all these should also explicitly exclude the code
points that have been set aside for UTF-16's surrogates.</t> points that have been set aside for UTF-16 surrogates.</t>
<figure anchor="e6527-new2"> <figure anchor="e6527-new2">
<name>Update to ABNF in Appendix B of RFC 8610: BCHAR, SCHAR, and PC HAR</name> <name>Update to ABNF in Appendix B of <xref target="RFC8610"/>: BCH AR, SCHAR, and PCHAR</name>
<sourcecode type="abnf" name="cddl-new-bchar.abnf"><![CDATA[ <sourcecode type="abnf" name="cddl-new-bchar.abnf"><![CDATA[
; new rules for SCHAR, BCHAR, and PCHAR: ; new rules for SCHAR, BCHAR, and PCHAR:
SCHAR = %x20-21 / %x23-5B / %x5D-7E / NONASCII / SESC SCHAR = %x20-21 / %x23-5B / %x5D-7E / NONASCII / SESC
BCHAR = %x20-26 / %x28-5B / %x5D-7E / NONASCII / SESC / "\'" / CRLF BCHAR = %x20-26 / %x28-5B / %x5D-7E / NONASCII / SESC / "\'" / CRLF
PCHAR = %x20-7E / NONASCII PCHAR = %x20-7E / NONASCII
NONASCII = %xA0-D7FF / %xE000-10FFFD NONASCII = %xA0-D7FF / %xE000-10FFFD
]]></sourcecode> ]]></sourcecode>
</figure> </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 <t>(Note that, apart from addressing the inconsistencies, there is no
attempt to further exclude non-printable characters from the ABNF; attempt to further exclude non-printable characters from the ABNF;
doing this properly would draw in complexity from the ongoing doing this properly would draw in complexity from the ongoing
evolution of the Unicode standard that is not needed here.)</t> evolution of the Unicode standard that is not needed here.)</t>
</section> </section>
<section numbered="false" anchor="addressing-err6526-err6543"> <section numbered="true" anchor="addressing-err6526-err6543">
<name>Addressing Err6526, Err6543</name> <name>Addressing Erratum ID 6526 and Erratum ID 6543</name>
<t>The above changes also cover <xref target="Err6543"/> (a proposal t o split off <t>The above changes also cover <xref target="Err6543"/> (a proposal t o split off
qualified byte string literals from UTF-8 byte string literals) and qualified byte string literals from UTF-8 byte string literals) and
<xref target="Err6526"/> (lost backslashes); see <xref target="Err6543-covered"/ > for details.</t> <xref target="Err6526"/> (lost backslashes); see <xref target="Err6543-covered"/ > for details.</t>
</section> </section>
</section> </section>
<section anchor="examples-demonstrating-the-updated-string-syntaxes"> <section anchor="examples-demonstrating-the-updated-string-syntaxes">
<name>Examples Demonstrating the Updated String Syntaxes</name> <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 conte
xt.
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 var ious escaping <t>The CDDL example in <xref target="string-examples"/> demonstrates var ious escaping
techniques now available for (byte and text) strings in CDDL. techniques now available for (byte and text) strings in CDDL.
Obviously in the literals for <tt>a</tt> and <tt>x</tt>, there is no need to esc ape Obviously, in the literals for <tt>a</tt> and <tt>x</tt>, there is no need to es cape
the second character, an <tt>o</tt>, as <tt>\u{6f}</tt>; this is just for demons tration. the second character, an <tt>o</tt>, as <tt>\u{6f}</tt>; this is just for demons tration.
Similarly, as shown in <tt>c</tt> and <tt>z</tt> there also is no need to escape Similarly, as shown in <tt>c</tt> and <tt>z</tt>, there also is no need to escap
the e the
<tt>🁳</tt> or <tt>⌘</tt>, but escaping them may be convenient in order to limit <u>🁳</u> or <u>⌘</u>; however, escaping them may be convenient in order to limit
the character the character
repertoire of a CDDL file itself to ASCII <xref target="STD80"/>.</t> repertoire of a CDDL file itself to ASCII <xref target="STD80"/>.</t>
<figure anchor="string-examples"> <figure anchor="string-examples">
<name>Example text and byte string literals with various escaping tech niques</name> <name>Example Text and Byte String Literals with Various Escaping Tech niques</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
start = [a, b, c, x, y, z] start = [a, b, c, x, y, z]
; "🁳", DOMINO TILE VERTICAL-02-02, and ; "🁳", DOMINO TILE VERTICAL-02-02, and
; "⌘", PLACE OF INTEREST SIGN, in a text string: ; "⌘", PLACE OF INTEREST SIGN, in a text string:
a = "D\u{6f}mino's \u{1F073} + \u{2318}" ; \u{}-escape 3 chars a = "D\u{6f}mino's \u{1F073} + \u{2318}" ; \u{}-escape 3 chars
b = "Domino's \uD83C\uDC73 + \u2318" ; escape JSON-like b = "Domino's \uD83C\uDC73 + \u2318" ; escape JSON-like
c = "Domino's 🁳 + ⌘" ; unescaped c = "Domino's 🁳 + ⌘" ; unescaped
; in a byte string given as text, the ' needs to be escaped: ; 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 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 y = 'Domino\'s \uD83C\uDC73 + \u2318' ; escape JSON-like
z = 'Domino\'s 🁳 + ⌘' ; escape ' only z = 'Domino\'s 🁳 + ⌘' ; escape ' only
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>In this example, the rules a to c and x to z all produce strings with <t>In this example, the rules a to c and x to z all produce strings with
byte-wise identical content, where a to c are text strings, and x to z byte-wise identical content: a to c are text strings and x to z
are byte strings. are byte strings.
<xref target="string-examples-pretty"/> illustrates this by showing the output g enerated from <xref target="string-examples-pretty"/> illustrates this by showing the output g enerated from
the <tt>start</tt> rule in <xref target="string-examples"/>, using pretty-printe d hexadecimal.</t> the <tt>start</tt> rule in <xref target="string-examples"/>, using pretty-printe d hexadecimal.</t>
<figure anchor="string-examples-pretty"> <figure anchor="string-examples-pretty">
<name>Generated CBOR from CDDL example (Pretty-Printed Hexadecimal)</n ame> <name>Generated CBOR from CDDL Example (Pretty-Printed Hexadecimal)</n ame>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
86 # array(6) 86 # array(6)
73 # text(19) 73 # text(19)
446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘"
73 # text(19) 73 # text(19)
446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘"
73 # text(19) 73 # text(19)
446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘"
53 # bytes(19) 53 # bytes(19)
446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘"
53 # bytes(19) 53 # bytes(19)
446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘"
53 # bytes(19) 53 # bytes(19)
446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘" 446f6d696e6f277320f09f81b3202b20e28c98 # "Domino's 🁳 + ⌘"
]]></sourcecode> ]]></sourcecode>
</figure> </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 XM
L prior to publication of the RFC. -->
<!-- cddl sourcecode/cddl/no-change-needed-after-addr.cddl g | diag2pret ty.rb | diff - sourcecode/cbor-pretty/no-change-needed-after-addr.cbor-pretty - -> <!-- cddl sourcecode/cddl/no-change-needed-after-addr.cddl g | diag2pret ty.rb | diff - sourcecode/cbor-pretty/no-change-needed-after-addr.cbor-pretty - ->
</section> </section>
</section> </section>
<section anchor="small-enabling-grammar-changes"> <section anchor="small-enabling-grammar-changes">
<name>Small Enabling Grammar Changes</name> <name>Small Enabling Grammar Changes</name>
<t>The two subsections in this section specify two small changes to the <t>Each subsection that follows specifies a small change to the
grammar that are intended to enable certain kinds of specifications. grammar that is intended to enable certain kinds of specifications.
These changes are backward compatible, i.e., CDDL files that These changes are backward compatible (i.e., CDDL files that
comply to <xref target="RFC8610"/> continue to match the updated grammar, but no comply with <xref target="RFC8610"/> continue to match the updated grammar) but
t not
necessarily forward compatible, i.e., CDDL specifications that make necessarily forward compatible (i.e., CDDL specifications that make
use of these changes cannot necessarily be processed by existing <xref target="R use of these changes cannot necessarily be processed by existing implementations
FC8610"/> of <xref target="RFC8610"/>).</t>
implementations.</t>
<section anchor="empty"> <section anchor="empty">
<name>Empty data models</name> <name>Empty Data Models</name>
<t><xref target="RFC8610"/> requires a CDDL file to have at least one ru le.</t> <t><xref target="RFC8610"/> requires a CDDL file to have at least one ru le.</t>
<figure anchor="empty-orig"> <figure anchor="empty-orig">
<name>Original RFC 8610 ABNF for top-level rule cddl</name> <name>ABNF from RFC 8610 for Top-Level Rule cddl</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; RFC 8610 ABNF: ; ABNF from RFC 8610:
cddl = S 1*(rule S) cddl = S 1*(rule S)
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>This makes sense when the file has to stand alone, as a CDDL data <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 model needs to have at least one rule to provide an entry point (i.e., a start
rule).</t> rule).</t>
<t>With CDDL modules <xref target="I-D.ietf-cbor-cddl-modules"/>, CDDL f iles can also include directives, <t>With CDDL modules <xref target="I-D.ietf-cbor-cddl-modules"/>, CDDL f iles can also include directives,
and these might be the source of all the rules that and these might be the source of all the rules that
ultimately make up the module created by the file. ultimately make up the module created by the file.
Any other rule content in the file has to be available for directive Any other rule content in the file has to be available for directive
processing, making the requirement for at least one rule cumbersome.</t> 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"/> <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 and turns the existence of at least one rule into a semantic constraint, to
be fulfilled after processing of all directives.</t> be fulfilled after processing of all directives.</t>
<figure anchor="empty-new"> <figure anchor="empty-new">
<name>Update to top-level ABNF in Appendices B and C of RFC 8610</name > <name>Update to Top-Level ABNF in Appendices B and C of RFC 8610</nam e>
<sourcecode type="abnf" name="cddl-new-cddl.abnf"><![CDATA[ <sourcecode type="abnf" name="cddl-new-cddl.abnf"><![CDATA[
; new top-level rule: ; new top-level rule:
cddl = S *(rule S) cddl = S *(rule S)
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="tagnum"> <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> <name>Non-literal Tag Numbers, Simple Values</name>
<t>The existing ABNF syntax for expressing tags in CDDL is:</t> <t>The existing ABNF syntax for expressing tags in CDDL is as follows:</ t>
<figure anchor="tag-orig"> <figure anchor="tag-orig">
<name>Original RFC 8610 ABNF for tag syntax</name> <name>Original ABNF from RFC 8610 for Tag Syntax</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; extracted from RFC 8610 ABNF: ; extracted from the ABNF in RFC 8610:
type2 =/ "#" "6" ["." uint] "(" S type S ")" type2 =/ "#" "6" ["." uint] "(" S type S ")"
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>This means tag numbers can only be given as literal numbers (uints). <t>This means tag numbers can only be given as literal numbers (uints).
Some specifications operate on ranges of tag numbers, e.g., <xref target="RFC927 7"/> Some specifications operate on ranges of tag numbers; for example, <xref target ="RFC9277"/>
has a range of tag numbers 1668546817 (0x63740101) to 1668612095 has a range of tag numbers 1668546817 (0x63740101) to 1668612095
(0x6374FFFF) to tag specific content formats. (0x6374FFFF) to tag specific content formats.
This can currently not be expressed in CDDL. This can currently not be expressed in CDDL.
Similar considerations apply to simple values (<tt>#7.</tt>xx).</t> Similar considerations apply to simple values (<tt>#7.</tt>xx).</t>
<t>This update extends the syntax to:</t> <t>This update extends the syntax to the following:</t>
<figure anchor="tag-new"> <figure anchor="tag-new">
<name>Update to tag and simple value ABNF in Appendices B and C of RFC 8610</name> <name>Update to Tag and Simple Value ABNF in Appendices B and C of RFC 8610</name>
<sourcecode type="abnf" name="cddl-new-tag.abnf"><![CDATA[ <sourcecode type="abnf" name="cddl-new-tag.abnf"><![CDATA[
; new rules collectively defining the tagged case: ; new rules collectively defining the tagged case:
type2 =/ "#" "6" ["." head-number] "(" S type S ")" type2 =/ "#" "6" ["." head-number] "(" S type S ")"
/ "#" "7" ["." head-number] / "#" "7" ["." head-number]
head-number = uint / ("<" type ">") head-number = uint / ("<" type ">")
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>For <tt>#6</tt>, the <tt>head-number</tt> stands for the tag number. <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 i n For <tt>#7</tt>, the <tt>head-number</tt> stands for the simple value if it is i n
the ranges 0..23 or 32..255 (as per Section <xref target="RFC8949" section="3.3" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/> the ranges 0..23 or 32..255 (as per Section <xref target="RFC8949" section="3.3" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/>,
the simple values 24..31 are not used). the simple values 24..31 are not used).
For 24..31, the <tt>head-number</tt> stands for the "additional For 24..31, the <tt>head-number</tt> stands for the "additional
information", e.g., <tt>#7.25</tt> or <tt>#7.&lt;25&gt;</tt> is a float16, etc. information", e.g., <tt>#7.25</tt> or <tt>#7.&lt;25&gt;</tt> is a float16, etc.
(All ranges mentioned here are inclusive.)</t> (All ranges mentioned here are inclusive.)</t>
<t>So the above range can be expressed in a CDDL fragment such as:</t> <t>So the above range can be expressed in a CDDL fragment such as:</t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
ct-tag<content> = #6.<ct-tag-number>(content) ct-tag<content> = #6.<ct-tag-number>(content)
ct-tag-number = 1668546817..1668612095 ct-tag-number = 1668546817..1668612095
; or use 0x63740101..0x6374FFFF ; or use 0x63740101..0x6374FFFF
]]></sourcecode> ]]></sourcecode>
<t>Notes:</t> <t>Notes:</t>
<ol spacing="normal" type="1"><li> <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; <t>This syntax reuses the angle bracket syntax for generics;
this reuse is innocuous as a generic parameter/argument only ever 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. 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 (Whether there is potential for human confusion can be debated; the
above example deliberately uses generics as well.)</t> above example deliberately uses generics as well.)</t>
</li> </li>
<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 <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 number given after the optional dot is special, not giving the CBOR
"additional information" for tags and simple values as it is with "additional information" for tags and simple values as it is with
other uses of <tt>#</tt> in CDDL. other uses of <tt>#</tt> in CDDL.
(Adding this observation to <xref section="2.2.3" sectionFormat="of" target="RFC 8610"/> is the subject (Adding this observation to <xref section="2.2.3" sectionFormat="of" target="RFC 8610"/> is the subject
of <xref target="Err6575"/>; it is correctly noted in <xref section="3.6" sectio nFormat="of" target="RFC8610"/>.) of <xref target="Err6575"/>; it is correctly noted in <xref section="3.6" sectio nFormat="of" target="RFC8610"/>.)
In hindsight, maybe a different character than the dot should have In hindsight, maybe a different character than the dot should have
been chosen for this special case, however changing the grammar been chosen for this special case; however, changing the grammar
now would have been too disruptive.</t> in the current document would have been too disruptive.</t>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The grammar fixes and updates in this document are not believed to <t>The grammar fixes and updates in this document are not believed to
create additional security considerations. create additional security considerations.
The security considerations in <xref section="5" sectionFormat="of" target="RFC8 The security considerations in <xref section="5" sectionFormat="of" target="RFC8
610"/> do apply, and 610"/> apply.
specifically the potential for confusion is increased in an Specifically, the potential for confusion is increased in an
environment that uses a combination of CDDL tools some of which have environment that uses a combination of CDDL tools, some of which have
been updated and some of which have not been, in particular based on been updated and some of which have not, in particular based on
<xref target="clari"/>.</t> <xref target="clari"/>.</t>
<t>Attackers may want to exploit such potential confusion by crafting <t>Attackers may want to exploit such potential confusion by crafting
CDDL models that are interpreted differently by different parts of a CDDL models that are interpreted differently by different parts of a
system. system.
There will be a period of transition from the details that the There will be a period of transition from the details that the grammar in
<xref target="RFC8610"/> grammar handled in a less well-defined way, to the upda <xref target="RFC8610"/> handled in a less-well-defined way, to the updated
ted
grammar defined in the present document. 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 This transition might offer one, but not the only kind of opportunity
for the kind of attack that relies on differences between for the kind of attack that relies on differences between
implementations. implementations.
Implementations that make use of CDDL models operationally already Implementations that make use of CDDL models operationally already
need to ascertain the provenance (and thus authenticity and integrity) need to ascertain the provenance (and thus authenticity and integrity)
and applicability of models they employ. and applicability of models they employ.
At the time of writing, it is expected that the models will generally At the time of writing, it is expected that the models will generally
be processed by a software developer, within a software development be processed by a software developer, within a software-development
environment. environment.
Developers are therefore advised to treat CDDL models with Therefore, developers are advised to treat CDDL models with
the same care as any other source code.</t> the same care as any other source code.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-cbor-cddl-modules" to="CDDL-MODULES"/>
<displayreference target="I-D.ietf-cbor-edn-literals" to="EDN-LITERALS"/>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8610">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
<title>Concise Data Definition Language (CDDL): A Notational Convent 10.xml"/>
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0068.xml
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/> " />
<author fullname="C. Vigano" initials="C." surname="Vigano"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0094.xml
<date month="June" year="2019"/> " />
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages 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/s
td68">
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rf
c5234">
<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 form
al syntax. Over the years, a modified version of Backus-Naur Form (BNF), called
Augmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and ABN
F involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encodin
g for a core lexical analyzer of the type common to several Internet specificati
ons. [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/s
td94">
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf
c8949">
<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 for
mat whose design goals include the possibility of extremely small code size, fai
rly small message size, and extensibility without the need for version negotiati
on. 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 improve
ments, new details, and errata fixes while keeping full compatibility with the i
nterchange 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>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<referencegroup anchor="STD80" target="https://www.rfc-editor.org/info/s
td80">
<reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rf
c20">
<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 Ba
ckus-Naur Form) to include a way to specify US-ASCII string literals that are ma
tched 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 RF
C 8610, provides "control operators" as its 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 constructi
on of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specificat
ions; 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 time of writing, 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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0080.xml
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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
</abstract> 05.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-cddl-modules- 65.xml"/>
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 <!-- [I-D.ietf-cbor-cddl-modules];I-D exists as of 9/5/24 -->
the diagnostic notation. It then defines two such extensions for <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cb
text representations of epoch-based date/times and of IP addresses or-cddl-modules.xml"/>
and prefixes (RFC 9164).
A few further additions close some gaps in usability. To facilitate <!-- [I-D.ietf-cbor-edn-literals];Waiting for AD go-ahead as of 9/5/24 -->
tool interoperation, this document specifies a formal ABNF definition <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cb
for extended diagnostic notation (EDN) that accommodates application- or-edn-literals.xml"/>
oriented literals.
</t> <reference anchor="Err6278" target="https://www.rfc-editor.org/errata/ei
</abstract> d6278" quote-title="false">
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-edn-literals-
09"/>
</reference>
<reference anchor="Err6278" target="https://www.rfc-editor.org/errata/ei
d6278">
<front> <front>
<title>Errata Report 6278</title> <title>Erratum ID 6278</title>
<author> <author>
<organization/> <organization>RFC Errata</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <refcontent>RFC 8610</refcontent>
</reference> </reference>
<reference anchor="Err6526" target="https://www.rfc-editor.org/errata/ei
d6526"> <reference anchor="Err6526" target="https://www.rfc-editor.org/errata/ei
d6526" quote-title="false">
<front> <front>
<title>Errata Report 6526</title> <title>Erratum ID 6526</title>
<author> <author>
<organization/> <organization>RFC Errata</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <refcontent>RFC 8610</refcontent>
</reference> </reference>
<reference anchor="Err6527" target="https://www.rfc-editor.org/errata/ei
d6527"> <reference anchor="Err6527" target="https://www.rfc-editor.org/errata/ei
d6527" quote-title="false">
<front> <front>
<title>Errata Report 6527</title> <title>Erratum ID 6527</title>
<author> <author>
<organization/> <organization>RFC Errata</organization>
</author> </author>
<date/> <date/>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <refcontent>RFC 8610</refcontent>
</reference> </reference>
<reference anchor="Err6543" target="https://www.rfc-editor.org/errata/ei
d6543"> <reference anchor="Err6543" target="https://www.rfc-editor.org/errata/ei
d6543" quote-title="false">
<front> <front>
<title>Errata Report 6543</title> <title>Erratum ID 6543</title>
<author> <author>
<organization/> <organization>RFC Errata</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <refcontent>RFC 8610</refcontent>
</reference> </reference>
<reference anchor="Err6575" target="https://www.rfc-editor.org/errata/ei
d6575"> <reference anchor="Err6575" target="https://www.rfc-editor.org/errata/ei
d6575" quote-title="false">
<front> <front>
<title>Errata Report 6575</title> <title>Erratum ID 6575</title>
<author> <author>
<organization/> <organization>RFC Errata</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <refcontent>RFC 8610</refcontent>
</reference>
<reference anchor="RFC9277">
<front>
<title>On Stable Storage for Items in Concise Binary Object Represen
tation (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 Bina
ry Object Representation (CBOR) data items that is friendly to common systems th
at 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"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
77.xml"/>
</references> </references>
</references> </references>
<?line 440?>
<section anchor="collected-abnf-appendix"> <section anchor="collected-abnf-appendix">
<name>Updated Collected ABNF for CDDL</name> <name>Updated Collected ABNF for CDDL</name>
<t>This appendix is normative.</t> <t>This appendix is normative.</t>
<t>It provides the full ABNF from <xref target="RFC8610"/> with the update <t>It provides the full ABNF from <xref target="RFC8610"/> as updated by t
s he present document.</t>
applied in the present document.</t>
<figure anchor="collected-abnf"> <figure anchor="collected-abnf">
<name>ABNF for CDDL as updated</name> <name>ABNF for CDDL as Updated</name>
<sourcecode type="abnf" name="cddl-updated-complete.abnf"><![CDATA[ <sourcecode type="abnf" name="cddl-updated-complete.abnf"><![CDATA[
cddl = S *(rule S) cddl = S *(rule S)
rule = typename [genericparm] S assignt S type rule = typename [genericparm] S assignt S type
/ groupname [genericparm] S assigng S grpent / groupname [genericparm] S assigng S grpent
typename = id typename = id
groupname = id groupname = id
assignt = "=" / "/=" assignt = "=" / "/="
assigng = "=" / "//=" assigng = "=" / "//="
skipping to change at line 719 skipping to change at line 788
SP = %x20 SP = %x20
NL = COMMENT / CRLF NL = COMMENT / CRLF
COMMENT = ";" *PCHAR CRLF COMMENT = ";" *PCHAR CRLF
PCHAR = %x20-7E / NONASCII PCHAR = %x20-7E / NONASCII
NONASCII = %xA0-D7FF / %xE000-10FFFD NONASCII = %xA0-D7FF / %xE000-10FFFD
CRLF = %x0A / %x0D.0A CRLF = %x0A / %x0D.0A
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="Err6543-covered"> <section anchor="Err6543-covered">
<name>Details about Covering Errata Report 6543</name> <name>Details about Covering Erratum ID 6543</name>
<t>This appendix is informative.</t> <t>This appendix is informative.</t>
<t><xref target="Err6543"/> observes that <t><xref target="Err6543"/> notes that
the ABNF used in <xref target="RFC8610"/> for the content of byte string literal s the ABNF used in <xref target="RFC8610"/> for the content of byte string literal s
lumps together byte strings notated as text with byte strings notated 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="e652 in base16 (hex) or base64 (but see also updated BCHAR rule in <xref target
7-new2"/>):</t> ="e6527-new2"/>):</t>
<figure anchor="e6527-orig2a"> <figure anchor="e6527-orig2a">
<name>Original RFC 8610 ABNF for BCHAR</name> <name>Original ABNF from RFC 8610 for BCHAR</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; RFC 8610 ABNF: ; ABNF from RFC 8610:
bytes = [bsqual] %x27 *BCHAR %x27 bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<section numbered="false" anchor="change-proposed-by-errata-report-6543"> <section numbered="true" anchor="change-proposed-by-errata-report-6543">
<name>Change Proposed By Errata Report 6543</name> <name>Change Proposed by Erratum ID 6543</name>
<t>Errata report 6543 proposes to handle the two cases in separate <t>Erratum ID 6543 proposes handling the two cases in separate
ABNF rules (where, with an updated SESC, BCHAR obviously needs to be ABNF rules (where, with an updated SESC, BCHAR obviously needs to be
updated as above):</t> updated as above):</t>
<figure anchor="e6543-1"> <figure anchor="e6543-1">
<name>Errata Report 8653 Proposal to Split the Byte String Rules</name > <name>Proposal from Erratum ID 6543 to Split the Byte String Rules</na me>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; Err6543 proposal: ; Proposal from Erratum ID 6543:
bytes = %x27 *BCHAR %x27 bytes = %x27 *BCHAR %x27
/ bsqual %x27 *QCHAR %x27 / bsqual %x27 *QCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS QCHAR = DIGIT / ALPHA / "+" / "/" / "-" / "_" / "=" / WS
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>This potentially causes a subtle change, which is hidden in the WS ru le:</t> <t>This potentially causes a subtle change, which is hidden in the WS ru le:</t>
<figure anchor="e6543-2"> <figure anchor="e6543-2">
<name>ABNF definition of WS from RFC 8610</name> <name>ABNF Definition of WS from RFC 8610</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; RFC 8610 ABNF: ; ABNF from RFC 8610:
WS = SP / NL WS = SP / NL
SP = %x20 SP = %x20
NL = COMMENT / CRLF NL = COMMENT / CRLF
COMMENT = ";" *PCHAR CRLF COMMENT = ";" *PCHAR CRLF
PCHAR = %x20-7E / %x80-10FFFD PCHAR = %x20-7E / %x80-10FFFD
CRLF = %x0A / %x0D.0A CRLF = %x0A / %x0D.0A
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>This allows any non-C0 character in a comment, so this fragment <t>This allows any non-C0 character in a comment, so this fragment
becomes possible:</t> becomes possible:</t>
skipping to change at line 779 skipping to change at line 849
<t>The current text is not unambiguously saying whether the three apostr ophes <t>The current text is not unambiguously saying whether the three apostr ophes
need to be escaped with a <tt>\</tt> or not, as in:</t> need to be escaped with a <tt>\</tt> or not, as in:</t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
foo = h' foo = h'
43424F52 ; \'CBOR\' 43424F52 ; \'CBOR\'
0A ; LF, but don\'t use CR! 0A ; LF, but don\'t use CR!
' '
]]></sourcecode> ]]></sourcecode>
<t>... which would be supported by the existing ABNF in <xref target="RF C8610"/>.</t> <t>... which would be supported by the existing ABNF in <xref target="RF C8610"/>.</t>
</section> </section>
<section numbered="false" anchor="no-further-change-needed-after-updating- <section numbered="true" anchor="no-further-change-needed-after-updating-s
string-literal-grammar-e6527"> tring-literal-grammar-e6527">
<name>No Further Change Needed After Updating String Literal Grammar (<x <name>No Further Change Needed after Updating String Literal Grammar</na
ref target="e6527"/>)</name> me>
<!--[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 <t>This document takes the simpler approach of leaving the processing of
the content of the byte string literal to a semantic step after 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 processing the syntax of the <tt>bytes</tt>/<tt>BCHAR</tt> rules, as updated by
<xref target="e6527-new1"/> and <xref target="e6527-new2"/> in <xref target="e65 27"/> (updates prompted by the combination Figures <xref target="e6527-new1" format="counter"/> and <xref target="e6527-new 2" format="counter"/> in <xref target="e6527"/> (updates prompted by the combina tion
of <xref target="Err6527"/> and <xref target="Err6278"/>).</t> of <xref target="Err6527"/> and <xref target="Err6278"/>).</t>
<t>The rules in <xref target="e6543-2"/> (as updated by <xref target="e6 527-new2"/>) are therefore <t>Therefore, the rules in <xref target="e6543-2"/> (as updated by <xref target="e6527-new2"/>) are
applied to the result of this applied to the result of this
processing where <tt>bsqual</tt> is given as <tt>h</tt> or <tt>b64</tt>.</t> 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 <t>Note that this approach also works well with the use of byte strings
in <xref section="3" sectionFormat="of" target="RFC9165"/>. in <xref section="3" sectionFormat="of" target="RFC9165"/>.
It does require some care when copy-pasting into CDDL models from ABNF It does require some care when copying-and-pasting into CDDL models from ABNF
that contains single quotes (which may also hide as apostrophes that contain single quotes (which may also hide as apostrophes
in comments); these need to be escaped or possibly replaced by <tt>%x27</tt>.</t > 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 <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"/>. similar to the way this is done for CBOR diagnostic notation in <xref target="I- D.ietf-cbor-edn-literals"/>.
(Note that the processing of string literals now is quite similar between (Note that, at the time of writing, the processing of string literals is quite s
CDDL and EDN, except that CDDL has "<tt>;</tt>"-based end-of-line comments, whil imilar for both
e EDN has CDDL and Extended Diagnostic Notation (EDN), except that CDDL has end-of-line co
two comment syntaxes, in-line "<tt>/</tt>"-based and end-of-line "<tt>#</tt>"-ba mments that are "<tt>;</tt>" based and EDN has
sed.)</t> two comment syntaxes: those that are in-line "<tt>/</tt>" based and those that a
re end-of-line "<tt>#</tt>" based.)</t>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>Many thanks go to the submitters of the errata reports addressed in <t>Many thanks go to the submitters of the errata reports addressed in
this document. this document.
In one of the ensuing discussions, <contact fullname="Doug Ewell"/> proposed to In one of the ensuing discussions, <contact fullname="Doug Ewell"/> proposed de
define an fining an
ABNF rule NONASCII, of which we have included the essence. ABNF rule "NONASCII", of which we have included the essence.
Special thanks to the reviewers <contact fullname="Marco Tiloca"/>, <contact ful Special thanks to the reviewers <contact fullname="Marco Tiloca"/>, <contact ful
lname="Christian Amsüss"/> (shepherd review and further guidance), <contact full lname="Christian Amsüss"/> (
name="Orie Steele"/> (AD Shepherd Review and further guidance), <contact fullname="Orie Steele"/> (AD
review and further guidance), and Éric Vyncke Review and further guidance), and <contact fullname="Éric Vyncke"/>
(detailed IESG review).</t> (detailed IESG review).</t>
</section> </section>
</back>
<!-- ##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] A general note: throughout the document, we see several instances wh
ere "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 b
elow:
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 desire
d.
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.
-->
<!-- [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> </rfc>
 End of changes. 125 change blocks. 
569 lines changed or deleted 484 lines changed or added

This html diff was produced by rfcdiff 1.48.