<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 4.0.5) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-cbor-pointer-01" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="CBOR Pointer">CBOR Pointer: Selecting Elements of Concise Binary Object Representation (CBOR) Documents</title>
    <seriesInfo name="Internet-Draft" value="draft-mahy-cbor-pointer-01"/>
    <author fullname="Rohan Mahy">
      <organization/>
      <address>
        <email>rohan.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2026" month="July" day="06"/>
    <area>Applications and Real-Time</area>
    <workgroup>Concise Binary Object Representation Maintenance and Extensions</workgroup>
    <keyword>CBOR Pointer</keyword>
    <keyword>pathspec</keyword>
    <keyword>JSON Pointer</keyword>
    <keyword>XPointer</keyword>
    <keyword>CBOR Pointer</keyword>
    <abstract>
      <?line 40?>

<t>CBOR Pointer is a syntax to identify a single CBOR value from a CBOR document with an arbitrarily complex nested structure.
It is analogous to JSON Pointer.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://rohanmahy.github.io/cbor-pointer/draft-mahy-cbor-pointer.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-cbor-pointer/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Concise Binary Object Representation Maintenance and Extensions Working Group mailing list (<eref target="mailto:cbor@ietf.org"/>),
        which is archived at <eref target="https://www.ietf.org/mail-archive/web/cbor/current/maillist.html"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cbor/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/rohanmahy/cbor-pointer"/>.</t>
    </note>
  </front>
  <middle>
    <?line 46?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>CBOR Pointer is a syntax for identifying a single arbitrary subtree or element of a CBOR <xref target="RFC8494"/> Document or a CBOR sequence.
It provides functionality analogous to JSON Pointer <xref target="RFC6901"/> but supporting the full range of CBOR types.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="definition">
      <name>Definition</name>
      <t>A CBOR Pointer is an array consisting of pathspecs.
The entire array can be implicitly typed or explicitly typed.
The first pathspec operates on the root of the CBOR or CBOR sequence document as the parent element.
The entire CBOR document matches the CBOR Pointer <tt>[]</tt>.</t>
      <t>Evaluating a CBOR Pointer returns either an array containing a single valid CBOR element, or returns <tt>null</tt>.</t>
      <section anchor="implicit-pathspecs">
        <name>Implicit Pathspecs</name>
        <t>The semantics of an implicit pathspec depend on the type of the parent element.</t>
        <ul spacing="normal">
          <li>
            <t>If the parent element is an array, it returns the appropriate element:
            </t>
            <ul spacing="normal">
              <li>
                <t>if the pathspec is an unsigned integer, it matches the element at that zero-based position from the start of the array;</t>
              </li>
              <li>
                <t>if the pathspec is a CBOR negative integer, hexadecimal 0x20 matches the last element of the array, with higher numbers moving backwards through the array</t>
              </li>
            </ul>
          </li>
          <li>
            <t>If the parent element is a map, the pathspec matches if it matches one of the map keys of the map. It returns the value of the map key.</t>
          </li>
          <li>
            <t>If the parent element is a tag, the pathspec matches if it matches the tag number. It returns the value inside the tag.</t>
          </li>
          <li>
            <t>If the parent element is a byte string, the parent element is re-evaluated as embedded CBOR. The pathspec is evaluated as above if the type after byte string decoding is an array, map, or tag.</t>
          </li>
          <li>
            <t>If the root element is a CBOR sequence, and the pathspec is evaluated as if the entire sequence were wrapped in an array.</t>
          </li>
        </ul>
      </section>
      <section anchor="examples-with-implicit-pathspecs">
        <name>Examples with Implicit Pathspecs</name>
        <t>Given the following source document, the table below gives the corresponding result.</t>
        <sourcecode type="cbor-diag"><![CDATA[
777([
  [
    [1, "two", 3],
    [4, "five", 6]
  ],
  {
    1: "abc",
    -18: h'1234',
    "x": null,
    35: 1(1760686166),
    "y": [ "l", "m"]
  },
  <<{
    2: 45,
    "pdq": false
  }>>,
  27,
  h'abcdef'
])
]]></sourcecode>
        <table>
          <thead>
            <tr>
              <th align="left">CBOR Pointer</th>
              <th align="left">Result</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">[77]</td>
              <td align="left">null</td>
            </tr>
            <tr>
              <td align="left">[777, 3]</td>
              <td align="left">[27]</td>
            </tr>
            <tr>
              <td align="left">[777, 9]</td>
              <td align="left">null</td>
            </tr>
            <tr>
              <td align="left">[777, null]</td>
              <td align="left">null</td>
            </tr>
            <tr>
              <td align="left">[777, 0]</td>
              <td align="left">[[[1,"two",3],[4,"five",6]]]</td>
            </tr>
            <tr>
              <td align="left">[777, 0, 1]</td>
              <td align="left">[[4, "five",6]]</td>
            </tr>
            <tr>
              <td align="left">[777, 0, 1, 1]</td>
              <td align="left">["five"]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, 1]</td>
              <td align="left">["abc"]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, -18]</td>
              <td align="left">[h'1234']</td>
            </tr>
            <tr>
              <td align="left">[777, 1, -18, 1]</td>
              <td align="left">null</td>
            </tr>
            <tr>
              <td align="left">[777, 1, "x"]</td>
              <td align="left">[null]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, 35]</td>
              <td align="left">[1(1760686166)]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, 35, 1]</td>
              <td align="left">[1760686166]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, "y"]</td>
              <td align="left">[["l","m"]]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, "y", 1]</td>
              <td align="left">["m"]</td>
            </tr>
            <tr>
              <td align="left">[777, 1, "z"]</td>
              <td align="left">null</td>
            </tr>
            <tr>
              <td align="left">[777, 2]</td>
              <td align="left">[h'49a202182d63706471f4']</td>
            </tr>
            <tr>
              <td align="left">[777, 2, 2]</td>
              <td align="left">[45]</td>
            </tr>
            <tr>
              <td align="left">[777, 2, "pdq"]</td>
              <td align="left">[false]</td>
            </tr>
            <tr>
              <td align="left">[777, 2, 0]</td>
              <td align="left">null</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="explicit-pathspecs">
        <name>Explicit Pathspecs</name>
        <t>Explicit CBOR Pointers use tags to match a specific type of element for each pathspec.
If the type of the parent element matches the expected type, the matching rules and return values are the same as for implicit pathspecs, except that in explicit pathspecs, byte string encoded strings are unwrapped in a separate pathspec.
Explicit CBOR Pointers are always wrapped in the tag <tt>&lt;TBD1&gt;</tt>.
Each element in an explicit CBOR Pointer is either the simple value <tt>&lt;TBD0&gt;</tt> for byte string encoded elements, or a pathspec tagged with one of the following tags:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Data Type</th>
              <th align="left">Tag</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">array</td>
              <td align="left">TBD2</td>
            </tr>
            <tr>
              <td align="left">map</td>
              <td align="left">TBD3</td>
            </tr>
            <tr>
              <td align="left">tag</td>
              <td align="left">TBD4</td>
            </tr>
            <tr>
              <td align="left">sequence</td>
              <td align="left">TBD5</td>
            </tr>
          </tbody>
        </table>
        <t>Converting one of our implicit pathspec examples (<tt>[777, 1, "y", 1]</tt>) into explicit pathspecs, gives us:</t>
        <sourcecode type="cbor-diag"><![CDATA[
TBD1([          # Explicit pathspecs
    TBD4(777),  # Tag 777
    TBD2(1),    # 2nd Array element
    TBD3("y"),  # Map key "y"
    TBD(1)      # 2nd Array element
])
]]></sourcecode>
        <t>Both the implicit and explicit version return the value <tt>["m"]</tt>.
However, an explicit pathspec tag referring to a different type would return <tt>null</tt>.
Consequently explicit pathspecs are useful where different types could be in the same location and the distinction is semantically meaningful.</t>
        <t>Explicit pathspecs involving embedded byte strings require an additional pathspec element. For example, the equivalent of the implicit pointer <tt>[777, 2, 2]</tt> (which returns <tt>[45]</tt>) is the following:</t>
        <sourcecode type="cbor-diag"><![CDATA[
TBD1([            # Explicit Pathspecs
    TBD4(777),    # Tag 777
    TBD2(2),      # 3rd Array element
    simple(TBD0), # decode byte string
    TBD3(2)       # Map key 2
])
]]></sourcecode>
        <t>This property of explicit pathspecs makes it possible to return the entire decoded value of an encoded byte string.
For example, the following explicit pointer applied to our original example:</t>
        <sourcecode type="cbor-diag"><![CDATA[
TBD1([            # Explicit Pathspecs
    TBD4(777),    # Tag 777
    TBD2(2),      # 3rd Array element
    simple(TBD0)  # decode byte string
])
]]></sourcecode>
        <t>returns <tt>[ {2:45, "pdq":false} ]</tt> as its result.</t>
      </section>
      <section anchor="array-filters">
        <name>Array Filters</name>
        <t>Array filters allow selecting a single array element by evaluating the contents of those elements against another CBOR Pointer. This filter pointer is evaluated against each array element inside the parent element where the filter was invoked, in turn. An array filter is tagged with tag <tt>TBD6</tt>.</t>
        <t>For example, if a filter were invoked at the following parent element of our initial example document, the filter pointer is evaluated once for each of the two elements of the parent.</t>
        <sourcecode type="cbor-diag"><![CDATA[
[
  [1, "two", 3],
  [4, "five", 6]
]
]]></sourcecode>
        <t>The CBOR Pointer Filter below selects the entire matching array element under the parent element, where the second element (<tt>[TBD2(1)]</tt>) matches the value "five":</t>
        <sourcecode type="cbor-diag"><![CDATA[
TBD6([           # Array Filter
    [            # Per-element CBOR Pointer
        TBD2(1)  # 2nd Array element
    ],
    ["five"]     # value to match per-element pointer result
])
]]></sourcecode>
        <t>If multiple elements or no elements would be returned after evaluating an array filter, the result of the entire array filter is <tt>null</tt>.</t>
        <t>When evaluating the CBOR Pointer (containing an array filter) below, against the original example, the result is <tt>[6]</tt>:</t>
        <sourcecode type="cbor-diag"><![CDATA[
TBD1([            # Explicit Pathspecs
    TBD4(777),    # Tag 777
    TBD2(0),      # 1st Array element
    TBD6([        # Array Filter
      [             # Per-element CBOR Pointer
        TBD2(1)       # 2nd Array element
      ],
      ["five"]      # value to match per-element pointer result
    ]),
    TBD2(2)       # 3rd Array element
])
]]></sourcecode>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TO DO register 6 tags (TBD1 through TBD6) and 1 simple value (TBD0).</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8494">
          <front>
            <title>Multicast Email (MULE) over Allied Communications Publication (ACP) 142</title>
            <author fullname="D. Wilson" initials="D." surname="Wilson"/>
            <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/>
            <date month="November" year="2018"/>
            <abstract>
              <t>Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).</t>
              <t>This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.</t>
              <t>This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8494"/>
          <seriesInfo name="DOI" value="10.17487/RFC8494"/>
        </reference>
        <reference anchor="RFC2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <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" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <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 anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC6901">
          <front>
            <title>JavaScript Object Notation (JSON) Pointer</title>
            <author fullname="P. Bryan" initials="P." role="editor" surname="Bryan"/>
            <author fullname="K. Zyp" initials="K." surname="Zyp"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <date month="April" year="2013"/>
            <abstract>
              <t>JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6901"/>
          <seriesInfo name="DOI" value="10.17487/RFC6901"/>
        </reference>
      </references>
    </references>
    <?line 256?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81Z3XLbuBW+51OgykXsVpIt2ZETNc2uEzu77iRx6jiz3fF4
xhAJSdhQBAOQlrX5eZY+S5+s3wEIEpTk7O5MO1NfJARwgHNwznf+oF6vFxWy
SMWYdV48P79gb5XMCqHH7J1IRVzIbMZOU7EQWWGYmrIXKoulEey5zLhesfPJ
LyBiFyLXwoCGF1JlbIdO2mUnKi7txk7EJxMtbtd4dKKYF2Km9GrMZDZVUZSo
OOMLyJJoPi16Cz5f9eKJ0r3c7ejtDyJTThbSGPApVjlIz04vXzL2gPHUKDCQ
WSJygX+yotNlHZHIQmnJUxqcHT/Hf0rj6+LyZSfKysUEV40SiDGOYpXhCqY0
Y1boUkQQ9yDiWnCcepznqYzt7QzjWYIb87R3KReiEy2V/jDTqszper9HPa85
XSbjWSzsWad3GNGFoKgPYoXzknHEeizUFY1zXsxNLmL6/vu78zfh2j+D79a+
W5GVuBxj/zURGXOK7/yEixM+fqCTaX7BZYp5stj3UhTTvtIzmuc6nmN+XhS5
Ge/tLZfLvl/eoz09IpC3Ym8pJnu0ey8utYYwdjWVpujPi0VKR81kMS8nOEyr
Oc8IIHshQIgkhTVNEfCrSftud1+q1qa9e9BWMY14WcyVJpPgdMamZZo6lF7Q
wdDVfGUXcB2eyV+tBsd2RjiNWAHslb+f0Uw/VosoypRegPYW1okI/s2o3+9H
Ua/XY3xiCs3jIopCmzIJDDKzgrHuWKGYJLDL6YomYY9UOATc8rQUbKrVAgt2
Jqkcki2hB9gVhplIMNAyXTHIlKfijmVQnkgYGJdxUWrRj84KyzHjqZqp0hDL
EH6Q1Qq7kEmSiih6wM6yQqsE26GIb4iOK9eyE45q8b1YKwZnL7QQ5LPCRSEK
QtV1Pn3608XLF48Pnxx++VIHGyKt1o34WAog2N4g1+oWzAzMl1nBeCqL1f23
wunf4fTRk/0BTp+UBWTJc6VtRCzmwsKAaZ7NhI2LxJD8wvRJA3CyW7qYDxcn
YiozacdRdInd8HNGjm5Y5/X7d5cUneh/9ubcfl+c/uP92cXpCX2/+/H41av6
I6oo3v14/v7VSfPV7Hxx/vr16ZsTtxmzrDUVdV4f/4wVkqpz/vby7PzN8asO
4i8uBePUEEHgI5VMBLPqQHQgVHATQYexlhMMsOf5i7f//tfgsDLFcDB4AmVV
dhkckV2Wc5E5bioDytwQ+ltFPM8F13QKhyZjnssCMRy0hpm5WmZsLgh90Z+v
SDPXY/Z0EueDw2fVBF24Nel11pq0Otuc2djslLhlagubWput+TVNt+U9/rk1
9noPJp9+l8pMsN7g8XfPIoJQA5koOmYbTkTOqzm5LeKysagEDH2KAAoJZQRB
LTwl9pA5F5TKkPJXFq+J9a279pzbPZXaFPWRTOVCU2iFIa0DaKWsN9K3FQ8H
tfwuAJOxVDmnoO49uSViOz4hEsZzYZqj/c1vrq5vAIlTim28cEGjRQCYlhpO
JxDhMAzVVCCntcIMDpGJ216JZIsDf8RNBg8nbg8Q0Sqlsbdewc6NDSI8LhDb
2gjMvHIbrblqxOuMtOt1tq6NqMfOtq2E5u4ynO0FJFI4kVY5CpxCeHpKPT0m
/VGVHO6QEmCZZdZ3UXkJbc8Lte158gJD/POr0Ko34QZbcmUsHF1KIWJTcF1D
wMr313t5Oz1nYmaTXMN/Lu54ImK54Cnbvxvut6RJuSnCwF/z6boUNpczsrKr
4wxbIMTDwBMef1hyiq3FHKXJbN7s+6aOwTrvtiX3wuBGgaJUVhsRWyiWm2Dc
Z2dtG7lE3N7Q/7YkBZ/9Lkkspvis0sA9nCWMnghP+xucJ6uCDKuhyO49RFr0
hHNAmxFQ5SAbJMK5Up9drpm+Rcsniqw/bbwBpRdMGLCFy8QqoY8W8K1x4J7t
K9gg1LpAKwS5zLMOxpZElSxVHKpj1xLJhy01JSmb6bwgLh6c3nGqloyD4bbo
8ANQ7nx+qtJULek+RpU6CIvdyiQTxKKJAA2q29vKqLFCAWxylVlF4LNMKUR8
/fqV2RI1kXwWHR0d7VzB465ssXk1QL4vlgrJ/eC666YOMTXFoZgbXWPKzn+y
awNUyHwSdxwl8s6YzR8OhgeHD91M564zZhQC3fDg0ZgNdgZHo/3R49FgNNqt
qFagumId218tOsTjC608feq4DMfs8FFFmicfQTxFkhdE9uwZzQ+P6N/5Q4iS
iOnD6HqXLokM+Lkd2D+jRSElsM/R517z9xf/gWl2dXR0zezfZys5qyaPSCM0
eTUEQTP55HoLJQ2vN6f3ae7qCkp2OoaKod1KuaPr6/Dc/S4bOPJG/6MNCk/k
CMLVZokMtLYCS9m1ylibq9XmNfkJHHcdu7O6Ybh08MiutAy8QeKlamjWSAAG
d22CA6Fhc72+2WL9Xp1fO1vEHlZ3PXzCh/vDweNhMjo42h8dHg2m7bsPPe3h
o7Vpizu7ZKG3trofMK1ce9OZ67kQkoaVxkZU2zvYiEy1BXbIqYzrVO+DE3U7
goPGRyK0JUEY3FoUtFPzHTZR0CL6bpVMsGwDREnBiGKdC/8u8htXxVOmRr9K
wc62XOs1CmpucReLvEr5CHa+HgxJwgiNCKkS1yRi6NiUWRgtEUhxFapKmuve
o0XazNMlRxINTvCZ7ebp5fOTwTPUYaekvDrU24gstp1oI7wr/+zV6b4+FdrT
9p/dWEVsu1F1vum6PrLOGhBlhmUb7oP038R2wsHYhq0TXnB2STb9zC5xg+0R
i0DoSlMXryDX0CKTCgTWTB7YSdJEMHloJ+tc5SYfWQTbztN1qZWcSDpb6lLh
M9jOzbp/3uxSeaa2osBlqJKu2s5FZKWdK1b/BY5Ub7dpgMTfAcfdLhGRgjDw
K8OdAc3TyhBgPrYKqmziaQ52IKfb/doVUyS4X8UBXoDNE3xyea4KVxTWeiHX
qe8LBdJbl/elppK6sXELWPxRLcUtla98i7NYa2kxFdpCC5rkLJFTjAm51tuX
qkxrX/WNxgt6gCSTUh+2qXznZUZMy5TaaAzahxoUDXSqbdkbr0+Ve7esK6HE
tov2DYRcxbcwaMJXbCE49Uhg0Q+iXiOCzG5VaovsuugLvIhKw4+l7TjBLkmk
e2cJQFf1OuylbTotAl0ko33QcVDnN5Cte78m0N+wneVcIh7UzRrFfQKuafvl
b+K0hdS39yJ1K1aHboXWDvQ2tLrYs0MxB6QPXGUrQpU1oB7u1vJ4WA9rwF7S
2wx1enDtlc0qm7ZZ8A/UH5DCjJFUVAJ5AYSrCtfJkDRdCUG4in6BYP1ow0ZN
sGu4V7bh9D5OqUnZcKO0nEmyfLX//8cKbLsVvJ4bOLFPwzEq16pqtZXDFwbc
UcdQmKYip5LBsXwpU8pnUeSGUzekxy1U9qb+NSV45QwEhTS+LfEPjPRk4X92
KebK1M05zpxxNHUUtZTNc2H6owYMYHHsawO1u55quy1H2mIEveJaKeJCjsWB
O3rJXTz4IJKujTjQXJ8d+xeXioocMsidNqXDEiN6WGkhTNK7rj+aWFVnu6eI
EH1rgvkUR49lDeTWuqxvqUNRDq3Lsyr8oMhv9N0qzjbaMNuCrTdfa63Xtffj
tQctB5qq/XMgMaG31hVe20xlllTlTVsZ3cBMBjDP6oqG8nyVYClOhoWliwRO
2G2eOmp5ahvurs1sO/JboXuea/s3rOqvkuP+LO/bV98auXOdnHWtnQds8vr5
j9yydmcU2AuMJeGhMaZmWWDbpU+azvcJcPZFIvBG3sa0Q5Rj5aHRemltoF+/
If40F9m6g7eAsBO+ULb57Tp4dGu/pc3rIbYlFHG+Gl3f/E/j7n4TdwcQamut
FkBnC27WkPOHoFNt2I6fGkFrGPpDILLHVM8cVaKp2W4mmvrd4gF7J+JS049L
VNAhmmruf/g5PzmvVy3p2fGb4y1kDHRazFCoQZyR6zEpfw3qF03S7a4t6Qbt
DselOf+bHD2FEp/j+EOmlqlIZhb00aexezEUyd86Nrd1vlTi8ZpS9KP/AFAS
+a8eIAAA

-->

</rfc>
