<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.14 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bormann-cbor-cddl-map-like-data-01" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.8.0 -->
  <front>
    <title abbrev="Map-like data in CBOR and CDDL">Map-like data in CBOR and CDDL</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-cbor-cddl-map-like-data-01"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
      <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>
    <author initials="B." surname="Moran" fullname="Brendan Moran">
      <organization>Arm Limited</organization>
      <address>
        <email>Brendan.Moran@arm.com</email>
      </address>
    </author>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization>Fraunhofer SIT</organization>
      <address>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="E." surname="Cormier" fullname="Emile Cormier">
      <organization/>
      <address>
        <email>emile.cormier.jr@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="June" day="01"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>The Concise Binary Object Representation (CBOR, RFC 8949) 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.</t>
      <t>Basic CBOR supports non-ordered maps free of duplicate keys, similar to the
way JSON defines JSON objects (RFC 8259).
Using the CBOR extension point of tags, tags for a selection of variants of
maps and multimaps have been registered, but gaps remain.
The present document defines a consolidated set of CBOR tags for
map-like data items involving key-value pairs.</t>
      <t>The Concise Data Definition Language (CDDL), standardized in RFC 8610,
is often used to express CBOR data structure specifications.
It provides "control operators" as its main language extension point.
The present document defines a number of control operators that enable
the description of CBOR data structures that make use of the newly
defined tags or that employ the same underlying structures.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>(See abstract for now.)</t>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t>This specification uses terminology from <xref target="RFC8949" format="default"/> and <xref target="RFC8610" format="default"/>.
In particular, with respect to CDDL control operators, "target" refers to
the left hand side operand, and "controller" to the right hand side operand.
The terms "array" and "map" (if unadorned) refer to CBOR major type 4
and CBOR major type 5; this is not called out explicitly.</t>
      </section>
    </section>
    <section anchor="cbor-tags-for-map-like-data-items" numbered="true" toc="default">
      <name>CBOR tags for map-like data items</name>
      <t>This document defines a consolidated set of CBOR tags for map-like
entities involving key-value pairs. These tags encode the following
meta-data concerning map-like data items:</t>
      <ul spacing="normal">
        <li>the homogeneity of the types of the keys, and of the types of the values;</li>
        <li>whether the order of the key-value pairs carries semantic value
("ordered") or needs to be ignored ("non-ordered");</li>
        <li>the uniqueness of the keys; and</li>
        <li>the major type used to encode the key-value pairs.</li>
      </ul>
      <t>Note that the term "ordered" as used in this document is distinct from
"sorted" -- "ordered" implies that the order in the data item
interchanged conveys a semantically relevant ordering, while a
property "sorted" can easily be established after interchange (by,
simply, sorting), less often needs to be indicated, and is more
complex to indicate as it may need details about the sorting.</t>
      <section anchor="summary" numbered="true" toc="default">
        <name>Summary</name>
        <table anchor="tag-new" align="center">
          <name>New CBOR tags defined in this document</name>
          <thead>
            <tr>
              <th align="left">Tag</th>
              <th align="left">LSBs</th>
              <th align="left">Homogeneous Value</th>
              <th align="left">Homogeneous Key</th>
              <th align="left">Ordering</th>
              <th align="left">Duplicate Keys Allowed</th>
              <th align="left">Data Item</th>
              <th align="left">Related Tag</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">128</td>
              <td align="left">0000</td>
              <td align="left">No</td>
              <td align="left">No</td>
              <td align="left">Non-Ordered</td>
              <td align="left">No</td>
              <td align="left">map</td>
              <td align="left">259</td>
            </tr>
            <tr>
              <td align="left">129</td>
              <td align="left">0001</td>
              <td align="left">No</td>
              <td align="left">No</td>
              <td align="left">Non-Ordered</td>
              <td align="left">Yes</td>
              <td align="left">array</td>
              <td align="left">TDB280*</td>
            </tr>
            <tr>
              <td align="left">130</td>
              <td align="left">0010</td>
              <td align="left">No</td>
              <td align="left">No</td>
              <td align="left">Ordered</td>
              <td align="left">No</td>
              <td align="left">array</td>
              <td align="left">TBD279*</td>
            </tr>
            <tr>
              <td align="left">131</td>
              <td align="left">0011</td>
              <td align="left">No</td>
              <td align="left">No</td>
              <td align="left">Ordered</td>
              <td align="left">Yes</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">132</td>
              <td align="left">0100</td>
              <td align="left">No</td>
              <td align="left">Yes</td>
              <td align="left">Non-Ordered</td>
              <td align="left">No</td>
              <td align="left">map</td>
              <td align="left">275</td>
            </tr>
            <tr>
              <td align="left">133</td>
              <td align="left">0101</td>
              <td align="left">No</td>
              <td align="left">Yes</td>
              <td align="left">Non-Ordered</td>
              <td align="left">Yes</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">134</td>
              <td align="left">0110</td>
              <td align="left">No</td>
              <td align="left">Yes</td>
              <td align="left">Ordered</td>
              <td align="left">No</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">135</td>
              <td align="left">0111</td>
              <td align="left">No</td>
              <td align="left">Yes</td>
              <td align="left">Ordered</td>
              <td align="left">Yes</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">136</td>
              <td align="left">1000</td>
              <td align="left">Yes</td>
              <td align="left">Yes</td>
              <td align="left">Non-Ordered</td>
              <td align="left">No</td>
              <td align="left">map</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">137</td>
              <td align="left">1001</td>
              <td align="left">Yes</td>
              <td align="left">Yes</td>
              <td align="left">Non-Ordered</td>
              <td align="left">Yes</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">138</td>
              <td align="left">1010</td>
              <td align="left">Yes</td>
              <td align="left">Yes</td>
              <td align="left">Ordered</td>
              <td align="left">No</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
            <tr>
              <td align="left">139</td>
              <td align="left">1011</td>
              <td align="left">Yes</td>
              <td align="left">Yes</td>
              <td align="left">Ordered</td>
              <td align="left">Yes</td>
              <td align="left">array</td>
              <td align="left">&nbsp;</td>
            </tr>
          </tbody>
        </table>
        <t>*TBD279: https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md</t>
        <t>*TBD280: https://github.com/ecorm/cbor-tag-multimap</t>
        <t>[The intention of the present document is to obviate the need for defining TBD279/TBD280.]</t>
        <t><xref target="proglan" format="default"/> provides information about constructs in a few programming
languages that are related to the tags being defined.</t>
      </section>
      <section anchor="keyvalue-type" numbered="true" toc="default">
        <name>Key/Value Type</name>
        <t>Bits 2 and 3 of the tag provide information on the map's key and value types:</t>
        <ul spacing="normal">
          <li>0b00xx Unspecified: There is no specified type for the map's keys and values</li>
          <li>0b01xx Homogeneous Key: All keys have the same data type</li>
          <li>0b10xx Homogeneous Key/Value: All values have the same data type in addition to all keys having the same data type (the types for keys and values may be distinct).</li>
        </ul>
        <t>The semantics for homogeneity shall be the same as for <xref target="RFC8746" format="default"/>
homogeneous arrays (tag 41). That is, "which CBOR data items
constitute elements of the same application type is specific to the
application" (<xref section="3.2" sectionFormat="of" target="RFC8746" format="default"/>).</t>
        <t>Maps with arbitrary keys and homogeneous values are considered
unusual, so they are left out of this specification so that fewer tag numbers
need to be allocated (12 instead of 16).</t>
      </section>
      <section anchor="ordering" numbered="true" toc="default">
        <name>Ordering</name>
        <t>Bit 1 of the tag represents the map's ordering semantics:</t>
        <ul spacing="normal">
          <li>0: The order of key-value pairs is unspecified</li>
          <li>1: Key-value pairs are encoded in the same order in which they were inserted</li>
        </ul>
      </section>
      <section anchor="key-uniqueness" numbered="true" toc="default">
        <name>Key Uniqueness</name>
        <t>Bit 0 of the tag represents the uniqueness of the map's keys.</t>
        <ul spacing="normal">
          <li>0: Keys are unique within the map</li>
          <li>1: Keys may be duplicated (i.e., multimaps)</li>
        </ul>
      </section>
      <section anchor="data-item" numbered="true" toc="default">
        <name>Data Item</name>
        <t>All these map-like data items could be represented as a tag with an
enclosed array of alternating key-value pairs, as
in:</t>
        <sourcecode type="CBORdiag">
129(["key1", 1, "key2", 2])
</sourcecode>
        <t>However, representing the key-value pairs as a CBOR map
for those cases where this is possible enables generic decoders that
are oblivious of these tags to represent the data in a more
appropriate platform type.</t>
        <t>Specifically, the key-value pairs are represented as a map if and only if</t>
        <ul spacing="normal">
          <li>the ordering is unspecified and</li>
          <li>the keys are unique;</li>
        </ul>
        <t>otherwise, they are represented as an array of alternating keys
and values ("flattened alist", see <xref target="falist" format="default"/>).</t>
        <figure anchor="falist">
          <name>CDDL for order-preserving representation of maps</name>
          <sourcecode type="cddl">
FAList&lt;K, V&gt; = [* (K, V)]
</sourcecode>
        </figure>
        <t><strong>Issue</strong>: <xref target="MAPREP" format="default"/> discusses alternative representations of
(ordered and other) maps.  How much of this do we need to address here?</t>
      </section>
      <section anchor="related-tags-informative" numbered="true" toc="default">
        <name>Related Tags (Informative)</name>
        <section anchor="tag-259" numbered="true" toc="default">
          <name>Tag 259</name>
          <t>Specification: https://github.com/shanewholloway/js-cbor-codec/blob/master/docs/CBOR-259-spec--explicit-maps.md</t>
          <t>The above defined tag 128 may be used instead to guide a JavaScript decoder into interpreting a CBOR map as a JavaScript Map instead of an Object.</t>
        </section>
        <section anchor="tag-275" numbered="true" toc="default">
          <name>Tag 275</name>
          <t>Specification: https://github.com/ecorm/cbor-tag-text-key-map</t>
          <t>The above defined tag 132 may be used instead to guide a decoder into interpreting a CBOR map as a JavaScript-like Object having only text string keys. The decoder would have to verify the first key to establish that the map has homogeneous text string keys.</t>
        </section>
        <section anchor="tag-tbd279" numbered="true" toc="default">
          <name>Tag TBD279</name>
          <t>Draft specification: https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md</t>
          <t>The above defined tag 130 may be used instead to encode map-like data items where the
order of the key-value pairs is semantically significant.</t>
        </section>
        <section anchor="tag-tdb280" numbered="true" toc="default">
          <name>Tag TDB280</name>
          <t>Draft specification: https://github.com/ecorm/cbor-tag-multimap</t>
          <t>The above defined tag 129 may be used instead to encode a multimap as an array of key-value pairs.</t>
        </section>
      </section>
    </section>
    <section anchor="cddl-support-for-map-like-data-items" numbered="true" toc="default">
      <name>CDDL Support for Map-Like Data Items</name>
      <t>The Concise Data Definition Language (CDDL), standardized in RFC 8610,
provides "control operators" as its main language extension point.</t>
      <t>The present document defines a number of control operators that enable
the use of group notation (enclosed in a CDDL map) to specify any of
the above map-like data structures:</t>
      <table anchor="tbl-new" align="center">
        <name>New control operators in this document</name>
        <thead>
          <tr>
            <th align="left">Name</th>
            <th align="left">Purpose</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">.omm</td>
            <td align="left">Ordered (Multi-)Map</td>
          </tr>
          <tr>
            <td align="left">.nomm</td>
            <td align="left">Non-Ordered (Multi-)Map</td>
          </tr>
          <tr>
            <td align="left">.unique</td>
            <td align="left">Uniqueness requirement</td>
          </tr>
        </tbody>
      </table>
      <section anchor="map-notation-for-map-like-data-items" numbered="true" toc="default">
        <name>Map notation for map-like data items</name>
        <t>[needs better examples]</t>
        <t>CDDL already can describe both arrays of alternating keys and values
and maps (non-ordered and with unique keys).  The two control operators
<tt>.omm</tt> and <tt>.nomm</tt>
introduced in this section enable the use of CDDL map notation for
map-like types beyond actual maps, increasing readability and possibly
even reusability.</t>
        <t>In a simple example that provides an non-ordered collection of zero or more
home addresses and zero or more work addresses, each labeled as such,
we use traditional map notation to describe that collection:</t>
        <sourcecode type="cddl">
[* (text, any)] .nomm {
  * home: address
  * work: address
  $$more-addresses
}
</sourcecode>
        <t>The <tt>.omm</tt> and <tt>.nomm</tt> control operators convert a group definition
enclosed into a CDDL map given as a controller type into an array type
given as the target type.
The controller type given is unwrapped (<xref section="3.7" sectionFormat="of" target="RFC8610" format="default"/>) into a
group.  Keys and values of the entries in that group are then alternatingly
matched as elements in the target array.
Note that both target and controller type can contribute to the
shaping of the data; declaring the key type as <tt>text</tt> limits what can
be added to the <tt>$$more-addresses</tt> socket.</t>
        <t><tt>.omm</tt> and <tt>.nomm</tt> differ in the semantics of the array type created:
<tt>.omm</tt> defines an ordered (multi)map, i.e., the order of the key/value
element pairs in the array matters, while <tt>.nomm</tt> defines an non-ordered
(multi)map, i.e., data items that present the same set of key/value
pairs in different orders are equivalent.</t>
        <t>The ability to specify specific ("homogeneous") types is
provided by the ability to specify the target type, as in the example above.</t>
        <t>Note that there is not strictly a need to define a control operator for building
non-ordered maps with non-duplicate keys, as existing CBOR maps already
fill this role, however the use of a map type as the target is allowed for symmetry
(implying uniqueness of the keys), allowing the following:</t>
        <sourcecode type="cddl">
{* text =&gt; any} .nomm {
  ? home: address
  ? work: address
  $$more-addresses
}
</sourcecode>
      </section>
      <section anchor="uniqueness" numbered="true" toc="default">
        <name>Uniqueness</name>
        <t>The <tt>.unique</tt> control annotates the target as requiring uniqueness,
within the enclosing container(*), of its value, among the other data
items in that enclosing container that are also marked <tt>.unique</tt>,
under the same label (given as the controller).</t>
        <t>E.g.,</t>
        <sourcecode type="cddl">
feature-set = [* feature .unique "set"]
ordered-pairs-with-unique-keys-and-values =
  [* (any .unique "key", any .unique "value") ]
</sourcecode>
        <t>defines a <tt>feature-set</tt> as an array of zero or more <tt>feature</tt> values
that need to be all different (as they are unique under the label <tt>set</tt>), and
<tt>ordered-map-with-unique-keys-and-values</tt> as an array of zero pairs of
keys and values, where the keys need to be unique among themselves and
the values need to be unique among themselves (the latter example
could employ an <tt>.omm</tt> or <tt>.nomm</tt> operator to further restrict what can
be in these keys and values).</t>
        <ul empty="true" spacing="normal">
          <li>Discussion: (*) while it is probably not a big problem to define
what exactly the "enclosing" container is, it may be useful to
actually define a larger scope of the uniqueness.  CDDL currently
does not have a way to establish and point to such a larger scope;
we might define one ad hoc here or leave that for later extension.</li>
        </ul>
      </section>
    </section>
    <section anchor="cddl-typenames" numbered="true" toc="default">
      <name>CDDL typenames</name>
      <t>For the use with CDDL <xref target="RFC8610" format="default"/>, the typenames defined in <xref target="tag-cddl" format="default"/>
are recommended unless there is a need for more specific shaping of
the data.</t>
      <figure anchor="tag-cddl">
        <name>Recommended typenames for CDDL</name>
        <sourcecode type="CDDL">
anymap = {* any =&gt; any}

tbd128 = #6.128(anymap)
tbd129 = #6.129([* (any, any)] .nomm anymap)
tbd130 = #6.130([* ((any .unique "mm"), any)] .omm anymap)
tbd131 = #6.131([* (any, any)] .omm anymap)
tbd132&lt;k&gt; = #6.132({* k =&gt; any})
tbd133&lt;k&gt; = #6.133([* (k, any)] .nomm anymap)
tbd134&lt;k&gt; = #6.134([* ((k .unique "mm"), any)] .omm anymap)
tbd135&lt;k&gt; = #6.135([* (k, any)] .omm anymap)
tbd136&lt;k,v&gt; = #6.136({* k =&gt; v})
tbd137&lt;k,v&gt; = #6.137([* (k, v)] .nomm anymap)
tbd139&lt;k,v&gt; = #6.138([* ((k .unique "mm"), v)] .omm anymap)
tbd139&lt;k,v&gt; = #6.139([* (k, v)] .omm anymap)
</sourcecode>
      </figure>
      <t><strong>Issue</strong>: fill in better names for tbdnnn</t>
      <t>Note that there is no need to call out the uniqueness of the keys
explicitly in tbd128, tbd132, or tbd136, as the use of maps as a
representation format already provides that key uniqueness.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="tags" numbered="true" toc="default">
        <name>Tags</name>
        <t>IANA is requested to allocate the tags of <xref target="tag-new" format="default"/> in the CBOR tags
registry <xref target="IANA.cbor-tags" format="default"/>, using this document as the specification
reference.</t>
        <t>The allocations are requested to be assigned from the "specification
required" space (24..255).  The values in the column labeled "Tag" in
<xref target="tag-new" format="default"/> are suggested as the allocated tag numbers.</t>
      </section>
      <section anchor="cddl-control-operators" numbered="true" toc="default">
        <name>CDDL control operators</name>
        <t>This document requests IANA to register the contents of
<xref target="tbl-iana-reqs" format="default"/> into the CDDL Control Operators registry <xref target="IANA.cddl" format="default"/>:</t>
        <table anchor="tbl-iana-reqs" align="center">
          <name>New control operators to be registered</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">.omm</td>
              <td align="left">[RFCthis]</td>
            </tr>
            <tr>
              <td align="left">.nomm</td>
              <td align="left">[RFCthis]</td>
            </tr>
            <tr>
              <td align="left">.unique</td>
              <td align="left">[RFCthis]</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="implementation-status" numbered="true" toc="default">
      <name>Implementation Status</name>
      <t>TBD</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security considerations</name>
      <t>The security considerations of <xref target="RFC8610" format="default"/> apply.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/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">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <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>
        <reference anchor="RFC8746" target="https://www.rfc-editor.org/info/rfc8746">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags for Typed Arrays</title>
            <author fullname="C. Bormann" initials="C." role="editor" surname="Bormann">
              <organization/>
            </author>
            <date month="February" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR), as defined in RFC 7049, 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.</t>
              <t>This document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays.  It is intended as the reference document for the IANA registration of the CBOR tags defined.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8746"/>
          <seriesInfo name="DOI" value="10.17487/RFC8746"/>
        </reference>
        <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">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <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>
        <reference anchor="IANA.cddl" target="http://www.iana.org/assignments/cddl">
          <front>
            <title>Concise Data Definition Language (CDDL)</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA.cbor-tags" target="http://www.iana.org/assignments/cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="MAPREP" target="https://mailarchive.ietf.org/arch/msg/cbor/5MuDSyPivZ7JfPhsfwCaW2usFHQ">
          <front>
            <title>Re: [Cbor] "ordered hash"</title>
            <author initials="C." surname="Bormann" fullname="Carsten Bormann">
              <organization/>
            </author>
            <date year="2020" month="July" day="30"/>
          </front>
          <refcontent>cbor@ietf.org mailing list message</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="implementation-considerations" numbered="true" toc="default">
      <name>Implementation Considerations</name>
      <t>This non-normative appendix provides information about the use on
implementations of the tags and control operators defined.</t>
      <section anchor="proglan" numbered="true" toc="default">
        <name>Programming Language Containers (Informative)</name>
        <t>The following subsections describe how the tags in this document relate to various programming language containers. Containers that are not part of the programming language or its standard libraries are not considered here.</t>
        <t>The <em>Encoding Tag</em> column in the following tables provide the recommended tag that best represents the given container type. For example, it's possible to
use tag 132 for encoding an ECMAScript <tt>Map</tt> if all keys happen to be of the same type, however tag 128 is more general and applies to any <tt>Map</tt>. When encoding
an ECMAScript <tt>Object</tt>, tag 128 would be technically correct but is too general; tag 132 best presents the fact that an <tt>Object</tt> has text keys only.</t>
        <t>The <em>Decodable Tags</em> column in the following tables, are for data items can be decoded into the destination container without having to inspect the following:</t>
        <ul spacing="normal">
          <li>the uniqueness of the keys,</li>
          <li>the ordering of the keys, and,</li>
          <li>the data types of <strong>every</strong> keys/value pair.</li>
        </ul>
        <t>It may however be necessary to inspect the data types of the <strong>first</strong> key-value pair in the case of tags representing homogeneous keys/values.</t>
        <section anchor="ecmascript" numbered="true" toc="default">
          <name>ECMAScript</name>
          <table align="center">
            <thead>
              <tr>
                <th align="left">Container</th>
                <th align="left">Encoding Tag</th>
                <th align="left">Decodable Tags</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>Object</tt></td>
                <td align="left">132</td>
                <td align="left">132, 136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Map</tt></td>
                <td align="left">128</td>
                <td align="left">128, 132, 136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Array</tt> of pairs</td>
                <td align="left">131</td>
                <td align="left">All</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="python" numbered="true" toc="default">
          <name>Python</name>
          <table align="center">
            <thead>
              <tr>
                <th align="left">Container</th>
                <th align="left">Encoding Tag</th>
                <th align="left">Decodable Tags</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>TypedDict</tt></td>
                <td align="left">136</td>
                <td align="left">136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>namedtuple</tt></td>
                <td align="left">132</td>
                <td align="left">132, 136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>dict</tt></td>
                <td align="left">128</td>
                <td align="left">128, 132, 136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>OrderedDict</tt></td>
                <td align="left">130</td>
                <td align="left">130, 134, 138</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>list</tt> of 2-tuples</td>
                <td align="left">131</td>
                <td align="left">All</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="c" numbered="true" toc="default">
          <name>C++</name>
          <table align="center">
            <thead>
              <tr>
                <th align="left">Container(s)</th>
                <th align="left">Encoding Tag</th>
                <th align="left">Decodable Tags</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">
                  <tt>Map&lt;K, T&gt;</tt></td>
                <td align="left">136</td>
                <td align="left">136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Map&lt;K, D&gt;</tt></td>
                <td align="left">132</td>
                <td align="left">132, 136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Map&lt;D, D&gt;</tt></td>
                <td align="left">128</td>
                <td align="left">128, 132, 136</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>MultiMap&lt;K, T&gt;</tt></td>
                <td align="left">137</td>
                <td align="left">137</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>MultiMap&lt;K, D&gt;</tt></td>
                <td align="left">133</td>
                <td align="left">133</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>MultiMap&lt;D, D&gt;</tt></td>
                <td align="left">129</td>
                <td align="left">128, 129</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Sequence&lt;Pair&lt;K, T&gt;&gt;</tt></td>
                <td align="left">139</td>
                <td align="left">[136, 139]</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Sequence&lt;Pair&lt;K, D&gt;&gt;</tt></td>
                <td align="left">135</td>
                <td align="left">[132, 139]</td>
              </tr>
              <tr>
                <td align="left">
                  <tt>Sequence&lt;Pair&lt;D, D&gt;&gt;</tt></td>
                <td align="left">131</td>
                <td align="left">All</td>
              </tr>
            </tbody>
          </table>
          <t>Legend:</t>
          <ul spacing="normal">
            <li>
              <tt>K</tt>: Static key type</li>
            <li>
              <tt>T</tt>: Static value type</li>
            <li>
              <tt>D</tt>: Suitable dynamic type, such as <tt>std::any</tt> or <tt>std::variant</tt></li>
            <li>
              <tt>Map</tt>: <tt>std::map</tt> or <tt>std::unordered_map</tt></li>
            <li>
              <tt>MultiMap</tt>: <tt>std::multimap</tt> or <tt>std::unordered_multimap</tt></li>
            <li>
              <tt>Sequence</tt>: Sequence container that maintains order (e.g. <tt>std::vector</tt>)</li>
            <li>
              <tt>Pair</tt>: Object containing a key and a value, such as <tt>std::pair</tt>, or <tt>std::tuple</tt>.</li>
          </ul>
          <t>Note that a C++ <tt>std::map</tt> stores its key-value pairs in a sorted fashion, and
does <strong>not</strong> preserve insertion order in the same manner as Python's <tt>OrderedDict</tt>.</t>
        </section>
      </section>
      <section anchor="cddl-implementation-considerations" numbered="true" toc="default">
        <name>CDDL Implementation Considerations</name>
        <t>TBD</t>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t>The CBOR tags defined in this document were developed by Emile Cormier
under the sponsorship of Duc Luong,
based on discussions with Kio Smallwood and Joe Hildebrand.
The CDDL control operators defined in this document were developed by
Carsten Bormann, Brendan Moran, and Henk Birkholz.</t>
      <!--  LocalWords:  dedenting dedented
 -->

</section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="K." surname="Smallwood" fullname="Kio Smallwood">
        <organization/>
        <address>
      </address>
      </contact>
      <contact initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
        <organization/>
        <address>
      </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHRStmAAA7Vc63Ibx5X+30/RgVIVkAFAAqQuhCzFFCFHsklJEeWkElll
NjANYMzBDDIXUjBFVx5kt2p/7JPsvkmeZL9zunumZwCKjOJl2SLQ05fT534b
drtdkYd5pIfyqZDyRC27UXiuZaByJcNYHj17/VaqOJBHo9GxUONxqi+Gt00L
kkmsFtgySNU0746TdKHiuDvBh+4kCKLuwq7v0vpupHKd5QKfsWSwO+h3dx90
d/tCZDm2/FFFSYwHeVpoIcJlyh+zfLC7e7A7EOd6dZmkwVC+jHOdxjrvjuhQ
MVH5EJBNEyGW4VC+z5NJR2ZJmqd6muHTamE+TJLFUk1y/rDQcZ59EEIV+TxJ
h8BHF/9LaS5zpNIs17F8Zq7DT5J0NpTfx+GFTrMw/9//zuWzVGMb+e5vL3lC
hvM0IHmTZPlUTeZyb293f3+Xn03CfDW0C8xAEuCcUXfwaO/+gR0p4jzFrD9q
OnTFg8s5I+T3+wfdfSBr0H/UfbB3MOjzQ71QYTSUEzVOvs5/DnuAkMfThGis
gzBP0vJi5d0ARByoWJ4kqYrdIyxVcfizysMkHsrDdCGPw0WY68BNsGfZxT1e
/LVKFz3gcv2MFzo+l8/C9HyeRD9vPuObVBXxPJnqVJ6+fNc4Zo71vbFd/zXQ
3ZuW03uBpgPtSc8XYaTlEegU6tTHiqYHgI4f9H5Kv57ROIMrJgkwHY6LnCnv
tvouTOTpQkXRZZIE1fC3iZYvwijQY1w5ECImnsjBBsQ0b785evSgvwsigNft
94f7D4ZSpala2YGD/QNMGDMxXh6+OuzRZIwQFElUDpLI5GqWgenxryCG9k46
OXzz9vmbIV8xV+mMOG2e58tsuLNDN1PpZI6pvVDnU+KEHRrYWWSzHdp45/5J
MTpdvQkv/vbw2+mbeTa9PFJ/GRTZNy/+xFtWckA/3c/IgadC6OctPr8/whEf
ZAvCqVMdyLnK5i1+Xgr6bnf3YXfPCAOkke4OCay2ISC/drBLulAYz2QUZrlc
6CxTMyiEbrcr1RhiBiEW4t2c6B5PwkyD1WKVruTr8U96kgOkZaozbM+sJtuk
sTpECUmk2JJhJhWrM2EwLC/nCTYJdBbOYjlLVJRBnUyiItAyxynLJMvCMSDK
VzKZSv0xJzmOVjIjbhEkyjILf9YdOVVh6sYd3PYRaUys1HG51WUIlBc5HSFi
DbQBGsnaBUDHepbkIV+gJ8QzlYUTo3mzYrmEastknMRdh3Ao2UxOoX4IvqBY
RiF0opZQmKT/IMlgD5knfNSlWslvT1+/wn2nYawz8yVh1GWyzWga3D/Y6onv
M6IBYYBPttADuGUSxjkdRYza4X8ZeCUzHWEbmoOnFyoNFdQsPguGkHCwKKI8
5G9zdaHlWIO9Uj0DoekmHQmplDN6nJIg4/JEZ0tPCWtTLPiDhV2RFGVJFBKj
BTiewWJwHVRiUbdguV4QeS+S6IKuBxx1L1RU4BAQL+vVGWtES0Z0WMi3Olbx
rCCitsn6bQG5ZLdUGoDGAVlHRh80QkeEdG8SniLDIyBff6RrZAY6hgWsXEzy
IgWPLPUknBLVcAqAeJnjzslFCJ6ULasoZLLUqYLOylpS4QpALGFIRg6mBoFu
RV1cLMZQv0DY2gmgOuRCx2ocaUEcAEAmabh0pN1wB7tmoYBpXJnZAwtjfRmt
hDk0MEQBp5jtF8soWfGsDOpGFjG4OVoRVapdQRAW/EUIpQklcI+sf5oEhWEz
+3N1L6TRayHap5ACpyWYK+PksrcFssKshnESJbMVbeh+DL3BBZJ8C2D75PvT
d62O+S1fvebPb5//6fuXb5+P6PPpi8Pj4/KDsDNOX7z+/nhUfapWHr0+OXn+
amQWY1TWhkTr5PCvLaMeWq/fvHv5+tXhcYs4KZ+Dg0qqKTAJeGis8QiSAqoS
v6tMGMKMDfc9O3rzP//V35dXV78BIw76/YPra/vlUf/hPr5cwrSa05IYmsp8
BQVWQi2XGloCu5DymqhlmEMRdojVsnlyGcMop5qo8Y4AqzEs0RvkrxAMXZQs
cDD7gTiVzqNvIOH1NbgbHKrSPJwU0EsdVoQQd9oyp0uSaK2zJLBn7F6LDIgm
Hk2YNSM9zaFMcEQGeTEL4sCi1G4T6bRlFaBMw9l8wwIjLnQJMAGb75bZAvqj
JdvhFPypggR+Z7BlIGBYSRAW6ifi6dVSy33BrnFj9P5jQ86Q1HYO5AIgUACq
DkoByhomdUWovVdXXXKD6rL4/xJNWG4nsBD6TH9OD0pgA1LMa3XMNo6QNwUu
k0ssEAsNf57hwsET+OO0ywaAh5BfXjpPFslMx9qaURoi5GTui7FWzJobnjJs
2WPsBZ7FQMqjbAC9DfwrAM1pSpfMYElw4YnZAw5H23kqrS1SRmR8MyddM/h3
wF+75dnX1tZje4ciDv9e4A5ZDerHBLWd4VG9VPwV+tatzask10Yd5pb9Sj+K
1TxvsqYO6DNMJryUnGVNtCjeoSVQldX6EBo2dJq5whdv59FIsE6ZQCRmOAzk
vMCl2JobxIFdV2D5SF8osvu0B4gNwZ2T860ETBVkCGQtoZggwNBwWrAOSEXI
B0MSZnNSWbCJqfQOlO3xqiMyAnVlwjbsDcsaGSSTBa0RKA7YubECDkQsQDBB
sV2kP9IkN8MYSRBkxRtAUnK4lbjX2Hpd7jBQ4d49eVosFnAihfgk36mZ/CSP
T59l+PXCsm1SZPLPTLr62HcwHZ/ka4sUMkaf5Kh0wb4jTB6SzACCT8afeAmU
4/NbHbGo8mk4lawc/+t+lT/S7PqZkeZzf6o/rb4JndofPMLoLn7w61UiGz/r
YzQSd19bz3PTGjsNuqD8DIeyesKnHphT+1946l/B1RtPZc1tP78bPRs82t2u
Tt3b5VP7d7+rO3Hz882nPhsNHh74p/bNqXe/a/3UO9219oRPHdCp/Rvp2tz1
y+j68H7j1D1z6k13ve3UL7zrPp96I13XT/0Cuq6fet+ceve7/ip0fYDRvpHX
9R1+Jbqun/rQnNr/wlO/8K6P+NT+3e/6q9D1wJx697v+23S9Gsp7cLW6iJZM
guVJ6xU+Vu6bC6CankALIc+20ThVPmgGh7oYU65r51Sf6zjVnARy7gznZMnb
3hlHyXhnoSj23qGzfrQX+fFELXuLwG79aHfj1pqSazsubdV1gb0QP7wnTzrk
DI+NF/NNkWjINj0ZX4Qq1zZYtGkQvi6ZU3O1HQNG74MQV1fwNmaIeRFWlCFy
mSvDaca8kzPMMWTGEY2cApu0MFWLBXmvLmi2vhGFV6m1xzZMYLSPNQFhkW/8
BFj0HeMHvIOTJ8QzCsQH7IzslZ4rTLoFrgZbElsfcfm7jGNOWmX8QXZ22Vfe
He/ufvwov49tjKWDITnjgJDDB1kOGy9zmqT1TbNq18xs18d2DZdlSE6Jmc15
mDIIZ6eQNual/d31peb2ZgNzyk1bMOqDwKROgFblHelSS40V7crxp4s1rsPO
HJxA5/tu2XSNc1TNIj/QyOZ06NiDTplJV1c2V3t9LebeBVlGM8ABEu73tygO
UsSqCD/h7k7mXurDxGPMaWFegIXhIXNdwbGBOW9pfEHGASOlip5dTs6bg1Dz
6urUJtH2egPaq4SU7ntCyTEOmVU6DvOUEp8lmvybWJQRaxOMIUu2KOIiK1RE
njbH/fycQ2gSGwZ8LbznqcAChIjiLmDGpI4yk7c0jjnwnLBjLtv9ASgPpaI4
lOs/2DKS43xklhnZ94UldSnbzONlF2hU5DXyweJQhX7NsA/gF5XsYEF/SGxb
m0OXNmFZ4KIhJlYZHxlaM4IuWfTiTFNo41QAVYJsJGius/uZ66xHjZWw9uyV
OFAgsMxkpnBYqovyFpUIuBAD+A57utepMqtbDGQZaghBkppzOL8pFzpJiiig
LUuoObMEpUlXMZwWC2ArSigWNUYM91ARVeFUviF7QFkjBJUg1y+//EICE4Rq
JuD0t9+3MLXf6sg+BAofB/g4+LBF84R4gSjpQqedChKnJZo0ZvBslmUpjAqk
HP5EUSbqkrWly7iY9H2kbTozkyQgKYQv0MQANtkpCPcJotSLkITH0MklQMDh
JUhe6EyGhaNPyC9C4JTt2BJWhDQ+Czuoe+pEKaL4duNl0g24J28snFaZunDq
8iilWNQZ3ctBnNd56bEQCWVMLsNMdyqhbx4Z30jaTHgquP3Pf/zHFHeEdaeF
VKL55z/+E/pEayjVKQ8YTQWamrrYN4fHGPzqu47881P5RL7flm36vPWByU6+
j1nmXB9OABJR+apdBjNli5HWSzsAlRienaDtl1lW6O3tIaAwxTJ4CDAUkyIj
niivdKEbu3B9ou1KKYxwwtYWb92TMH+XkC1oA6ccgwQ6QTrVBwPHaX3iuT+w
5HmBPdD1sqrjsWDe44AfAbHHGqYkusHHgvmCSzjnpJta7fyU2co6+LbuvcGp
ytiF62Jndu66XZdb7PJFyJ0jvQn/6EJLLyHPKQCrVWy2yehuXG5WkAuj5Lfq
Qp1yAcBJDfl3SZWMJuJUEmlY2Ft0QtxcmQTwmqnV9TyMPLx/F4w0vM5cf8y7
JFDsed5wP4TCt9zvSy5lFKmtOVqPhkWVYKIKhpMezqWWR1yyujUeU0L1vnBq
aiBT6IKcvULKGbqUWZW7IxDmgMG38WtHVfg0nrPEVyG4T6Ju1P8/ooWb0L97
E/ptZnSTVXI6XIvP5njDrJ6lpBIu3zH2ecskgv41XNwY3twkRAe33FKVFrqp
btezwoJV4Kmp9bIqpD6cY8JRadcz8cT7+dXqlr9C3fHXLDzaUuIsTYolFU9s
Tb90R9gIM7aA2C1CtyEtxVaEXN7EkKvOZlWJcUg531fk/nFk/qZIl+RLNMN3
TOoli0U94m+fEE27WycmecKT4nKWnwOpzeR51tP75PmSME1/L0JuE8pdWmAc
NdMC61jblBYA79NZJc5uLCj98N4k2Mc6p9y8/qgol07dUYxXFaVg5BXn9F21
UY4TDkA4VtrgMPghKFf9KWhp+y0LNMq+pcUCrUK0xaoyv0zW7yjOCPtnvPCM
cXwmQlsK9hIjmQ2dDAtJj4Uck9QwUnUHmKBzrFcJDlDgDBUx2B3qBUmpmMH+
hwqU7d8gQKxvuRLwW6mPocjsUwjBS+JMrmtoh1PD3aWEAaE+SiZUpyy7J37W
aULVKXYwofO18zS0wa7/nGrX59XzjtTUfxapsY6Mc5fBf+mIS4MLxIwmJjc3
rPAB4SkJzJBWEBlXnr05ct/I7lABZrX1wfL7lZBym2yTHjpAeIQg80d++1sC
uFvCKq6N7090X6fwBlbn8hSUorI6ISi1nPCUAjlmFcVnIZFH2SqpLQi7FAVN
dcqYEx/lbBPOUc3ZOvMEZHMDM5t98cuUiuhBPYJ/6CJ4aFf4xfZAwcCD379r
ZDisndPUoaatYIMS5q7KmMTYlzcwH7zLydwQukxB2NjRgs+363nFRpZf9zAO
1m5Fwl62yWmXp4A7umQ3Z1pGQY/JsYlU6kVqZgcAc0ZsciYjaiUki04chVBy
zKxcZdrOmjxxJrNkcq7JkmxgiSCcTqsiZpX6sUBVhJQktnDEh26X0gLF0slc
m23yFpgEcs5h9Kay8o6pHFvkOtcj9s5bUEBEga+piZawVid6ki7WT/U8H6sj
qmCTMxO2oF8BUwJh8KFdZdYmN2BGME+X5thpLc9AllmodsvzKVtbVhWGmfMF
Ajk2LuqGTRoywv0iFjNO6bH1bZa6XTrTuK+THL6bKmMqg7ZKWkvxZyM2LsIo
oDzSWgscGxQabfbAkWR85KThrPTnM2fZxDTkBAngodbZDrQY5yF842ECcsfY
3qWpmdCWdwm2bLVY6DxdiTYXtOm8zT0D8MGUbaWoN1Z4mvZq2zj4T56Sqr32
NO0f1jTtH+6saeEX+Mkro3gNkJW+VTFbBV27q3L+Sf1aMCxVssroYJpAW8FP
1Gl7G5fF1UkJMO/i6ovE3ptjbdON6VrznA+4tlGVq1dRloAi6bkOKuA7gjvI
KplhAyjbNX1eKTpKUTzvzXqdCuFT6At4hF0SNs5T2IHSV2vhSeuDcKERy2CX
bt81EygUzbrQVl2rzp+AEGQwyRktN8Ekbvnyhng6RM+kRETlK595MJ01A4ea
D+BmnjnHi7FVz9B6yqJtELLyk44V/gzqzujQLe60EGd+PPiZK28G0mgruOMN
77BTBXrGcfTgtUCVvLLIdHRhvB9RtQTdZUXbXMl3b4VJe9oeRMBrbQSw6ZR3
qXSw+bRImVEhSqyuatbMsH6mm64vcdhTOTI5KI4zIQrWQoSsOqBgx/BTV6wI
lRyHXDeC47qo1CC24MMAOKtJukurlI6WJx5UpbAdLyYMnRYRdck9tf4sFpea
NSKRhr6a4JZOL1UiDcfEdOEVKTELfIyniC20Udicu1CSGolrmQrjEFNrMNkH
ypjVj3lMN0EYxv13FpCEgKG6xYQTaIT+SJtqkjKBL+XS0irGLINj0sXUpe6H
wUJ8k1Rqm60Bzy17DztlYxkv9cuqV1cU5ptpwuRHzXsiZP+KmNuRSrulqlIl
y15pSisPSTgPyWZCzVs18YrsyBMJ1U7ybzW7EPk4oDTcE3nvQQ8f2mbilhk/
cOMHbatL6r63P3lv107e2+XJdc2zWLS2yrVrS/tuaX/tnLW5g6/On7rpgzau
c+4uYyfseRP2eL/zz0C9783eN4Cf3xXs+97a+42T1iY/+Oq8c1FOf1BCfuHg
flib8NDtd7EZ7oPa7Ec3QH6xEZT62oPaSf5klyR3/OlSAW89Bq1YmniSeK2R
FGcfB2xug/xqLkCJ4/gG76xUrpRdk65vbrNHI6peVtaIzNEdabilI81RQHnH
mWLrWhlXDP+JRnbfvp3h8g9l2MxAUpzh6SuE24evDin/xYVOk9ivJcichjAp
QTg+ZkVofBpoMZvOt2XMqgcAIBrdEOvL62vn3JatGcK8vZCuSMvQAGmZwr46
UWvhNreuZR4FNxJDmWvnppvjuSxhlJAHG9nwjDKcpHqow5pNQXNDTiAFLRyk
Jlq2B/u93uD+fZdbsUbT3gIBfrGIy0xBC5ih5nPhX5jAyIrZzIBhb1FVe71y
MLcw37uhf7vZuGxvlvHbT6bCZt4CKd00W0onYMZRN1Sx6mJRxjSwoSMfdWSP
el3mCHySWECurxtpvrcO843M3nvE6kS4D81kXuNBmb3zx13CrgT282k7Q9Pq
9ReS2ZfknSxKITjF72ITJ5uc77OREKcaZprCsslt3O9lirPNiwy3WzPIvQuU
yqJm0bGanPPrF3X4GhJniEwhWPmeHO0CJRV+/Fy/TqkPYhHWDihVDMuil6rw
0Fjrz3lTdflUae8j5yM1CnLy6p5rJzJoKcMwsPzY5hKzKiuGyLACZq0r23QQ
cVlHpVxG9lqOqnx56bDBzfIAK4Mb8rHo/YiqcWrDJlCnFE+5PL6MwnGqOGXk
tqiaPtyrG3TB7edUjeDWKjXbdgrAqoPq9rkplbsmJnro+0Mk9CaPBBFutjuY
eMuL2ih3Jskzs743eam/8wrzcFELU2rnWh1ZJe2ghGf+/Ojk0NYRz07U8ozr
4lUrEXGXlSS/78ZkI8pQ3tY5bb+46QFQETMUd99olkZylviMnvwL5dkcGKIB
hqn6nXXKfS9dE0WuJ/PYFqMmCbxnxAr0Ths3uyXu3MflZRmBNfRN6cUlwwxx
eRJX/jgZwLemOqMj6IgKi5zsJrt2G0k7zB/cY+e1gKiYe0q064ix6hV8n4ex
kdOKnu7FRdfFRRVT+/JOI5HxuZcmOs12huZrIG5C2RzGy7e3iZ6r7W2euFOV
zcgFMLGPo/mYivQTegszXTWhrG9KI9vbXIA1G3vluNJUKvtSG4l+rUHFL8hW
QLlabMU2CFxKHFZNob480hsCNWrCpHy2oX/DywLU1l9yjXcOMVv9a4ebiV11
y4hWvWGVOLv+teMtxJpDCvLPCC0mwJem3d1bQ71HtSoaI+XNCiwUb0LIF6Hk
bkihfs1gFPp4+eShYP0rX5E85SAvoLbO/Gm3IDOoHXNXdNpaoQ+jeWuhdtYu
LdjvcHs0raLWGabBoMtw3p0MR7//vUeDdrb175LhjpQAq1E30LunNRTdgRh2
4Wh94e3M/dVo08LbSMJV2zV4TUd87cSHtY3rC0e1hXv1hXs3LRw1Fg4OagsZ
1HIMC0/Jo4ZD+9UbyKKBF8tNQ7u38If3HIRh9IcPNywcuYX3mwsHn1k48hbe
wnzHGgozYAtx9t3ZkL3ccFIWj2j4XTVcdUjTgxE9KEI2ZzJYQT6pkZatvUk6
ZfIsy4PhEMbc5PP4m30b/Yy2IFU3tOMLUnvlrCK2ac4faZznWnJUC2wXx+ZV
7iEtdeghgO3HZjKbOinou+12lW3dm/UcxFDhSXq2RVsRgrGN7Taym5j+JNdH
rlxyvY4FUsxnnQpWo8pq5RhFisBHR4ZztWn1WGu44ao2v+YHTyWbwzUw+WFO
D25vw/OECbUte65vlkva/quH7KHRn5TAECA15gAuYU0D9qpo8ragg8Kgw8l5
nFwijJ2ZEuha/EPRmYlUdfCkFSct6/Pf/paF6QEO4FVEydKUw+p/eMQrPCzp
NdwUiFmSSh4VE3lcJPGsI8aKStNJ7JoSObLgHGXtL48wLet/dMQUnjeH1f8C
zKLx5zw69b8FY16orP3pFlDgq9/Q24XHCPajv9AL8kOJPQPr+ZhP9Fdiut2n
4v8AIUdh02FIAAA=

-->

</rfc>
