<?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.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?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-ietf-cbor-tags-oid-07" category="std" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="2" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.7.0 -->
  <front>
    <title abbrev="CBOR Tags for OIDs">Concise Binary Object Representation (CBOR) Tags for Object&nbsp;Identifiers</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-tags-oid-07"/>
    <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="2021" month="May" day="19"/>
    <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>The present document defines CBOR tags for
object identifiers (OIDs).  It is intended
as the reference document for the IANA registration of the CBOR tags
so defined.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" toc="default">
      <name>Introduction</name>
      <t>The Concise Binary Object Representation (CBOR, <xref target="RFC8949" format="default"/>) provides
for the interchange of structured data without a requirement for a
pre-agreed schema.
<xref target="RFC8949" format="default"/> defines a basic set of data types, as well as a tagging
mechanism that enables extending the set of data types supported via
an IANA registry.</t>
      <t>The present document defines CBOR tags for object identifiers
(OIDs, <xref target="X.660" format="default"/>), which many IETF protocols carry.
The ASN.1 Basic Encoding Rules
(BER, <xref target="X.690" format="default"/>) specify binary encodings of both (absolute) object identifiers
and relative object identifiers.
The contents of these encodings (the "value" part of BER's
type-length-value structure) can be carried in a CBOR byte string.
This document defines two CBOR tags that cover the two kinds of
ASN.1 object identifiers encoded in this way.
The tags can also be applied to arrays and maps to efficiently tag all
elements of an array or all keys of a map.
It is intended as the reference document for the IANA registration of
the tags so defined.</t>
      <section anchor="terms" 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>The terminology of <xref target="RFC8949" format="default"/> applies; in particular
the term "byte" is used in its now customary sense as a synonym for
"octet".
The term "SDNV" (Self-Delimiting Numeric Value) is used as defined in
<xref target="RFC6256" format="default"/>, with the additional restriction detailed in <xref target="reqts" format="default"/> (no
leading zeros).</t>
      </section>
    </section>
    <section anchor="oids" toc="default">
      <name>Object Identifiers</name>
      <t>The International Object Identifier tree <xref target="X.660" format="default"/> is
a hierarchically managed space of
identifiers, each of which is uniquely represented as a sequence of
unsigned integer values
<xref target="X.680" format="default"/>.
(These integer values are called "primary integer values" in X.660
because they can be accompanied by (not necessarily unambiguous)
secondary identifiers.  We ignore the latter and simply use the term
"integer values" here, occasionally calling out their unsignedness.
We also use the term "arc" when the focus is on the edge of the tree
labeled by such an integer value, as well as in the sense of a "long
arc", i.e., a (sub)sequence of such integer values.)</t>
      <t>While these sequences can easily be represented in CBOR arrays of
unsigned integers, a more compact representation can often be achieved
by adopting the widely used representation of object identifiers
defined in BER; this representation may also be more amenable to
processing by other software that makes use of object identifiers.</t>
      <t>BER represents the sequence of unsigned integers by concatenating
self-delimiting <xref target="RFC6256" format="default"/> representations of each of the integer values in sequence.</t>
      <t>ASN.1 distinguishes absolute object identifiers (ASN.1 Type <tt>OBJECT IDENTIFIER</tt>),
which begin at a root arc (<xref target="X.660" format="default"/> Clause 3.5.21), from relative object
identifiers (ASN.1 Type <tt>RELATIVE-OID</tt>), which begin
relative to some object identifier known from context (<xref target="X.680" format="default"/>
Clause 3.8.63).
As a special optimization,
BER combines the first two integers in an absolute object identifier
into one numeric identifier by making use of the property of the
hierarchy that the first arc has only three integer values (0, 1, and 2),
and the second arcs under 0 and 1 are limited to the integer values between
0 and 39.  (The root arc <tt>joint-iso-itu-t(2)</tt> has
no such limitations on its second arc.)
If X and Y are the first two integer values,
the single integer value actually encoded is computed as:</t>
      <ul empty="true" spacing="normal">
        <li>X * 40 + Y</li>
      </ul>
      <t>The inverse transformation (again making use of the known ranges of X
and Y) is applied when decoding the object identifier.</t>
      <t>Since the semantics of absolute and relative object identifiers
differ, and it is very common for companies to use self-assigned numbers
under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number OID,
<xref target="IANA.enterprise-numbers" format="default"/>) that adds 5 fixed bytes to an encoded OID value,
this specification defines three tags, collectively called the
"OID tags" here:</t>
      <t>Tag TBD111: tags a byte string as the <xref target="X.690" format="default"/> encoding of an
absolute object identifier (simply "object identifier" or "OID").</t>
      <t>Tag TBD110: tags a byte string as the <xref target="X.690" format="default"/> encoding of a relative
object identifier (also "relative OID").  Since the encoding of each
number is the same as for <xref target="RFC6256" format="default"/> Self-Delimiting Numeric Values
(SDNVs), this tag can also be used for tagging a byte string that
contains a sequence of zero or more SDNVs (or a more
application-specific tag can be created for such an application).</t>
      <t>Tag TBD112: structurally like TBD110, but understood to be relative to
<tt>1.3.6.1.4.1</tt> (IANA Private Enterprise Number OID, <xref target="IANA.enterprise-numbers" format="default"/>).  Hence, the
semantics of the result are that of an absolute object identifier.</t>
      <section anchor="reqts" toc="default">
        <name>Requirements on the byte string being tagged</name>
        <t>To form a valid tag, a byte string tagged by TBD111, TBD110, or TBD112
MUST be syntactically valid contents (the value part) for a BER
representation of an object identifier (Sections 8.19, 8.20, and 8.20
of <xref target="X.690" format="default"/>, respectively): A concatenation of zero or
more SDNV values, where each SDNV value is a sequence of one or more bytes that
all have their most significant bit set, except for the last byte,
where it is unset.
Also, the first byte of each SDNV cannot be a
leading zero in SDNV's base-128 arithmetic, so it cannot take the
value 0x80 (bullet (c) in Section 8.1.2.4.2 of <xref target="X.690" format="default"/>).</t>
        <t>In other words:</t>
        <ul spacing="normal">
          <li>the byte string's first byte, and any byte that follows a byte that has the most significant
bit unset, MUST NOT be 0x80 (this requirement requires expressing the
integer values in their shortest form, with no leading zeroes)</li>
          <li>the byte string's last byte MUST NOT have the most significant bit set (this
requirement excludes an incomplete final integer value)</li>
        </ul>
        <t>If either of these invalid conditions are encountered, the tag is
invalid.</t>
        <t><xref target="X.680" format="default"/> restricts RELATIVE-OID values to have at least
one arc, i.e., their encoding would have at least one SDNV.
This specification permits
empty relative object identifiers; they may
still be excluded by application semantics.</t>
        <t>To facilitate the search for specific object ID values, it is RECOMMENDED
that definite length encoding (see Section 3.2.3 of <xref target="RFC8949" format="default"/>) is used
for the byte strings used as tag content for these tags.</t>
        <t>The valid set of byte strings can also be expressed using regular
expressions on bytes, using no specific notation but resembling
<xref target="PCRE" format="default"/>.  Unlike typical regular expressions that operate on
character sequences, the following regular expressions take bytes as
their domain, so they can be applied directly to CBOR byte strings.</t>
        <t>For byte strings with tag TBD111:</t>
        <ul empty="true" spacing="normal">
          <li>
            <tt>/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/</tt></li>
        </ul>
        <t>For byte strings with tag TBD110 or TBD112:</t>
        <ul empty="true" spacing="normal">
          <li>
            <tt>/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/</tt></li>
        </ul>
        <t>A tag with tagged content that does not conform to the applicable
regular expression is invalid.</t>
      </section>
      <section anchor="prefser" toc="default">
        <name>Preferred Serialization Considerations</name>
        <t>For an absolute OID with a prefix of "1.3.6.1.4.1", representations
with both the TBD111 and TBD112 tags are applicable, where the
representation with TBD112 will be five bytes shorter (by leaving out
the prefix h'2b06010401' from the enclosed byte string).
This specification makes that shorter representation the preferred
serialization (see Sections <xref target="RFC8949" section="3.4" sectionFormat="bare" format="default"/> and <xref target="RFC8949" section="4.1" sectionFormat="bare" format="default"/> of <xref target="RFC8949" format="default"/>).
Note that this also implies that the Core Deterministic Encoding
Requirements (<xref section="4.2.1" sectionFormat="of" target="RFC8949" format="default"/>) require the use of TBD112
tags instead of TBD111 wherever that is possible.</t>
      </section>
      <section anchor="discussion" toc="default">
        <name>Discussion</name>
        <t>Staying close to the way object identifiers are encoded in ASN.1
BER makes back-and-forth translation easy; otherwise we would choose a
more efficient encoding.  Object
identifiers in IETF protocols
are serialized in dotted decimal form or BER form, so
there is an advantage in not inventing a third form.  Also,
expectations of the cost of encoding object identifiers are
based on BER; using a different encoding might not be aligned with
these expectations. If additional information about an OID is desired,
lookup services such as
the <xref target="X.672" format="default">OID Resolution Service (ORS)</xref>
and the <xref target="OID-INFO" format="default">OID Repository</xref> are available.</t>
      </section>
    </section>
    <section anchor="examples" toc="default">
      <name>Basic Examples</name>
      <t>This section gives simple examples of an absolute and a relative
object identifier, represented via tag number TBD111 and TBD110,
respectively.</t>
      <!-- <note removeinrfc="true" markdown="1"> -->
<t>RFC editor: These and other examples assume the allocation of 111 for
TBD111 and 110 for TBD110 and need to be changed if that isn't the
actual allocation.  Please remove this paragraph.
<!-- </note> -->
      </t>
      <section anchor="encoding-of-the-sha-256-oid" toc="default">
        <name>Encoding of the SHA-256 OID</name>
        <dl>
          <dt>
ASN.1 Value Notation:  </dt>
          <dd>
            <t>{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
  csor(3) nistalgorithm(4) hashalgs(2) sha256(1) }</t>
          </dd>
          <dt>
Dotted Decimal Notation:  </dt>
          <dd>
            <t>2.16.840.1.101.3.4.2.1</t>
          </dd>
        </dl>
        <figure anchor="fig-sha-ber">
          <name>SHA-256 OID in BER</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
06                                # UNIVERSAL TAG 6
   09                             # 9 bytes, primitive
      60 86 48 01 65 03 04 02 01  # X.690 Clause 8.19
#      |   840  1  |  3  4  2  1    show component encoding
#   2.16         101
]]></artwork>
        </figure>
        <figure anchor="fig-sha-cbor">
          <name>SHA-256 OID in CBOR</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
D8 6F                             # tag(111)
   49                             # 0b010_01001: mt 2, 9 bytes
      60 86 48 01 65 03 04 02 01  # X.690 Clause 8.19
]]></artwork>
        </figure>
      </section>
      <section anchor="encoding-of-a-mib-relative-oid" toc="default">
        <name>Encoding of a MIB Relative OID</name>
        <t>Given some OID (e.g., <tt>lowpanMib</tt>, assumed to be <tt>1.3.6.1.2.1.226</tt> <xref target="RFC7388" format="default"/>),
to which the following is added:</t>
        <dl>
          <dt>
ASN.1 Value Notation:  </dt>
          <dd>
            <t>{ lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }</t>
          </dd>
          <dt>
Dotted Decimal Notation:  </dt>
          <dd>
            <t>.1.1.29</t>
          </dd>
        </dl>
        <figure anchor="fig-mib-ber">
          <name>MIB relative object identifier, in BER</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
0D                                # UNIVERSAL TAG 13
   03                             # 3 bytes, primitive
      01 01 1D                    # X.690 Clause 8.20
#      1  1 29                      show component encoding
]]></artwork>
        </figure>
        <figure anchor="fig-mib-cbor">
          <name>MIB relative object identifier, in CBOR</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
D8 6E                             # tag(110)
   43                             # 0b010_00011: mt 2 (bstr), 3 bytes
      01 01 1D                    # X.690 Clause 8.20
]]></artwork>
        </figure>
        <t>This relative OID saves seven bytes compared to the full OID encoding.</t>
      </section>
    </section>
    <section anchor="tfs" toc="default">
      <name>Tag Factoring with Arrays and Maps</name>
      <t>OID tags can tag byte strings (as discussed above), but also CBOR arrays and maps.
The idea in the latter case is that
the tag is factored out from each individual item in the container;
the tag is placed on the array or map instead.</t>
      <t>When an OID tag is applied to an array, it means
that the respective tag is imputed to all elements of the array that are
byte strings, arrays, or maps.  (There is no effect on other elements,
including text strings or tags.)
For example, when an array is tagged with TBD111,
every array element that is a byte string
is an OID, and every element that is an array or map is in turn
treated as discussed here.</t>
      <t>When an OID tag is applied to a map, it means that
the respective tag is imputed to all keys in the map that are byte
strings, arrays, or maps; again, there is no effect on keys of other major types.
Note that there is also no effect on the values in the map.</t>
      <t>As a result of these rules, tag factoring in nested arrays and maps is supported.
For example,
a 3-dimensional array of OIDs can be composed by using
a single TBD111 tag containing an array of arrays of arrays
of byte strings. All such byte strings are then considered OIDs.</t>
      <section anchor="preferred-serialization-considerations" toc="default">
        <name>Preferred Serialization Considerations</name>
        <t>Where tag factoring with tag TBD111 is used, some OIDs enclosed in the
tag may be encoded in a shorter way by using tag TBD112 instead of
encoding an unadorned byte string.
This remains the preferred serialization (see also <xref target="prefser" format="default"/>).
However, this specification does not make the presence or absence of
tag factoring a preferred serialization; application protocols can
define where tag factoring is to be used or not (and will need to do
so if they have deterministic encoding requirements).</t>
      </section>
      <section anchor="tag-factoring-example-x500-distinguished-name" toc="default">
        <name>Tag Factoring Example: X.500 Distinguished Name</name>
        <t>Consider the X.500 distinguished name:</t>
        <table anchor="tab-dn-data" align="center">
          <name>Example X.500 Distinguished Name</name>
          <thead>
            <tr>
              <th align="left">Attribute Types</th>
              <th align="left">Attribute Values</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">c (2.5.4.6)</td>
              <td align="left">US</td>
            </tr>
            <tr>
              <td align="left">l (2.5.4.7)<br/>s (2.5.4.8)<br/>postalCode (2.5.4.17)</td>
              <td align="left">Los Angeles<br/>CA<br/>90013</td>
            </tr>
            <tr>
              <td align="left">street (2.5.4.9)</td>
              <td align="left">532 S Olive St</td>
            </tr>
            <tr>
              <td align="left">businessCategory (2.5.4.15)<br/>buildingName (0.9.2342.19200300.100.1.48)</td>
              <td align="left">Public Park<br/>Pershing Square</td>
            </tr>
          </tbody>
        </table>
        <t><xref target="tab-dn-data" format="default"/> has four "relative distinguished names" (RDNs). The
country (first) and street (third) RDNs are single-valued.
The second and fourth RDNs are multi-valued.</t>
        <t>The equivalent representations in CBOR diagnostic notation (<xref section="8" sectionFormat="of" target="RFC8949" format="default"/>) and CBOR are:</t>
        <figure anchor="fig-dn-cbor-diag">
          <name>Distinguished Name, in CBOR Diagnostic Notation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
111([{ h'550406': "US" },
     { h'550407': "Los Angeles",
       h'550408': "CA",
       h'550411': "90013" },
     { h'550409': "532 S Olive St" },
     { h'55040f': "Public Park",
       h'0992268993f22c640130': "Pershing Square" }])
]]></artwork>
        </figure>
        <figure anchor="fig-dn-cbor">
          <name>Distinguished Name, in CBOR (109 bytes)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
d8 6f                                      # tag(111)
   84                                      # array(4)
      a1                                   # map(1)
         43 550406                         # 2.5.4.6 (4)
         62                                # text(2)
            5553                           # "US"
      a3                                   # map(3)
         43 550407                         # 2.5.4.7 (4)
         6b                                # text(11)
            4c6f7320416e67656c6573         # "Los Angeles"
         43 550408                         # 2.5.4.8 (4)
         62                                # text(2)
            4341                           # "CA"
         43 550411                         # 2.5.4.17 (4)
         65                                # text(5)
            3930303133                     # "90013"
      a1                                   # map(1)
         43 550409                         # 2.5.4.9 (4)
         6e                                # text(14)
            3533322053204f6c697665205374   # "532 S Olive St"
      a2                                   # map(2)
         43 55040f                         # 2.5.4.15 (4)
         6b                                # text(11)
            5075626c6963205061726b         # "Public Park"
         4a 0992268993f22c640130    # 0.9.2342.19200300.100.1.48 (11)
         6f                                # text(15)
            5065727368696e6720537175617265 # "Pershing Square"
]]></artwork>
        </figure>
        <t>(This example encoding assumes that all attribute values are UTF-8 strings,
or can be represented as UTF-8 strings with no loss of information.)</t>
      </section>
    </section>
    <section anchor="control" toc="default">
      <name>CDDL Control Operators</name>
      <t>Concise Data Definition Language (CDDL <xref target="RFC8610" format="default"/>) specifications may
want to specify the use of SDNVs or SDNV
sequences (as defined for the tag content for TBD110).  This document
introduces two new control operators that can be applied to a target
value that is a byte string:</t>
      <ul spacing="normal">
        <li>
          <tt>.sdnv</tt>, with a control type that contains unsigned integers.  The
byte string is specified to be encoded as an <xref target="RFC6256" format="default"/> SDNV (BER
encoding) for the matching values of the control type.</li>
        <li>
          <tt>.sdnvseq</tt>, with a control type that contains arrays of unsigned
integers.  The byte string is specified to be encoded as a sequence
of <xref target="RFC6256" format="default"/> SDNVs (BER encoding) that decodes to an array of
unsigned integers matching the control type.</li>
        <li>
          <tt>.oid</tt>, like <tt>.sdnvseq</tt>, except that the X*40+Y translation for
absolute OIDs is included (see <xref target="fig-dn-cddl-oid" format="default"/>).</li>
      </ul>
      <t><xref target="fig-dn-cddl" format="default"/> shows an example for the use of <tt>.sdnvseq</tt> for a part
of a structure using OIDs that could be used in <xref target="fig-dn-cbor" format="default"/>;
<xref target="fig-dn-cddl-oid" format="default"/> shows the same with the <tt>.oid</tt> operator.</t>
      <figure anchor="fig-dn-cddl">
        <name>Using .sdnvseq</name>
        <sourcecode type="cddl">
country-rdn = {country-oid =&gt; country-value}
country-oid = bytes .sdnvseq [85, 4, 6]
country-value = text .size 2
</sourcecode>
      </figure>
      <figure anchor="fig-dn-cddl-oid">
        <name>Using .oid</name>
        <sourcecode type="cddl">
country-rdn = {country-oid =&gt; country-value}
country-oid = bytes .oid [2, 5, 4, 6]
country-value = text .size 2
</sourcecode>
      </figure>
      <t>Note that the control type need not be a literal; e.g., <tt>bytes .oid
[2, 5, 4, *uint]</tt> matches all OIDs inside OID arc 2.5.4,
<tt>attributeType</tt>.</t>
    </section>
    <section anchor="cddl-typenames" toc="default">
      <name>CDDL typenames</name>
      <t>For the use with CDDL, the
typenames defined in <xref target="tag-cddl" format="default"/> are recommended:</t>
      <figure anchor="tag-cddl">
        <name>Recommended typenames for CDDL</name>
        <sourcecode type="cddl">
oid = #6.111(bstr)
roid = #6.110(bstr)
pen = #6.112(bstr)
</sourcecode>
      </figure>
    </section>
    <section anchor="iana" toc="default">
      <name>IANA Considerations</name>
      <section anchor="cbor-tags" toc="default">
        <name>CBOR Tags</name>
        <t>IANA is requested to assign in the 1+1 byte space (24..255) of the CBOR tags registry
<xref target="IANA.cbor-tags" format="default"/> the CBOR tags in <xref target="tab-tag-values-new" format="default"/>, with the
present document as the specification reference.</t>
        <table anchor="tab-tag-values-new" align="center">
          <name>Values for New Tags</name>
          <thead>
            <tr>
              <th align="left">Tag</th>
              <th align="left">Data Item</th>
              <th align="right">Semantics</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBD111</td>
              <td align="left">byte string or array or map</td>
              <td align="right">object identifier (BER encoding)</td>
              <td align="left">[this document, <xref target="oids" format="default"/>]</td>
            </tr>
            <tr>
              <td align="left">TBD110</td>
              <td align="left">byte string or array or map</td>
              <td align="right">relative object identifier (BER encoding); <br/>SDNV <xref target="RFC6256" format="default"/> sequence</td>
              <td align="left">[this document, <xref target="oids" format="default"/>]</td>
            </tr>
            <tr>
              <td align="left">TBD112</td>
              <td align="left">byte string or array or map</td>
              <td align="right">object identifier (BER encoding), relative to 1.3.6.1.4.1</td>
              <td align="left">[this document, <xref target="oids" format="default"/>]</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="cddl-control-operators" toc="default">
        <name>CDDL Control Operators</name>
        <t>IANA is requested to assign in the CDDL Control Operators registry
<xref target="IANA.cddl" format="default"/> the CDDL Control Operators in
<xref target="tab-operators-new" format="default"/>, with the present document as the specification
reference.</t>
        <table anchor="tab-operators-new" align="center">
          <name>New CDDL Operators</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">.sdnv</td>
              <td align="left">[this document, <xref target="control" format="default"/>]</td>
            </tr>
            <tr>
              <td align="left">.sdnvseq</td>
              <td align="left">[this document, <xref target="control" format="default"/>]</td>
            </tr>
            <tr>
              <td align="left">.oid</td>
              <td align="left">[this document, <xref target="control" format="default"/>]</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="security-considerations" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of <xref target="RFC8949" format="default"/> apply.</t>
      <t>The encodings in Clauses 8.19 and 8.20 of <xref target="X.690" format="default"/> are quite compact and unambiguous,
but MUST be followed precisely to avoid security pitfalls.
In particular, the requirements set out in <xref target="reqts" format="default"/> of this document need to be
followed; otherwise, an attacker may be able to subvert a checking
process by submitting alternative representations that are later taken
as the original (or even something else entirely) by another decoder
supposed to be protected by the checking process.</t>
      <t>OIDs and relative OIDs can always be treated as opaque byte strings.
Actually understanding the structure that was used for generating them
is not necessary, and, except for checking the structure requirements,
it is strongly NOT RECOMMENDED to perform any
processing of this kind (e.g., converting into dotted notation and
back) unless absolutely necessary.
If the OIDs are translated into other representations, the usual
security considerations for non-trivial representation conversions
apply; the integer values are unlimited in range.</t>
      <t>An attacker might trick an application into using a byte string inside
a tag-factored data item, where the byte string is not actually
intended to fall under one of the tags defined here.  This may cause
the application to emit data with semantics different from what was
intended.  Applications therefore need to be restrictive with respect
to what data items they apply tag factoring to.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC6256" target="https://www.rfc-editor.org/info/rfc6256">
          <front>
            <title>Using Self-Delimiting Numeric Values in Protocols</title>
            <author fullname="W. Eddy" initials="W." surname="Eddy">
              <organization/>
            </author>
            <author fullname="E. Davies" initials="E." surname="Davies">
              <organization/>
            </author>
            <date month="May" year="2011"/>
            <abstract>
              <t>Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead.  They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development.  This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage.  This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6256"/>
          <seriesInfo name="DOI" value="10.17487/RFC6256"/>
        </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="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="X.660" target="https://www.itu.int/rec/T-REC-X.660">
          <front>
            <title>Information technology — Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree</title>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date year="2011" month="July"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.660"/>
        </reference>
        <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
            <title>Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.680"/>
        </reference>
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.690"/>
        </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>
        <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="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>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="X.672" target="https://www.itu.int/rec/T-REC-X.672">
          <front>
            <title>Information technology — Open systems interconnection — Object identifier resolution system</title>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date year="2010" month="August"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.672"/>
        </reference>
        <reference anchor="PCRE" target="http://www.pcre.org/">
          <front>
            <title>PCRE - Perl Compatible Regular Expressions</title>
            <author initials="A." surname="Ho" fullname="Andrew Ho">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
        </reference>
        <reference anchor="OID-INFO" target="http://www.oid-info.com/">
          <front>
            <title>OID Repository</title>
            <author>
              <organization>Orange SA</organization>
            </author>
            <date year="2016"/>
          </front>
        </reference>
        <reference anchor="IANA.enterprise-numbers" target="http://www.iana.org/assignments/enterprise-numbers">
          <front>
            <title>Enterprise Numbers</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC7388" target="https://www.rfc-editor.org/info/rfc7388">
          <front>
            <title>Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
              <organization/>
            </author>
            <author fullname="A. Sehgal" initials="A." surname="Sehgal">
              <organization/>
            </author>
            <author fullname="T. Tsou" initials="T." surname="Tsou">
              <organization/>
            </author>
            <author fullname="C. Zhou" initials="C." surname="Zhou">
              <organization/>
            </author>
            <date month="October" year="2014"/>
            <abstract>
              <t>This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7388"/>
          <seriesInfo name="DOI" value="10.17487/RFC7388"/>
        </reference>
      </references>
    </references>
    <section removeInRFC="true" anchor="change-log" toc="default">
      <name>Change Log</name>
      <section anchor="changes-from-06-to-07" toc="default">
        <name>Changes from -06 to -07</name>
        <ul spacing="normal">
          <li>Various editorial changes prompted by IESG feedback; clarify the
usage of "SDNV" in this document (no leading zeros).</li>
          <li>Add security consideration about tag-factoring.</li>
          <li>Make TBD112, where applicable, the preferred serialization (and thus
the required deterministic encoding) over TBD111.</li>
        </ul>
      </section>
      <section anchor="changes-from-05-to-06" toc="default">
        <name>Changes from -05 to -06</name>
        <t>Add references to specific section numbers of <xref target="X.690" format="default"/> to better
explain validity of enclosed byte string.</t>
      </section>
      <section anchor="changes-from-04-to-05" toc="default">
        <name>Changes from -04 to -05</name>
        <ul spacing="normal">
          <li>Update acknowledgements, contributor list, and author list</li>
        </ul>
      </section>
      <section anchor="changes-from-03-to-04" toc="default">
        <name>Changes from -03 to -04</name>
        <t>Process WGLC and shepherd comments:</t>
        <ul spacing="normal">
          <li>Update references (RFC 8949, URIs for ITU-T)</li>
          <li>Define arc for this document, reference SDN definition</li>
          <li>Restructure, small editorial clarifications</li>
        </ul>
      </section>
      <section anchor="changes-from-02-to-03" toc="default">
        <name>Changes from -02 to -03</name>
        <ul spacing="normal">
          <li>Add tag TBD112 for PEN-relative OIDs</li>
          <li>Add suggested CDDL typenames; reference RFC8610</li>
        </ul>
      </section>
      <section anchor="changes-from-01-to-02" toc="default">
        <name>Changes from -01 to -02</name>
        <t>Minor editorial changes, remove some remnants, ready for WGLC.</t>
      </section>
      <section anchor="changes-from-00-to-01" toc="default">
        <name>Changes from -00 to -01</name>
        <t>Clean up OID tag factoring.</t>
      </section>
      <section anchor="changes-from-07-bormann-to-00-ietf" toc="default">
        <name>Changes from -07 (bormann) to -00 (ietf)</name>
        <t>Resubmitted as WG draft after adoption.</t>
      </section>
      <section anchor="changes-from-06-to-07-1" toc="default">
        <name>Changes from -06 to -07</name>
        <t>Reduce the draft back to its basic mandate: Describe CBOR tags for
what is colloquially know as ASN.1 Object IDs.</t>
      </section>
      <section anchor="changes-from-05-to-06-1" toc="default">
        <name>Changes from -05 to -06</name>
        <t>Refreshed the draft to the current date ("keep-alive").</t>
      </section>
      <section anchor="changes-from-04-to-05-1" toc="default">
        <name>Changes from -04 to -05</name>
        <t>Discussed UUID usage in CBOR, and incorporated fixes
proposed by Olivier Dubuisson, including fixes regarding OID nomenclature.</t>
      </section>
      <section anchor="changes-from-03-to-04-1" toc="default">
        <name>Changes from -03 to -04</name>
        <t>Changes occurred based on limited feedback, mainly centered around
the abstract and introduction, rather than substantive
technical changes. These changes include:</t>
        <ul spacing="normal">
          <li>Changed the title so that it is about tags and techniques.</li>
          <li>Rewrote the abstract to describe the content more accurately,
and to point out that no changes to the wire protocol are being proposed.</li>
          <li>Removed "ASN.1" from "object identifiers", as OIDs are independent of ASN.1.</li>
          <li>Rewrote the introduction to be more about the present text.</li>
          <li>Proposed a concise OID arc.</li>
          <li>Provided binary regular expression forms for OID validation.</li>
          <li>Updated IANA registration tables.</li>
        </ul>
      </section>
      <section anchor="changes-from-02-to-03-1" toc="default">
        <name>Changes from -02 to -03</name>
        <t>Many significant changes occurred in this version. These changes include:</t>
        <ul spacing="normal">
          <li>Expanded the draft scope to be a comprehensive CBOR update.</li>
          <li>Added OID-related sections: OID Enumerations,
OID Maps and Arrays, and
Applications and Examples of OIDs.</li>
          <li>Added Tag 36 update (binary MIME, better definitions).</li>
          <li>Added stub/experimental sections for X.690 Series Tags (tag &lt;&lt;X&gt;&gt;)
and Regular Expressions (tag 35).</li>
          <li>Added technique for representing sets and multisets.</li>
          <li>Added references and fixed typos.</li>
        </ul>
        <!--  LocalWords:  CBOR extensibility IANA uint sint IEEE endian IETF
 -->
<!--  LocalWords:  signedness endianness ASN BER encodings OIDs OID
 -->
<!--  LocalWords:  Implementers SDNV SDNVs repurpose SDNV's UTF
 -->

</section>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t><contact fullname="Sean Leonard"/> started the work on this document in 2014 with an
elaborate proposal.
<contact fullname="Jim Schaad"/> provided a significant review of this document.
<contact fullname="Rob Wilton"/>'s IESG review prompted us to provide preferred
serialization considerations.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="S." surname="Leonard" fullname="Sean Leonard">
        <organization>Penango, Inc.</organization>
        <address>
          <postal>
            <street>5900 Wilshire Boulevard</street>
            <street>21st Floor</street>
            <city>Los Angeles, CA</city>
            <code>90036</code>
            <country>USA</country>
          </postal>
          <email>dev+ietf@seantek.com</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAKkepWAAA8V92XIjN7bgO74CTU2EyTLJ4q6l2r6tklS2blSparS07XHX
XCUzQTK7kpnsRFIqtUo37kfMB9yHeZtPmLeeP5kvmbMASCQXqeR2xCjabTKJ
BA7OvgFutVqiiItEHcjvhZRHWRrGWsnXcRrkd/L9+K8qLOS5WuRKq7QIijhL
Zf3o9fvzhrwMplpOstyM+sd/nkYwJJ7EKtciGI9zdXMgcag38vRYiygL02AO
C0Z5MClasSomrXCc5a0ChrWyOGolQaF0ISL414HsdXrdVmfY6u4LoYsgjf4t
SLIUfijypRIiXuT0URe9Tme/0xOf1N1tlkcH8jQtVJ6qonWM64gwKA6kLiIR
ZinsRS+1nWIRH8hfiyxs0v9HalHMmrL3sSl1lhe5mmj4dDfnD2E2XwRhQR/m
sF39UYhgWcyy/ADQ14J/pIxTmPqoLV9n+TxIU3rGOz4Kcl2otPJLlk8P5FUa
3wDa4uL//M9Cvs4VTC0v/9spDdAAgwLYP2S6mAThTPb7ncGgQ7+FcXF3YF7g
B1kE6xy3env94b55skyLHEb9oHDRO3q4mBEKvx3stwaA3l53rzXq7/e69KOa
B3FyIMNgnP2p+HvcBggFYq3I4/GyWNvpRVu+VRnwS+Tt9EIFaeWxmTRSN98i
xf+kYUChPrUBj2IHByxzIMOsKBYHL1/e3t62FyoN0mmGA16WiPrAT5tA3bDt
o4c+A1xyuN/pyJ/iRM/iHBg5WybqxgKBv/e6upBvkizLPQy+zbQ8TKcqUUDj
o0MPlTBbf1RF5NXFoRAiRRoWQDZc+vzN0ag3HAGDRekNf9/bH+wDEse0Dn4f
dTvwPYoS+P5zezTqMMye9OHfaTrhiUHQChXO0izJpnfy//7H/zADPuRZqKIl
CCSJVDFTMluonN/IJjJjmY2dMMpcTWPAEo9gZo2LWGmLsx9UCu8nclHODGIm
i2whgzzUOCmuEpM80SwweH0ZpAPNWMqDI9tp5d1LwDPKzzKNQ3qmUQAy5mAr
9V2Q+l2msMoB2hgQY+c8vbxqXR6AXmIpjHhrhFTGaZBPUWSQnbThp7hYtmEL
L3MVvrxsnZ8ctXg8U2PvudSQh2PEKaDg4g4U42d5lhn1+D5Vsn54cdbuNiy8
FwsVApJCR6RxoONQpuaV3xNrw1Zn77lY23sm1vYs1vafjzXEi1QpCFecTmUO
0qm3Yuk1YenEDj7HwbL++uS8AUIapBkiInG/m1nMqCMYRWx8DLwPvy5jPVPR
2mTHMOz/N/r3n4l+GC9ii2LWP/B0t/dcWrwHFQuWDSzSXLN0g5JPQapxbKlw
3m9QKDpLljSMX/89Mdj5DRjc7T0PgzT+w9H5iZ3Zf9PanzBXaPpe2iGMV3wL
rMgHlSfgLYEzUMTjRAFM02US5PLkM7pKGjdn3quiBS0QW8jDNMrVrfwxM784
BODuwVFqnZ69eX+wti8DHbpJiJrSPK7QHWZAvy0DnyLL77YR6H0O1lTJi8Mq
DUZCtFotGRgVB9buEgzA1zuHTTR4Ei1gQ8ZgTXDmQDAjyttZBpNEQNppKqdZ
kCDzhckyUmRmAGQdj+ME7DLqAPW5QO8muZN6HiSJQKssdfx31ZSTIM7tczkH
rAdT+xMKPrwJbp6d6jaGzS8LXEKkCjQBGk/yuQDoVE2zIqYNtHmvZk8SnNXl
nD6oSZyCxiCHtjAOrVizgqBS0MlttIFbC9w7ylUaqUgEmrYHbqTKQf+pcmpr
xk8Pzw6rxtpYXrem0JkBJGozieYxOBTgw4Kk5Vm0ZNk1f/c7MT59EN95f88n
5f09uecPDw30EG5gr1pYkFlrzIiJAFgAHEAADyIiijukB7Ctvy1jclN5v4GA
pVrBNEdS6HAG7mFbuJUctgNjKbUqcH6atLhboJcG+LxVQPgARwFypmgC5gqB
ifUcoANWA2dxjGqeWIHUPgK9NpnUy8UCfH0A5SYOBHiuPinunsUS646RFsQS
iEjyOACRTRCCGDx59Mfl6cnlG8QsxB4ZyEIY5LgkrsjGcpMVFGgFzYz7OKPU
ZDzv5Jgpai0seW/jrJjJOkgzam3V2AQiCkyuEjIoG35neDAGwJjH8CXwT7lM
HTFbuwmSparJRZATigHIb7RAHLcSlU6LWYsGlHzSgO2mcqxo1zHgPwYPlRE6
vitoIMyOq4MorSG+uM085BPFw+xGMWvij5/iNEJoBWNyg7TSBnjdAte4DQzu
aUoEDvRThhAGi0WCEBYZeMV5cMdO8jxYaHykJuC4xDAvKCR4VaKqAnM3t+jC
ifAtibwPXAtRKj/HGdqiqivkb9MVorBwV9TEJcR9sTH7pWoAuZ3rB9Qh7o/Z
HCCTGEBrWXt3dXFZa/K/5dl7+nx+8l+vTs9PjvHzxY+Hb9+6D8KMuPjx/dXb
4/JT+ebR+3fvTs6O+WV4KiuPRO3d4S811t219x8uT9+fHb6tOco4FAQQ1hVE
EtI+IJYFoUyAYgohRGVqvj768I//7A5ARP4AtqjX7e6DWuEve93dAXy5namU
V8tSoBp/BRTeCSC1AluOvAikCoNFXAAXkMrRs+w2lTMgS9tYxcJDLxC01GHM
MPoVzoMCEYfoITCR4B1ZQw6vId2XmmGOgVfS7FaGS11kcxRjTFQoVnH6Dhze
uzmZnVoWFqqotR0AgOvjsz/XZP1CJZPWsUrieYxerzwDnOWgPv6Mctdwi8GM
hkFgXdS7GLc+PDRJYxODBVEUG78N9B6IIZuWSBUQxzO49/eg1QsNW62nmUhU
QPrp7yrPwP4JYYyKlxUCtgO/RVcN0rpxqnqNa9NQoFkqU9iTCOQMfoBgdYYR
ARATFCs4A2BZFkGIlkl4Mt+UCrMoQCtWwoiTNP7bEn2M3FpAxhFgHewWSSDM
sUzRZaG9F2oKgJAy04JA2QNQ2qJ+SWqxOoA4FuGCV2uLPCbKVocQm3M8OlZh
ADQiTrTaMQgp75Si/hnfIboL8FlCdHnyGMBegks5jqfLbKkbQoN7DL4xruEp
cCl/ArimaZazmwWqHrBM7K/j+QIn4UWJn0RtFT5k+abMwjDQRJfkjraEFDdu
VZxLiyFQzmAyYEFSnv7EsgZUqpGw0bMJSLVGEmT8XUXsSdB4TCgkwVglvG29
BGoBQiqgVRyBODUGHqWGtGstycAtwDWbMm6rNgyXdb0cNzzC8sTVDbcbQvw0
A043hs4OZ5ugAAmAgLGqMAysTtbImIcNHIM6RM6RBCaPWL7PShwnzyaYIiSq
A1ffgOsIew+ibFFYB+YWCMsEi1Yn2JQAQs1oZR1N8itWqCtvzsE4WVtHIEKU
Qu4TKFtBqSHwywEAAAbcCUCUBkBvSRmj4Z0HnxQpl80ggD6Alcs1tSFUSYQ1
XOFKwMkQKipUBkBGjcotKpWb01sreyHLaoXcuqmePAIa7MoAF/sGkZcm0NL6
SptcBs7tyEvwauT1+9f/enJ0KU+PT84uT9+cnpxfN5qC9coYrDNYEPJ+swzt
Vijrpdo6SkjM++1hu9cFj3CSZ/NVF0xsXff85O3h5emfT1rgWl47f5KWFG4S
sJI6m2/YhPyUohmjJcmp+1wY0FCNCQfaXnvUB1V+SJoQHUxM/AEfzuO/E6Kb
RFTg5TH7YyjQca4Lcr4cHREL6SMoFTAyAwWgZGqslQfpGJX5J6S24S2KEXNM
eXKAiAGd1f53zIslHIjzWaDZwhczNBwrvFDvNGWX3YAekI4Sn8SZqEQ5/7kE
nyyXHRrTJWVOHMi+4Ab2GqviVqlU8Bv9fdC9aBdKLrj+awavtGKdteJi2Srq
vcY1ginSjHURzW9Zmf2CEiBQTacT+TNN/gt7Q5vwbqBpksOBkpusAAr6pViS
IndOsCa9tGTrdyDE97DMCznoyG/lL2yb4xRjZtTNQarLzFI9mAZxuoFSzGiU
ZSCp/Jkw/AunBYxHTcYgUia+oYT2KouAmF7EqCiYNmDewZ1iB9qy1RMRjIji
CXjTTOmY3G3YyR3VcWAD6FdbG0sO/ZKUPuibQBu9BMw5xomYHchHAlrWuu1+
e9TutgftLvhf5Jd/yOMb0FoQs5F/ioH2Gb2MWZkm+Av/gsPayv3cMnNjIEcc
DN6XlkMg6mcyfQXDhJbHkArTO2z/BClzXcmdugCJOB5DAixYgQMSInaM6VbE
6aKGU+EQtvFA9UuIXy5fH3e73QMOJwI/GLPBiYs9y2wuxTliu6CD5WVXo7b2
Uw0DIwSlhq6jg6DzGyBwXLCenQE+RQtXc3zCC0pZMpc/FZoQwaRBfiHeA6uI
6yO/lObnUa8bgnV0znWjyXYXw0M/sCQzTnEdJzFWNov8QNU3ELAVj5R8bUQc
2WtaRNYxwKQHguSLOaJl+cOtjjF3roLCrG19K++dCiF6By5oJ5WRxJ+UIVFT
jsEBJKmAsCWLTHDmWSFx7QnJ9VcJiXxUSIBiPyIOKF4TFX3AcbNeJiZQRGky
8fdWvoSN7uzI8zJF5dxRnxBjReQAIgHO7nc49gEUZYjAOSAd5DGOcEBzlYT8
DpgyFqumwxxgntErKMYGtGmsJoGYchzDU7q8CyVZWHljRNngVBr6dGLdD0RX
cl0ALji/r+Veu7vfhP/vdVgn4idBAayRqibicWFVRuNAHvruGK9hGFA4BrRW
B5U6PCInrHzOyWCfg9HqWwY2eg75HePuWXCjTFwxz8C2oRomFZcWcgwaXKsC
QrnPoVqUaZEkgIE4DzphCABrevAtVQF+DEhc07OWRCPrKhKUMDnGVuh8VwJa
9GFwwDcaE5Kq1e3tAXtBrDxXQCrsFMCVzNsFuMLEmLznzue9jqyPl6BxwcsK
GzSXqbIAEdo9kIqe9DGPkneaGjebcjGglV+sMiTAUm6DaYjpRBpBbD8BjZ/d
OuVJz2ZGd65iVEjCKSGqKW3CBxHB4JuIoUzims+YW+WKB5tuITc420xEPcMU
qyZizU2mARweH80KwtdN+3RkLSGz3LGVNxhmgMeHGtgFCw2aw0g0+EAUZAfM
NFQAh/gPvCwVEw1cvhPcHyuRnB7h4B6NxhIVlYqYv1DLwuJmOJDTOdcum6Kl
78NbbIHupJ0BqQAxuhAoIOBn2OiVUemM1G22TKLqGyRSyKsma1r1DBaYrSq0
UPNFcfeYv/SKExAQFQoIjEAcgRUM9kiTeYaidMjarA6DEGsuQWHdNXTN2cpY
K2TWc/tuGkH1EoKC+JU8GfC1JeePy53XNXg2Voz6IET9SvbNpbpcqcLjqDIJ
RtaQtavVIZodJpP0Z3KbikFlCt+EGxmAOZckCDlXA4Uqq4FoUUjBNc0Y9PUt
OmwjAFlSVOPzMWZWgGuw3PjwAPbuKiWTW9wtqOhtVpD+CmzrqBcEKJqKcBZg
9Q5DdZu9MNqPFIMHaHUaVF+siyEkYYaLsjm4H6TnKnkp48FHIF8hpb6zteQ9
YvJNlleRx2nG0s/EUOP65X+v13/9y+e9busvn9+8+YgfO/zxReNf4FsHv+2+
+dj49r+8vH5y0k5pXJ85/Qua/pCmsnOi/baMwowJygrphk/J/ptY0MjFOFFi
Hbmc5Lc6AXyOD5Tix3rZBTiM8JzjaqzPaRDG3MSA9zsLbD9T+QNv2/dmUHkQ
lAFWqCBiQE6tRCXN1fSIoPFUFUKQmQZkQBhfxufO/d1Yi446fsXXoNnMm7dG
VUxQqzATsd4H1wO0BmioG5MyFBzIE8Szb3rjzqjT7Qw63W84LWF88STTJgIy
ZG5sVGucfSLC2OVWgLSrEbaFrmCbdMn9vXON+u0BYWOANaOJbeYiu3yWWUtK
FpEUAMY0sV2e6rXozRwrrgxgXqks34mKl1l3i8JavdXVrOWiOU1MbbxFIhDE
AwUYT/e4yyTiAlhA+pSL6QkVK4DdjmMdLpkT73ci9wW46qII7pAwhHDLy7dY
r1pPgFmLZ+pmlJaiRBBTYRyEn1qAvhaIBXIYZgoSRjTYp7tX7NfcosN/q4wF
C2cZrhuwI+mKaU7dt20bSiUjBotXi6cCQbO0ZeiirMAYJwJumYPeJFEFCUJw
2Q/RGXJizr4pyFV0A7YMOwngZZRvzHikBcdlQPOc4qU5AETeJKp4AKtMOxZU
J9VkL8pYciMSBbqSWH3ipCybhUByosLfvZzH01khrWeacD4CxU6YMqwHRFuC
3+JVb2KvASgYUzU+JaWBNTWlY/RZRJJln5YLRN1NHFJBHMNB0v7yV24lcS0/
FzxI1t+fXzQ+1neon6bhMme/VjtPYIBtZmmwSrkJ4iQwPGlq258DdMRQzynz
sawRCSPvRk6moFg0lyxw3+bFlQiPfOFH8gDNSt7+JqYGApPgWVOHnabwAyEA
+49/aLXkH1NUBSDJ2Q0Ehvkk/K6G7cQ1kIL8U5Tdpt/VurXvZav1vcBmGBUh
Og4kF4io6kiupdtCoPVyzrIO0U9WdsEhMFj08+BC6zax5o3TjNTTwpE392MA
90+sHki/4cYXzvh58wMbf0Cv0W6EtRrElsE0DxazttnqS9wr7wXVyImXI0F4
L348bPWGI+Qqm06nzIfriTwQB/Jermc9bU9tvTtqAP/X9wadBjYmBalRzfVu
Q06zm3q30+U2vVBneb3fkKhWg2SaUQxWHzQwsJnBA42zwicAB98FzXbMCuDY
KAAfJNC4ozasCXYSFgCLSUoY2PLfyz/RGckn/nbk1Rm48ecXh2/l5eEPktqF
O/tPvLNv3UGsCMbEp/zTqCP3RnKwJztdORrKTl92BrLTw6/wGoWItniAMTx3
T0v5Bf6BvUjZpc99KQdS9uirpLI15TchOPAUC72LWHBwAR4qu78/kDuTeNoC
lLZQOKjL7LuaR3FTVKo9VNF2vCdHb55AAQhdHViaKDt4Cl+dMfgH/wb/dLoH
cl7IXtOi8Dfibds2MYDYsk/0bXGjKzIQyHenr0HnlUlFIX6ATymXX/DlumpP
IXy7Br97EaTv4vF100i8lVqXI+vhP73RNabAQHPs9vf2sGVIwDCu8lRdeDRb
EZjig8dEj5dlE6pRMPgBWH3/6/tlcYnWGiPEem//KfFBsWn39lfE5fhROsp1
cen2SV76T7zU3yYvQF/4X3fjumt073WsvHTxf70tXLdNXjbxzDwe+6KBrLA9
rm4+Ii4nT2CAxaXD4vIUuoy4gLQYcQH/GzzoRtMi8jdibxsGfKn5ChRYSbrk
vFIpOVIHZOAVig8HEFSXycty22QJMQYOdd4hJ6rfgHnLKOFKEclh2aX1Dru0
7neKiV5thrTFD4po0QmoRJR17JNhNxnzBWOwkA1Od5Pj71f7bTMY9+TAbgPb
jWA6LUK0srHJb5Y5IsyWANToB8K0FPpQOjJOo/gmjtBcx4Wa28lMIUDlr/w5
FkkQsifJZSnTaAbw2CChje0MKrW+n3nP72kzDWqUiZkr0ALCxTOl+2NfjE2V
EF8EYvidbiUEXMlCP9fDadMgrGkA1KY6yg54Sp10yC+ZzX/auZuCu4Qp0YgF
a0skrpxgxwaGxsafanJV0bXdcd1latxmm4cXimqAPMQs5GKnSg5fcHRApQlq
LqYX115JV5DP6c9lnorCFFsqHGX6yJ6gDE5VkqVkoCfJQk2GhnEQHEsQ2pjY
RpBXkoq5lCraQBXbucjUmQd/RfxjF201OLYRFcpJ5X1XwvBBwzYMTS47VW5c
vpXOhzRpexMn3RiYKU3IXGnEjL1W3naFHUQg+60onmNHOIVFhk4TOpPoKmKo
8TnhwOEYvGZK58b7tglDQBBFa2k5kWv7MZ/ESsawDRFjwpFVRcmYCn6K81LS
h8u72sTsX5ciIibK1QqmVtJsNifadH6JLnMsTAzMLFAr0LgS4wcurYI5AYud
cuqel4wQLmwF7CzTIMrytJrDaVu1P6eaZiU1IzekZoiJ7u9tDgzzMD9mtyiC
pqS6Uv22qbm5KcSY1u2QSk0QJNqGviqygm1AvKoku/1O7dR0VtncWJVNtfHs
KNkMKyNIdeRVSpLZgC3KsKufYjV1x6n8qJI6Kg9LeamjBucPq2bPxNEHYLaH
nc7KyaezYK6EsFxDaOFhUWUYHU4R4os8LPi8p6KOI/2ou/H4nz8XV8TXRsB6
oaz32kMIwSAU/Of+vsiriydGwHqJXW+38cdx/vJ7bb/v8XdQBBBhHuFxE/ND
d3czZF/846P07tEh/WsfvK++XY/Pqdq59v+JTX6Rw35PXsj3Car+i2Lz/sYo
okrrIzA7ECffuV0MeX/jZZwgWyFfyHqnvd/u9QcQe+z3Op1+B2Ji/Kc92GvA
eh+WY+B/+SHIP9G7H1SuZ8hxF39bovr6Qq5gEYxbUdricxXsCRqO3MqQNfRC
UZi+qyUyqQGS7vA1MF7oHN7fe1M+PFDxcpItc6+BY515dU3Wz4/P8AgOuBXC
ZBhknWqlfCTQkoLSeQ2Jo0kLs6rnMwoRO3K27SqNaGVQp270HCxV7AbTaBRQ
eMD10WpHom0OjeJgmmYk2K7q46WB90Q1BYwLGzcTxbLifoNGr/96L2ffDIed
QWf0zYGsXV3U5EOTXXv3yy7+4rForWkPo5kBezjg6HD1ebeLz4mJN8y6jz9W
GXHDqAmO8tjHX6Ozvw9x7t7+fn/S64WjAazToeFV7oJZPzY2xh3AGXRxAOLU
ctw6j7l4A/jP4d7GsatxWARx2OTrxLCav9gbfO1b5B3UBw17PrD7VW+Bf1Pv
NtwpQgwAmeyPvGP0qSwXg79R7+nF0L+u97yX4G84HD4Wc+4Q89k9PR6d2jdw
T/0Ne9p95B2js1f2NH56MdpTt1vd1CAcTXb7PeD1kRrtjoajcDTc7XtvVeRm
HdK9JyHd+32wP+gPHuOTHZLfNfi629+x8HVXUTn8SgCHVQD7+30wG/1ufzPp
d6wi+X24fnuy0O5rf2Vb6unFmEMGK/sa9vv9Xq8zRC6ZAH/s745GQ/y+O+B9
rehAu8EnCe022Nuwwe06yBFu+DvJwLCzOxz1cGcj2OOwM+ru9rzJdqr62wM1
kJs0OL+z3Z+QVQCe1rYW7OEq2CCqvd3+aA8AB+ElknRhKwj+kMBesSOP2ZCv
MR/1bsdknBtoNuoUxJgAs/TSOatrqsEYhQfO+fWOA11dvmntuZyIwO5jDkFX
TiBVxpU9U5mmQNOr7eGBlaPj47cYFxZ5luDpfogNMzp1FfKzjQevKCagw8DH
6Lgdc8MN+iJvA0AEVkLrNDH21kRRUh42daf4sUnoFluvisydQ/Vq1tyYClvE
D6I8SVP3TqHZLp3VhhyucGHDZ+UIqIjNeWdzCjRVt9Js0nTA4Mb5RGi1VYUS
Knyg3vTnbcz3UMPddRv7e6+btr/CroDpDnvc1PTlrp1eIYgxRe03gpahqkv7
2yA7oOyR11KM7Yh4yhemsLzVcGgCmofE2oalXOG5BLBd7gBQ/lWbKDMYdjtl
O5/Z0HO249qOYBbuzfL2xhd5eFsz7V74uvYTkhioyw2ngxwKtmw8iyPYNDVN
+VgwDaMut/nzi0Hn218qXQoTurLHb7DRnMkz3W+mXcRqD5AJvLWK2zYrj2Gr
WEggylo9YSloZKMEzfTyYl+voJqSOyRtki0EhyEY9kzYzAKdxPRU2cPDK7EB
OgOKa2J3Jz0ZVU5s2uQQ80VFJnhq5VEqv5P39iuMl999b4u3HAI9iMqvJnVv
dyd/3Rs25aApRx9F5TUYScncNt7bIHtiVTUDFFY1XxEW7IzGcf+94MQvv/aa
8jdDSdNVIYUnCGUlK1oVP8oB2bYO4NUC72F6JU2tsARNlKC9WIIEfLxm9kdj
wrUQ6gaKIy6h4LkUchKa4tpZH8ziXGNOkZQ5Lk/RsvAtwRuPOYk/cCw32bsX
vIPDEgP0qWV1NGu5vZqF6pGOPozqnVEbQ1YqQ4nce9Yxz/A+GvOoZx5ZTNt1
LIrPy4XKvZAIIciIdkGnDNYa6eIgDVaLQDs75T115j3T7cxpZtRGdArIZqy7
33aNIqTzxfXeoN3uDYeNtQs73B0SIJF/oPMM7qY7wFh1qMHnGH9lttMtsGv+
qWyxdgeFaeeuJkDdvQFtTORhjlBi1ojs+ykWk9b/vsgLd4rin/v7Is/dtQUb
fxdf7IUDX1qP/T3+63P+npoJ02UmQ/6lYuBQI/v1nC+bTlRUzdhXY+kvv1au
NcATL3Q4/uGjdPB0noRne5l1BbBXkjJ35FaUltgdxfg6eHr/NH6a/rkg6XWp
Pg8/Nt1YFRWrHEySGbXBGTy9pMNtNsvY7ap5InPTxrHZZRZfpQW2uNvrIs/6
8ZFX6A4G3I/zXVclf/32mU2SL6qST6ndZ8rk10kLWeGtdLLhhmEd5wR81WC0
C183s2WCCtIsDyDhCdsOy2QULlS4zPE+qJXy2fotFNqODKsmZO2OD3s/UHkX
DgaM1DLBp6zc8arKIR+yl39b4tkGexkAjvOucmgK7DSwB8O44wf4EDgBwzXu
tg9uMjqfYGBdxMUEPALdxvND5aUjTVPG91qP6UjDsqje40Hmy79rpewqFHZ9
r3+3SU56UQThJyoFU9XQXBkg9XJ8o3I8/Q5+Sojngu0tAnyXw3geF9xWm5jr
Pm7UWtbcVazxSticjiak9iatLI+ndG4Hjzwq221VUEygErqcqIDtJncNOq+S
csGaI4xcUJ1Yu7gFq3qguLj0S36aAVoaoNvUK6Krx4xd7ThIbjFyGtOlFbbO
ny0C0B0rZyEO7aFrc2Ay8O6lcg4/bfs20OXZ0Cnd0WlvgJiLmCuc9hKQO+pK
qByHcxuoTu0zQVPwqRv4NUunANPKnTyIG5AePt6Y3vm3QFhOwRuWbHMbCApS
nEv0VNmk1jFX5gAIBTaHN2DvCfKBDbFgZbeRNh67QpAZ27lyoRkHf5lpPFjh
lKbxWwG3YpvkTqgGm7aAFDcxnaGp3r1B4PPVfSTXdARq010uAL65ACA2Z9ux
f8EXBerXxmNen1YO1fIWbKt3JZgmWAW1IrdcUxAV07AByDt/sRqDIyPYs/zC
3SFV4EEsCA74uDqds5zYFEvpxFMHikmuoADT3TPCO8jChycyqWDD5aVu3hn8
sl2dmpduDes6QLBTvpxKc2vIBNv8vZZld8XQjQk8TG8LNz0GRYkHzXVyItBK
wb3IMLwBC0VHECDQ4Xvp3mZTP8gBq8G9zqfp+Zsj07T9YEdr3kWrM0LI8Aba
LVYQkwx/DvIY9LTp7UaWCs0kICnzhdEmpycXP8gJ7BWheiVD0McmQYZ5Dbq0
EE/s8AVOa7dd1VeOSGLl/4U8jKItBsr0+JdMRP0WL+S7wB7Y7llW8g/3PNqD
wa39S2wZ9OxItKVPAaKgG9dG315D7JARO9qOWNycc2R0mVSkewC5TGqOglcN
KrES9trhoYwE76Ogk1b2IskNh4nWoRswdMPHyH61wIsyQeTwcosEbyxibSq9
O7IhmNeFOZRL127Sg7Xl+rzcYPtyH4zN/OmHt0dcvJ6pBZAvcjeQH3gweWir
2ys4m/Lq/JS1H12gikdsj7ltBRMFnJCq+FnlvXPAlPYIJrqXL/AciDUlTXPz
psf9xNpW0sXabnu82/5jyEXie21FCN2Hk7NWxeRaAVhOp+yaV1Mar7wNmIu3
10DpMii97aC8i1P0K1ZFu2lPSlALFXxOA6I9mP3ojsBFSq0zVocX7G5f8CjB
O9OXC9cG6Mnv6my7sj7mO+QbPG9H1vFa9ca26f2FgIbsfbGb8tMPfBO/hH/w
RjC6aYouQn2mSqyugcl5Uhc8OSo/fB/vsuE7PQF6vnD22Nzbt3K36q3Jy+PF
JRloHPKaUOQQaG51t3fDcbPcMxVNFdwJWJwZX4liIDbdxqBkybqRfNVrn5Ra
tAIs9tFNJc9UH/6ax64N9OoKKM6WwNSazDU1oFHzRZbzLR3xZ6XRBXMdilhy
xAj7eDlexlpnaVOWLbI0HGPRII9M9hgchTlqwQCldx32p3SRD7t9NQsJPZF0
R9msZ2QNXlNikx9eOaP4gDwonQx8EvYx7B3qvNvyCluQp4DcPPCEUwwW0FGm
nn+6w5qOQBuBbJsjVdb0mjQ9acUjcxKK3B6MC/kAM/IVl3ysrTQ33tPcGO9T
DeFc3eaZOcTuIEW/1vKrzecie/CVaYiOAB1abHPhS/TlAo89mUvyAjzF50C1
xyzxjKdtK+T+XGUiD6K1AQa1TiRrxPk1Jtr6PTq6RhfiOecZ3HO1QD8spa5a
enltcz7mjUPG2xmbq/1c9gGz4PT6B8uHVFCi8qHJPNuf8aLgyF5Hu+EoNEYV
7r8KwpbaXsBszVm04ZrTgm703SDuTxkXn33f4UUZ/p0R4So/Wz/MRASPMdnJ
50XAHrdTHTrMFvaS0oDC+1zNsPX4xii5Je2vbQweN/yyjSPvi88hHxBmTuhS
NBPl8NXgfJ4B2evQtG5jaLXiZ+PPJ975SNNSbBfErHB/ZAABa8J0enf67qRp
vCjP8FO7qX1TF8vxSzxxmmM7dQGSaAEmavKRkQu6vJ3/yy91NGb/+F8//+N/
N4xUbLgtnUf1h/5KTh5pYheuoWxoVZi+b+zCw2/ee54XRI17dIsWuAeZtoc3
ISgAFfITXa0imSTV68KJ8bDUgk2BYGFOTk4kXiEd8JFjQWchN0xV3n9phtNH
EDvpp0GNgOJBsW0TnSLh5qQzNReDuWoKWFjmKHr2PporC404dA4p+YWrxX6M
fNhvVtF3tTTjDst7/7/U8oAp4SKgm7BJM2X5J+7Z90MSkI1epzswBeVUANuO
yUgZjRUkeJX3/b/Gc3kBAhPQtAurEYKK4OUKTNjtWuKJJjjPxvgfcimyFCaA
nVIgZV5wAdaS1KiZfesJ/2omoC3+H9NS6VL3aAAA

-->

</rfc>
