<?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.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-cbor-pointer-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.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-00"/>
    <author fullname="Rohan Mahy">
      <organization/>
      <address>
        <email>rohan.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="17"/>
    <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(TBD1), # 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(TBD1)  # 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:
H4sIAAAAAAAAA81Z73LbuBH/zqdAlQ+xW0mWZEdO1DRXJ3bu3Eni1PHN9cbj
GUMkJKGhCB5AWtYluWfps/TJ+luAIEFJzt3NtDP1h4QAFtjF7m//Qb1eLypk
kYoJ67x6eXHJ3iuZFUJP2AeRiriQ2ZydpWIpssIwNWOvVBZLI9hLmXG9ZhfT
f4KIXYpcCwMaXkiVsT06aZ+dqri0GzsRn061uNvg0YliXoi50usJk9lMRVGi
4owvIUui+azoLfli3YunSvdyt6M3GESmnC6lMeBTrHOQnp9dvWbsEeOpUWAg
s0TkAv9kRafLOiKRhdKSpzQ4P3mJ/5TG1+XV606UlcsprholEGMSxSrDFUxp
JqzQpYgg7mHEteA49STPUxnb2xnGswQ35mnvSi5FJ1op/XGuVZnT9X6Let5y
ukzGs1jYs87uMaILQVEfxRrnJZOI9VioKxrnvFiYXMT0/bcPF+/CtX8E3619
dyIrcTnG/msiMuYU3/kBFyd8fEsn0/ySyxTzZLG/SlHM+krPaZ7reIH5RVHk
ZnJwsFqt+n75gPb0iEDeiYOVmB7Q7oO41BrC2NVUmqK/KJYpHTWXxaKc4jCt
FjwjgByEACGSFNY0RcCvJu273X2pWpsOHkBbxTTiZbFQmkyC0xmblWnqUHpJ
B0NXi7VdwHV4Jn+2GpzYGeE0YgWwV/7rnGb6sVpGUab0ErR3sE5E8G9G/X4/
inq9HuNTU2geF1EU2pRJYJCZNYx1zwrFJIFdztY0CXukwiHgjqelYDOtlliw
M0nlkGwFPcCuMMxUgoGW6ZpBpjwV9yyD8kTCwLiMi1KLfnReWI4ZT9VclYZY
hvCDrFbYpUySVETRI3aeFVol2A5FfEV0XLmWnXBUi+/FWjM4e6GFIJ8VLgpR
EKqu8+nTHy5fv3p69Ozoy5c62BBptW7ET6UAgu0Ncq3uwMzAfJkVjKeyWD98
K5z+DU4fPxsMcfq0LCBLnittI2KxEBYGTPNsLmxcJIbkF6ZPGoCT3dHFfLg4
FTOZSTuOoivshp8zcnTDOm+//3BF0Yn+Z+8u7Pfl2d+/P788O6XvD9+dvHlT
f0QVxYfvLr5/c9p8NTtfXbx9e/bu1G3GLGtNRZ23Jz9ihaTqXLy/Or94d/Km
g/iLS8E4NUQQ+EglU8GsOhAdCBXcRNBhrOUUA+x5+er9v/81PKpMMRoOn0FZ
lV2Gx2SX1UJkjpvKgDI3hP7WEc9zwTWdwqHJmOeyQAwHrWFmoVYZWwhCX/TH
a9LMzYQ9n8b58OhFNUEXbk16nbUmrc62Z7Y2OyXumNrBptZma35D0215T35s
jb3eg8nn36QyE6w3fPrNi4gg1EAmik7YlhOR82pObou4bCwqAUOfIoBCQhlB
UAtPiT1kziWlMqT8tcVrYn3rvj3nds+kNkV9JFO50BRaYUjrAFop6430bcXD
QS2/C8BkLFXOKah7T26J2I5PiITxQpjmaH/z2+ubW0DijGIbL1zQaBEApqWG
0wlEOAxDNRXIaa0wg0Nk4rZXItniwB9xm8HDidsjRLRKaey9V7BzY4MIjwvE
tjYCM6/cRmuuGvE6I+16nW1qI+qx810robm7DGd7AYkUTqRVjgKnEJ6eUk+P
SX9UJYc7pARY5pn1XVReQtvzQm17nrzAEP/8LLTqTbnBllwZC0eXUojYFFzX
ELDy/flB3k7PmZjbJNfwX4h7nohYLnnKBvejQUualJsiDPw1n65LYQs5Jyu7
Os6wJUI8DDzl8ccVp9haLFCazBfNvq/qGKzzbltyLwxuFChKZbURsYViuQnG
fXbetpFLxO0N/a9LUvD5b5LEYorPKw08wFnC6InwtL/CebouyLAaiuw+QKRF
TzgHtBkBVQ6yQSKcK/XZ1YbpW7R8qsj6s8YbUHrBhAFbuEysEvpoAd8aB+7Z
voINQq0LtEKQyzybYGxJVMlSxaE6dq2QfNhKU5Kymc4L4uLB2T2nask4GO6K
Dt8C5c7nZypN1YruY1Spg7DYrUwyRSyaCtCgur2rjBorFMAmV5lVBD7LlELE
L7/8wmyJmkg+j46Pj/eu4XHXtti8HiLfFyuF5H5403VTR5ia4VDMjW8wZec/
2bUhKmQ+jTuOEnlnwhaPh6PDo8dupnPfmTAKgW54+GTChnvD4/Fg/HQ8HI/3
K6o1qK5Zx/ZXyw7x+EIrz587LqMJO3pSkebJTyCeIckLInvxguZHx/Tv4jFE
ScTscXSzT5dEBvzcDuyf0aKQEtjn6HOv+fuT/8A0uz4+vmH277OVnFWTx6QR
mrwegaCZfHazg5KGN9vTA5q7voaSnY6hYmi3Uu745iY8d9BlQ0fe6H+8ReGJ
HEG42iyRgTZWYCm7Vhlre7XavCE/geO+Y3dWNwyXDp/YlZaBt0i8VA3NBgnA
4K5NcCA0bK/XN1tu3qvzc2eH2KPqrkfP+GgwGj4dJePD48H46Hg4a9995GmP
nmxMW9zZJQu9jdVBwLRy7W1nrudCSBpWGhtRbe9gIzLVFtghZzKuU70PTtTt
CA4aH4nQlgRhcGdR0E7N99hEQYvou1UywbINECUFI4p1Lvy7yG9cFU+ZGv0q
BTvbcm3WKKi5xX0s8irlI9j5ejAkCSM0IqRKXJOIoWNTZmG0RCDFVagqaa77
gBZpM09XHEk0OMFnttvnVy9Phy9Qh52R8upQbyOy2HWijfCu/LNXp/v6VGhP
G7y4tYrYdaPqfNN1fWSdNSDKHMs23Afpv4nthIOJDVunvODsimz6mV3hBrsj
FoHQlaYuXkGukUUmFQismTy0k6SJYPLITta5yk0+sQi2nafrUis5kXR21KXC
Z7C9203/vN2n8kztRIHLUCVdtZ2LyEp716z+Cxyp3m7TAIm/B477XSIiBWHg
V0Z7Q5qnlRHAfGIVVNnE0xzuQU63+60rpkhwv4oDvADbJ/jk8lIVriis9UKu
U98XCqS3Lu9LTSV1a+MWsPidWok7Kl/5Dmex1tJiJrSFFjTJWSJnGBNyrbev
VJnWvuobjVf0AEkmpT5sW/nOy4yYlSm10Ri0DzUoGuhU27I3Xp8q925ZV0KJ
bRftGwi5im9h0ISv2VJw6pHAoh9EvUYEmd2p1BbZddEXeBGVhj+VtuMEuySR
7p0lAF3V67DXtum0CHSRjPZBx0Gd30C27v2aQH/L9lYLiXhQN2sU9wm4pu2X
v4rTFlLfP4jUnVgduRVaO9S70Opizx7xBOkjV9mKUGUNqEf7tTwe1qMasFf0
NkOdHlx7bbPKtm2W/CP1B6QwYyQVlUBeAOGqwnUyJE1XQhCuol8gWD/aslET
7BrulW04vY9TalI23Cgt55IsX+3//7EC220Fr+cGTuzTaILKtapabeXwhQF3
1DEUpqnIqWRwLF/LlPJZFLnhzA3pcQuVval/TQleOQNBIY1vS/wDIz1Z+J9d
ioUydXOOM+ccTR1FLWXzXJj+qAEDWBz72kDtrqfabsuRthhBr7hRiriQY3Hg
jl5xFw8+iqRrIw4012cn/sWloiKHDHKnTemwxJgeVloIk/Su648mVtXZ7iki
RN+GYD7F0WNZA7mNLutr6lCUQ+vyrAo/KPIbfbeKs602zLZgm83XRut14/14
40HLgaZq/xxITOitdYXXNlOZJVV501ZGNzCTAcyzuqKhPF8lWIqTYWHpIoET
dpenjlue2oa7azPbjvxe6J7n2v4Nq/qr5Hg4y/v21bdG7lwnZ11r5wGbvH7+
I7es3RkF9hJjSXhojKlZFth25ZOm830CnH2RCLyRtzHtEOVYeWi0Xlob6Ndv
iD8sRLbp4C0g7IUvlG1++w4e3dpvafNmiG0JRZyvxze3/9O4O2ji7hBC7azV
AujswM0Gcn4XdKoNu/FTI2gDQ78LRPaY6pmjSjQ12+1EU79bPGIfRFxq+nGJ
CjpEU839Dz8Xpxf1qiU9P3l3soOMgU6LOQo1iDN2PabNX/WLJul235Z0w3aH
Q2SDff+bHD2FEp+T+GOmVqlI5hb00aeJezEUyV86Nrd1vlTi8ZpS9KP/AFzu
OMoeIAAA

-->

</rfc>
