<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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.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 CDDL grammar of RFC 8610</title> Concise Data Definition Language (CDDL) Grammar</title>

    <seriesInfo name="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="November"/>
    <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 in
RFC 8610
RFCs 8610 and RFC 9165, 9165,
provides an easy and unambiguous way to express structures for
protocol messages and data formats that are represented in CBOR Concise 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 for CDDL 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 reports and making
other small fixes for the ABNF grammar defined for CDDL there. CDDL.
The body of this document motivates and explains 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>The Terminology terminology 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 Changes based Based on Errata Reports</name>

      <t>A number of errata reports have been made around regarding some details of text
string and byte string literal syntax: for example, <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"/> needs need to be applied (backslashes have been lost during the RFC processing in some publication process of Appendix G.2, garbling the text explaining backslash escaping).</t>
      <t>These changes are intended to mirror the way existing implementations
have dealt with the errata.  They errata reports.  This document also use uses the opportunity presented
by
for the necessary cleanup of the grammar of string literals for a
backward compatible
backward-compatible addition to the syntax for hexadecimal escapes.
The latter change is not automatically forward compatible (i.e., CDDL
specifications that make use of this syntax do not necessarily work
with existing implementations until these are updated, which is recommended in this
specification recommends).</t>
specification).</t>
      <section anchor="e6527">
        <name>Updates to String Literal Grammar</name>
        <section numbered="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 ABNF from RFC 8610 ABNF for strings Strings with permissive Permissive ABNF
                 for SESC, but not allowing hex escapes</name> SESC (Which Did Not Allow Hex Escapes)</name>
            <sourcecode type="abnf"><![CDATA[
; ABNF from RFC 8610 ABNF: 8610:
text = %x22 *SCHAR %x22
SCHAR = %x20-21 / %x23-5B / %x5D-7E / %x80-10FFFD / SESC
SESC = "\" (%x20-7E / %x80-10FFFD)
]]></sourcecode>
</figure>

          <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 be
applying
applied here according to Bullet item 6 of <xref section="3.1" sectionFormat="of" target="RFC8610"/>).

(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 strings are do not using use 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 <xref target="e6527-new1"/>:</t> target="e6527-new1"/>.</t>
          <figure anchor="e6527-new1">
            <name>Update to string String ABNF in Appendix B of RFC 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:
        <aside><t>Notes:
In ABNF, strings such as <tt>"A"</tt>, <tt>"B"</tt> etc. <tt>"B"</tt>, etc., are case-insensitive, case insensitive, as is
intended here.
The rules above could, instead of <tt>%x62</tt>, also could 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 ABNF tool compatibility.)</t> tools.</t></aside>
          <t>Now that SESC is more restrictively formulated, this also requires an
update to the BCHAR rule used in the ABNF syntax for byte string
literals:</t>
literals is also required:</t>
          <figure anchor="e6527-orig2">
            <name>Original
            <name>ABNF from RFC 8610 ABNF for BCHAR</name>
            <sourcecode type="abnf"><![CDATA[
; ABNF from RFC 8610 ABNF: 8610:
bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
bsqual = "h" / "b64"
]]></sourcecode>
</figure>

          <t>With the SESC updated as above, <tt>\'</tt> is no longer allowed in BCHAR;
this BCHAR and now needs to be explicitly included; included there; see below.</t> <xref target="e6527-new2"/>.</t>
        </section>
        <section numbered="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 string literal, and literal; therefore, it should therefore be
excluded from BCHAR as it is from SCHAR.
The same reasoning also applies to the C1 control characters,
so the updated ABNF actually excludes the entire range from U+007F to U+009F.
The same reasoning then also applies to text in comments (PCHAR).  For completeness, all these rules should also explicitly exclude the code
points that have been set aside for UTF-16's UTF-16 surrogates.</t>
          <figure anchor="e6527-new2">
            <name>Update to ABNF in  Appendix B of RFC 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>

          <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 <xref target="UNICODE"/> that is not needed here.)</t>
        </section>
        <section numbered="false" numbered="true" anchor="addressing-err6526-err6543">
          <name>Addressing Err6526, 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>

        <t>The CDDL example in <xref target="string-examples"/> demonstrates various escaping
techniques now available for (byte and text) strings in CDDL.
Obviously
Obviously, 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>Example text Text and byte string literals Byte String Literals with various 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 identical content, where content: a to c are text strings, 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 CDDL example Example (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>
        <!-- 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 small changes change to the
grammar that are is intended to enable certain kinds of specifications.
These changes are backward compatible, i.e., compatible (i.e., CDDL files that
comply to with <xref target="RFC8610"/> continue to match the updated grammar, grammar) but not
necessarily forward compatible, i.e., compatible (i.e., CDDL specifications that make
use of these changes cannot necessarily be processed by existing implementations of <xref target="RFC8610"/>
implementations.</t> target="RFC8610"/>).</t>
      <section anchor="empty">
        <name>Empty data 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 8610 ABNF for top-level rule Top-Level Rule cddl</name>
          <sourcecode type="abnf"><![CDATA[
; ABNF from RFC 8610 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 to top-level Top-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">
        <name>Non-literal

        <name>Non-Literal Tag Numbers, Numbers and Simple Values</name>
        <t>The existing ABNF syntax for expressing tags in CDDL is:</t> is as follows:</t>
        <figure anchor="tag-orig">
          <name>Original ABNF from RFC 8610 ABNF for tag syntax</name> Tag Syntax</name>
          <sourcecode type="abnf"><![CDATA[
; extracted from the ABNF in RFC 8610 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 tag numbers, 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 syntax to:</t> to the following:</t>
        <figure anchor="tag-new">
          <name>Update to tag Tag and simple value Simple 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 <xref target="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.&lt;25&gt;</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>
       <aside> <t>Notes:</t>
        <ol spacing="normal" type="1"><li>

            <t>This syntax reuses the angle bracket syntax for generics;
this reuse is innocuous as because a generic parameter/argument parameter or argument only ever
occurs after a rule name (<tt>id</tt>), while it occurs after <tt>.</tt> the "<tt>.</tt>" (dot) character here.
(Whether there is potential for human confusion can be debated; the
above example deliberately uses generics as well.)</t>
          </li>
          <li>

            <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" value of the argument:
 for tags and simple values
 values, it is not giving the CBOR "additional information”,
 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 special case, however case; however, changing the grammar
now
in the current document would have been too disruptive.</t>
          </li>
        </ol>
        </ol></aside>
      </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
specifically apply.
Specifically, the potential for confusion is increased in an
environment that uses a combination of CDDL tools tools, some of which have
been updated and some of which have not 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"/> grammar handled in a less well-defined less-well-defined way, to the updated
grammar defined in the present document.  This transition might offer one, but one (but not the only kind only) type of opportunity
   for the kind of attack that relies on differences between
   implementations.
Implementations that make use of CDDL models operationally already
need to ascertain the provenance (and thus authenticity and integrity)
and applicability of models they employ.
At the time of writing, it is expected that the models will generally
be processed by a software developer, within a software development software-development
environment.
Developers
Therefore, developers are therefore advised 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 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 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 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
   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 extensions 9/5/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cbor-cddl-modules.xml"/>

<!-- [I-D.ietf-cbor-edn-literals];Waiting for
   text representations of epoch-based date/times and AD go-ahead as of IP 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"/>
          <refcontent>RFC 8610</refcontent>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9277.xml"/>

	<reference anchor="RFC9277"> anchor="UNICODE" target="https://www.unicode.org/versions/latest/" quoteTitle="true" derivedAnchor="UNICODE">
<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>
<title>The Unicode Standard</title>
<author>
<organization showOnFrontPage="true">The Unicode Consortium</organization>
</author>
</front>
          <seriesInfo name="RFC" value="9277"/>
          <seriesInfo name="DOI" value="10.17487/RFC9277"/>
</reference>
      </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 in as updated by the present document.</t>
      <figure anchor="collected-abnf">
        <name>ABNF for CDDL as updated</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 Covering Errata Report Erratum ID 6543</name>
      <t>This appendix is informative.</t>
      <t><xref target="Err6543"/> observes notes 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 8610 ABNF for BCHAR</name>
        <sourcecode type="abnf"><![CDATA[
; ABNF from RFC 8610 ABNF: 8610:
bytes = [bsqual] %x27 *BCHAR %x27
BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
]]></sourcecode>
      </figure>
      <section numbered="false" numbered="true" anchor="change-proposed-by-errata-report-6543">
        <name>Change Proposed By Errata Report by Erratum ID 6543</name>
        <t>Errata report
        <t>Erratum ID 6543 proposes to handle handling 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>ABNF definition Definition of WS from RFC 8610</name>
          <sourcecode type="abnf"><![CDATA[
; ABNF from RFC 8610 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>
      <section numbered="false" numbered="true" anchor="no-further-change-needed-after-updating-string-literal-grammar-e6527">
        <name>No Further Change Needed After after Updating String Literal Grammar (<xref target="e6527"/>)</name> Grammar</name>

        <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> <tt>bytes</tt> and <tt>BCHAR</tt> rules, as updated by
Figures <xref target="e6527-new1"/> target="e6527-new1" format="counter"/> and <xref target="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"/>) are therefore
applied 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 when copy-pasting copying-and-pasting into CDDL models from ABNF
that contains contain 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"/>.
(Note that that, at the time of writing, the processing of string literals now is quite similar between for both
CDDL and EDN, Extended Diagnostic Notation (EDN), except that CDDL has "<tt>;</tt>"-based end-of-line comments, while comments that are "<tt>;</tt>" based and EDN has
two comment syntaxes, 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"/> proposed to define  defining an
ABNF rule NONASCII, "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"/> (AD
review
Review and further guidance), and Éric Vyncke <contact fullname="Éric Vyncke"/>
(detailed IESG review).</t>
    </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=

-->
</rfc>