<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-amsuess-core-coap-over-gatt-01" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>CoAP over GATT (Bluetooth Low Energy Generic Attributes)</title>
    <seriesInfo name="Internet-Draft" value="draft-amsuess-core-coap-over-gatt-01"/>
    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization/>
      <address>
        <postal>
          <country>Austria</country>
        </postal>
        <email>christian@amsuess.com</email>
      </address>
    </author>
    <date year="2020" month="November" day="02"/>
    <workgroup>CoRE</workgroup>
    <keyword>CoAP, bluetooth, gatt</keyword>
    <abstract>
      <t>Interaction from computers and cell phones to constrained devices is limited by the different network technologies used,
and by the available APIs.
This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile)
and its use cases.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t>Discussion of this document takes place on the
  CORE Working Group mailing list (core@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/core/">https://mailarchive.ietf.org/arch/browse/core/</eref>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://gitlab.com/chrysn/coap-over-gatt/-/tree/master">https://gitlab.com/chrysn/coap-over-gatt/</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default"/> can be used with different network and transport technologies,
for example UDP on 6LoWPAN networks.</t>
      <t>Not all those network technologies are available at end user devices in the vicinity of the constrained devices,
which inhibits direct communication and necessitates the use of gateway devices or cloud services.
In particular, 6LoWPAN is not available at all in typical end user devices,
and while 6LoWPAN-over-BLE (IPSP, the Internet Protocol Support Profile of Bluetooth Low Energy (BLE), <xref target="RFC7668" format="default"/>) might be compatible from a radio point of view,
many operating systems or platforms lack support for it,
especially in a user-accessible way.</t>
      <t>As a workaround to access constrained CoAP devices from end user devices,
this document describes a way encapsulate generic CoAP exchanges in Bluetooth GATT (Generic Attribute Profile).
This is explicitly not designed as means of communication between two devices in full control of themselves -
those should rather build an IP based network and transport CoAP as originally specified.
It is intended as a means for an application to escape the limitations of its environment,
with a special focus on web applications that use the Web Bluetooth <xref target="webbluetooth" format="default"/>.
In that, it is similar to CoAP-over-WebSockets <xref target="RFC8323" format="default"/>.</t>
      <section anchor="procedural-status" numbered="true" toc="default">
        <name>Procedural status</name>
        <t>[ This section will be removed before publication. ]</t>
        <t>The path of this document is currently not clear.
It might attract interest in the CoRE working group,
but might be easier to process as an indpenendent submission.</t>
      </section>
      <section anchor="appplication-example" numbered="true" toc="default">
        <name>Appplication example</name>
        <t>Consider a network of home automation light bulbs and switches,
which internally uses CoAP on a 6LoWPAN network
and whose basic pairing configuration can be done without additional electronic devices.</t>
        <t>Without CoAP-over-GATT,
an application that offers advanced configuration requires the use of a dedicated gateway device
or a router that is equipped and configured to forward between the 6LoWPAN and the local network.
In practice, this is often delivered as a wired gateway device and a custom app.</t>
        <t>With CoAP-over-GATT,
the light bulbs can advertise themselves via BLE,
and the configuration application can run as a web site.
The user navigates to that web site, and it asks permission to contact the light bulbs using Web Bluetooth.
The web application can then exchange CoAP messages directly with the light bulb,
and have it proxy requests to other devices connected in the 6LoWPAN network.</t>
        <t>For browsers that do not support Web Bluetooth,
the same web application can be packaged into an native application
consisting of a proxy process that forwards requests received via CoAP-over-WebSockets on the loopback interface to CoAP-over-GATT,
and a browser view that runs the original web application in a configuration to use WebSockets rather than CoAP-over-GATT.</t>
        <t>That connection is no replacement when remote control of the system is desired
(in which case, again, a router is required that translates 6LoWPAN to the rest of the network),
but suffices for many commissioning tasks.</t>
      </section>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
    </section>
    <section anchor="protocol-description" numbered="true" toc="default">
      <name>Protocol description</name>
      <section anchor="requests-and-responses" numbered="true" toc="default">
        <name>Requests and responses</name>
        <t>[ This section is not thought through or implemented yet,
and could probably end up very different. ]</t>
        <t>CoAP-over-GATT uses individual GATT Characteristics to model a reliable request-response mechanism.
Therefore, it has no message types or message IDs (in which it resembles CoAP-over-TCP <xref target="RFC8323" format="default"/>),
and no tokens.
In the place of tokens,
different Bluetooth characteristics (comparable to open ports in IP based networks) can be used.
All messages use GATT to ensure reliable transmission.</t>
        <t>A GATT server announces service of UUID 8df804b7-3300-496d-9dfa-f8fb40a236bc (abbreviated US in this document),
with one or more characteristics of UUID 2a58fc3f-3c62-4ecc-8167-d66d4d9410c2 (abbreviated UC).</t>
        <t>[ Right now, this only supports requests from the GATT client to the GATT server; role reversal might be added later. ]</t>
        <t>A client can start a CoAP request by writing to the UC characteristic
a sequence composed of a single code byte, any options encoded in the option format of <xref target="RFC7252" format="default"/> Section 3.1,
optionally followed by a payload marker and the request payload.</t>
        <t>After the successful write,
the client can read the response back from the server on the same characteristic.
The client may need to attempt reading the characteristic several times
until the response is ready,
and may subscribe to indications to get notifiied when the response is ready.</t>
        <t>The server does not need to keep the response readable after it has been read successfully.</t>
        <t>If the request and initial response establish an observation,
the client may keep reading;
the server may keep the latest notification available indefinitely (especially if it turns out that "has been read successfully" is hard to determine)
or make it readable only once for each new state.</t>
        <t>Once the client writes a new request to a UC characteristic,
any later reads pertain to that request,
and any observation previously established is cancelled implicitly.</t>
        <t>Attribute values are limited to 512 Bytes (<xref target="bluetooth52" format="default"/> Part F Section 3.2.9),
practically limiting blockwise operation (<xref target="RFC7959" format="default"/>) to size exponents to 4 (resulting in a block size of 256 byte).
Even smaller messages might enhance the transfer efficiency
when they avoid fragmentation at the L2CAP level.</t>
        <t>If a server provides multiple OC typed characteristics,
parallel requests or observations are possible;
otherwise, this transport is limited to a single pending request.</t>
      </section>
      <section anchor="addresses" numbered="true" toc="default">
        <name>Addresses</name>
        <t>[ ... coap+bluetooth://00-11-22-33-44-55-66-77-88-99/.well-known/core ... ]</t>
        <t>Note that when using Web Bluetooth <xref target="webbluetooth" format="default"/>,
neither the own nor the peer's address are known to the application.
They may come up with an application-internal authority component
(e. g. <tt>coap+bluetooth://id-SomeInternalIdentifier/.well-known/core</tt>),
but must be aware that those can not be expressed towards anything outside the local stack.</t>
        <section anchor="scheme-free-alternative" numbered="true" toc="default">
          <name>Scheme-free alternative</name>
          <t>As an alternative to the abovementioned scheme,
a zone in .arpa could be registered to use addresses like</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
coap://001122334455.ble.arpa/.well-known/core
]]></artwork>
          <t>where the .ble.arpa address do not resolve to any IP addresses.</t>
          <t>[ Accepting this will require a .arpa registering IANA consideration to replace the URI one. ]</t>
        </section>
      </section>
      <section anchor="compression-and-reinterpretation-of-non-coap-characteristics" numbered="true" toc="default">
        <name>Compression and reinterpretation of non-CoAP characteristics</name>
        <t>The use of SCHC is being evaluated in combination with CoAP-over-GATT;
the device can use the characteristic UUID to announce the static context used.</t>
        <t>Together with non-traditional response forms (<xref target="I-D.bormann-core-responses" format="default"/>
and contexts that expand, say, a numeric value 0x1234 to a message like</t>
        <t><tt>
2.05 Content
Response-For: GET /temperature
Content-Format: application/senml+cbor
Payload (in JSON-ish equivalent):
[
    {1 /* unit */: "K", 2 /* value */: 0x1234}
]
</tt></t>
        <t>This enables a different use case than dealing with limited environments:
Accessing BLE devices via CoAP without application specific gateways.
Any required information about the application can be expressed in the SCHC context.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA considerations</name>
      <section anchor="uniform-resource-identifier-uri-schemes" numbered="true" toc="default">
        <name>Uniform Resource Identifier (URI) Schemes</name>
        <t>IANA is asked to enter a new scheme into the "Uniform Resource Identifier (URI) Schemes" registry set up in <xref target="RFC7595" format="default"/>:</t>
        <ul spacing="normal">
          <li>URI Scheme: "coap+gatt"</li>
          <li>Description: CoAP over Bluetooth GATT (sharing the footnote of coap+tcp)</li>
          <li>Well-Known URI Support: yes, analogous to <xref target="RFC7252" format="default"/></li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security considerations</name>
      <t>All data received over GATT is considered untrusted;
secure communication can be achieved using OSCORE <xref target="RFC8613" format="default"/>.</t>
      <t>Physical proximity can not be inferred from this means of communication.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7252"/>
            <seriesInfo name="RFC" value="7252"/>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7595" target="https://www.rfc-editor.org/info/rfc7595">
          <front>
            <title>Guidelines and Registration Procedures for URI Schemes</title>
            <seriesInfo name="DOI" value="10.17487/RFC7595"/>
            <seriesInfo name="RFC" value="7595"/>
            <seriesInfo name="BCP" value="35"/>
            <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor">
              <organization/>
            </author>
            <author initials="T." surname="Hansen" fullname="T. Hansen">
              <organization/>
            </author>
            <author initials="T." surname="Hardie" fullname="T. Hardie">
              <organization/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t>This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes.  It obsoletes RFC 4395.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7668" target="https://www.rfc-editor.org/info/rfc7668">
          <front>
            <title>IPv6 over BLUETOOTH(R) Low Energy</title>
            <seriesInfo name="DOI" value="10.17487/RFC7668"/>
            <seriesInfo name="RFC" value="7668"/>
            <author initials="J." surname="Nieminen" fullname="J. Nieminen">
              <organization/>
            </author>
            <author initials="T." surname="Savolainen" fullname="T. Savolainen">
              <organization/>
            </author>
            <author initials="M." surname="Isomaki" fullname="M. Isomaki">
              <organization/>
            </author>
            <author initials="B." surname="Patil" fullname="B. Patil">
              <organization/>
            </author>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization/>
            </author>
            <author initials="C." surname="Gomez" fullname="C. Gomez">
              <organization/>
            </author>
            <date year="2015" month="October"/>
            <abstract>
              <t>Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group.  The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices.  The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc.  The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6.  This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="webbluetooth" target="https://webbluetoothcg.github.io/web-bluetooth/">
          <front>
            <title>Web Bluetooth</title>
            <author initials="R." surname="Grant">
              <organization/>
            </author>
            <author initials="O." surname="Ruiz-Henríquez">
              <organization/>
            </author>
            <date year="2020" month="February" day="24"/>
          </front>
        </reference>
        <reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8323">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
            <seriesInfo name="DOI" value="10.17487/RFC8323"/>
            <seriesInfo name="RFC" value="8323"/>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <author initials="S." surname="Lemay" fullname="S. Lemay">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization/>
            </author>
            <author initials="B." surname="Silverajan" fullname="B. Silverajan">
              <organization/>
            </author>
            <author initials="B." surname="Raymor" fullname="B. Raymor" role="editor">
              <organization/>
            </author>
            <date year="2018" month="February"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t>
              <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613">
          <front>
            <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8613"/>
            <seriesInfo name="RFC" value="8613"/>
            <author initials="G." surname="Selander" fullname="G. Selander">
              <organization/>
            </author>
            <author initials="J." surname="Mattsson" fullname="J. Mattsson">
              <organization/>
            </author>
            <author initials="F." surname="Palombini" fullname="F. Palombini">
              <organization/>
            </author>
            <author initials="L." surname="Seitz" fullname="L. Seitz">
              <organization/>
            </author>
            <date year="2019" month="July"/>
            <abstract>
              <t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
              <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7959" target="https://www.rfc-editor.org/info/rfc7959">
          <front>
            <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7959"/>
            <seriesInfo name="RFC" value="7959"/>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
              <organization/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates.  In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS).  These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t>
              <t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t>
              <t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations.  Therefore, this specification updates RFC 7252.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="bluetooth52" target="https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=478726">
          <front>
            <title>Bluetooth Core Specification v5.2</title>
            <author>
              <organization/>
            </author>
            <date year="2019" month="December" day="31"/>
          </front>
        </reference>
        <reference anchor="I-D.bormann-core-responses" target="http://www.ietf.org/internet-drafts/draft-bormann-core-responses-00.txt">
          <front>
            <title>CoAP: Non-traditional response forms</title>
            <seriesInfo name="Internet-Draft" value="draft-bormann-core-responses-00"/>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization/>
            </author>
            <date month="November" day="12" year="2017"/>
            <abstract>
              <t>In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request.  The present memo describes two forms of responses that go beyond that model.  These descriptions are not intended as advocacy for adopting these approaches immediately, they are provided to point out potential avenues for development that would have to be carefully evaluated.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="change-log" numbered="true" toc="default">
      <name>Change log</name>
      <t>Since -00:</t>
      <ul spacing="normal">
        <li>Add note on SCHC possibilities.</li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAPR1oF8AA41aXXPbRrJ9x6+Ykh+ulCUoifqwxNStvYpsJ9r12irJrjzs
bq2HwJCcEgggmIFoxqX8o/0H+7Z/7J7TMyBBSqmKKxWTBNDTH6e7Tzecpmni
rS/MWO1dV1e3qno0jfrx6tMntf9D0RpfVX6u3ldL9bY0zWylfjT422bqyvvG
Tlpv3MFekldZqReQkTd66lO9cK1xLs2qxuB/uk4pNZ1p79Oj48TWzVj5pnV+
dHR0eTRKnNdl/i9dVKWRCybJtB8r87VOlrOxuq7u3iYPS364uh2oSafWQFFi
ols/r5pxkipbOtw0VFcL99//OJcoFbS6njfWeavL3pWsakvfrMbqCno0VuMn
s9C2GKusu/v/oh3DrFokZdUstLePZow7795dvx6djbqPZ5dn48SW091bzs8v
+HFpJmud+V2p6PGfzUStnSwXOluU/Enj3ypYdjdUPza69C9f/ThUd639Nf3J
lM1///1La36V67n2OGl0NDpKj0bp6FR+DJp2x/z06W/vx2rufe3Gh4d9bbPZ
cGb9vJ0MbcUL6frKYTDx4mR0Eq29OD/uPr6+PLvc8cH6weC1tQs2GLsGWNR9
bTI7tQi/rUr1eDYcbRlxfJkej9KT4xeMuH3zrmfDcjlcnzismtkhELrQ5eEc
QCtM4/B9WRaVzvH7ULv51z/jw79s/r+nry9ej84T/EnTVOkJsKEznyQ3pTf8
RLWmTbUAfhY10N84BZEqM0Wh6jkA7JSvcLHkg7Y0ucrNo83ws3WqsAvr8dNk
pfzcqNxOp6YxpVel8cuqeVDeZPOyKqqZxQOtM/kgofR4v34EPvWkMOrq9sYN
k09zyITe7YIycuMyZCQe1MghXbq6ajydJM9e9zS6quuic/FtU/kqqwq1z+Q6
wL3a82TXi0yoBs8Sn89ObWEOREfrRWOVaTw8DO5b2BzeTpJXCu5rqrwN/vv2
yva+PiUw5I8r+O1bTL6nJ5xVqokRR6klcPqCR6naxht9/w4S+sZ81YsaHv38
BqWvVOfvq59vrz50j9OQD5VXGtFFYsK8FyOlm35w4ECDU6FVswl+KVHAF1ta
v1LVVL6/gJNBspzbbI4n5nZCp+a2MZkn3hZt2XmFZpUGtzvrkRtOpNH9EIyi
aJZ6tT4bVmZF1eYKCskvQ6BZ1brxNmsL3QzWVgNOJa3tm0LTqf2qxtnFM8sC
QKEy7o5iQrH/4f1btX9ze4+CTd0kf+C8TTzv21piElFEzV9sOPuQdDCIcUc1
eXo6ALBmc8/QMwvhEeoqWalVo3NbqboCxCjy0ZrlIEHqw+c1Mtjbcqbcynmz
EM/UhfYsJEhOnT0oF5UiNKwfJMaxIMEHKzpBi+mpzsTxPBR+BkSumHOEhW7Q
VXJWgHDPVoClvXZBEW2fO9P/bkozoqbMdO0QMyTfLKajSDVfM1S2WQDaH0/c
WELwH1otMg4leSUIwMF2Rp21UwuD7KErtxE4QSIYA2Asqz7Kpy3wAquR30VE
+cKZ4hFXyTQkh9y8aosckcLFRk1aiy/I5JtbNdFM5ZdzVwzVDJqd2VJC4kK3
MDkQ7WkGgg6fBr111JyhhHTdqymIDzyrayPQlKosF8RM5pwpH21TlQwC8pGV
RauIBMjLWsdagX7Yl+rWtVOkbvV2oLffVp+eJAV5/wDnUXMHJZCLVI2GhhyC
jPsqezDQSODPbstnk1evGMPM5G0DjUCffOuS5B9/VxJPZ0KdXVrEAknSmAXE
oY2YKXts3U46nYfqH/8M5RdZNA/x6gMQn7O2YUGNwMgKoxvxdkhB8C92RXF8
Y5zvCh0pm2QE022GrKgHCaC3SVyjnTVibk1DkCoMWYnn8xp4RRBxvGsnC4tM
g6JiM/rCJoixcicJO4fNIUyvkQND5tXCkE5Vi3B7EU5ui0no2A5hzeb9essC
JbCS9hfIMHN+pyfEgkcgA67Iq1rbhmYC9VM7a5twXuxNOSiB9KYK1oNuWF5k
HS0QJEAMz8fsgYk/x/s2CGAGs8Ruw5c4q9jpYEr+qEsAYef0xvzSom9s9QWN
k3LKwN3bPSJhiihEyTMklM6SAAl1zVwqN9KNFDfAaKmbfFMD5uviH5KWWVWx
XUSfhY4j/CkzgwAyy2xDukKHApy56bJ2aZtnCopUDSw6zyJf19FZzzwV8nkT
aUYBLjLodSEvu2L0aLVCYwntK7binv/67qaMpi2jdkhr9FwzlKyR4l3qRzsL
TbgK3utuGqjAjPDog1NoPxHNkSJ6Zs6uxq0jlraqRzhrp9yIWni4XBf/ANkF
ckmzEwTeADhL/do+Jpg914+G2iEDv64EMshgsaKSytyVdagKrkHY2O1Yr6Ob
vAOCJk21dMSk+CCvpGB0DXXLoBAnh9nsRasmLEfZA6zgiWymJZzMwap/a8Le
ykEN7hJ0BzO6ciJKRKC6jXHwibEshgTAi5W2KiN+q3pCSiCFYaoBwq3a3GUm
cRktF7IRDgZeQu513eqZoUIntkEH+UzVni6xRUJkuXP0kGVb+y42IpHsDQaC
0mRGyveS8GD192anJ0cKxGfY65FxyT40CqWQFB7QnYG2DDZ1wbququTBRmnN
hQC/A4QkABuO891BESMHof67djoN/AeAEVZGVhGygoH0zBQWe/WJ2SIMe4WB
wW++PfHqmkUGilQLINgi7rpAMzLQowZIzAu9MVJd1lsmhZ83/EBGaNlV6D7Y
uTI+xDgTxgJsTcCLV4G41QrBWG1mjtBMt8MUegmamn20eQsYyI/Xc81aaGTP
kEnGLSqUQTobxVCod0Rs2tmAxGaaW7eQctBILxf2MNcS+Jj4ZOqB9Hc/3Lxx
ahNcPACRZoEzXA9Tn65v+xzjIJgNsb56MKWLfMUoAZfEVn4fJJuRa8N2sh37
9oWmN2IXqws6vGJVEMa4S/vcQX+uGyZXIDHrosb8EBeSwpUODWnjMcHjhi9c
hRs59JAblCWoOZEXpyDa8PnzzRt1kU8vjk4nr9OTk6Oj9PTyPE8v86lOpxfT
yemRHp2cTzK1ryeTBuVQmufn+1AIe0zpINJEdnu6njxr1wvdgSN9djHNTqbp
SXY+Sk9NlqUXx+ev0/z8PD/NL0+Pj7LRzoHXoOqE8J1U8LJaxh5alWTBocT2
ipwMF4yWeCArLMMTc7PnlO+R2oI0fHbA5pqcgafgVKZ2E0B91QlhZEA3UdBD
9ezO5Ipi2VgpxvGgz9c7HkjAoXk3oiBzW8WgS+Vmyyv4Yw5OtQp9k/NaoNV4
oMo3zSf8HLc/fL6/EbiP6X0yPB4k4U6hdNOqKKplWL2gU+gVdz8oQM2DYCOP
ZSvYEi8TQ9PAiFAvWxnoMN6InSa0sJ5XGqM7KTFhpXusQxFxGLuL9L5t94Qu
HyUuQH1KE9gWOLZZ1F5OEP/Odx+FcMhGBL1FpiRt6W2xrYsUb52vQlpTOrh1
GC55BAvUeoqpMFsSZB6jleVmZR4p3jNpwzA7RNPyyoSi2in+YEy9/SCfCosF
cWwsXhNjov82Xi4o/Ga6FRchUyVABkvXInEBEq2bkyVUE+oihmwFiAaLNtGH
3ye9kKwvSttnP+us75Yt630I/GSmVMEAU/v95QDnRuXbhjNk60OD3Pt94/bo
wzk5tOf4HNqbOUikKz6YUKWjryTJK2aNLKw0ingJnsGpDzQ0+cgrPVsFnk6G
oeXadYTR84wkGlYhz+U44ahe23LNZOPzkegwKTceRjtEgapax4bYRYF5KrSb
G1F+WXSLBabTegPxqNEswuKsW4riyLPjkfphRe33v33rbYyR2LesOe96+T0a
XqLoxplCYiCCmCATzB4PSxL+uPLBA/uhSlyeXXJ/hLOc/dVw7YGKXQbSe6r2
gaq2EBlCz0RQuBN1ZnR2LtUJtfjtI4LqFjjWNJvmFOqnKee6C4m0JLRHZUh7
EJ5slXTphEL0WNkcFULP2EIi1sJE8H50jeJaIK2LkAe6Qys4CKgET6OmXF1+
vJaen+82HHgH36FisekMAFAvgiEAKMSyzPo+EdpPx8X2slm+9JbXAqVYsdHI
pSRF+XFKz3P4sWNdw+FQ8RXQnzavQA4P0WiPj9PRCD03PT1Nz87S8/P09ev0
4iK9vDwcLoGd9AFtrjzkKySRwTb0gUQ2TFh04guj0rNFyyApjY0kGlFcYpKI
G/HamOZ/OECLtuIJObLrXz2yLqV5JYUi41oB1C8shbYGxbRbIcS3ONzzSp8j
wpJ9M1SzofryzBc2T+8h9CY+fMPNB5dazTM/fIkketG60KaXVDpwcdlHsA+x
AE8E2RIExiuMQMheBJXDUuu5L+lN6Uje7EGC90rdZxiSTTptDA4oRCdOXmHJ
WfZ/WjtqAgZJBMMHOM+JAFQM9SvZEBJpqJtaRwot66gZAGriLoGMTneIAcge
cNRvv/2W0E+ClOPj0ejk5PT07GwIkIqsZ56RJ5hZTTBrfec6vHEcxeeqCKqz
moF7rs8ODOsKNboONIYZICu0OPYA9kFmZwDvurn6cCVbXm6g1mNcHMICD7q7
IS0MCIaDrwEJntit8RsjuMFvsQSg1JRAk9CrnZROuq0Db7q//umaiTkxVMSw
pOo4pAN2E1vquAV8ticJ7S+uVgiabmm5QyuEroqrAnkO1IVqZjJPmq8+kvTk
UwXSwDST46i/5yY+brvW3Tqs2lGM/3yTvhlOyOHKMrwnXg9rT09x5JID4iQP
POPHAYjTijNpCdbNnbb0EXX09Xh0choqUzf1BCR9+fIlGQ2Pzvh6yTMN7+Ip
6buqGasf335Sh2RXjB2GiSTexqt8t9hP70NnykXxpwxKJ7eRQHKs+sv9xw8p
+QdRAn04DYyTv8tryW/H6vA71YIwqO8Ox2rvr3sDNeJPQW/+FnR/Sv4puoaF
vCm1jGe690Kre7cWlgG50QWjLt7uKnNva+3GyVV4S4Gb+Cqm2+V0a4/NTrK3
k4j79KzbviEnrsrVZuxfv+ImdCeB55iX1jeb6hNJu2A1RlTG++d54yQ7PpeW
Z2COd1XbAHKbeqj2kUoHsUDhbhFhuTh+CKWEM3sTiU+oQmF9RAX2/rDgvZjf
GO0deDBqPWwI7OHs8uzpaZwk30lSh/sRVSnp/KcIe7jyZrOQGKvNv6jYfSnj
kGkdmZ/i95KtTV6yQJbP6gOI+plF7q/Sk+S8MOeN1co4Tki6qGZgX7S8NwLR
uWBJbWw/2w7mLJ1rrzdrsM0/97BufTt+5z+OQJsx+feJozSz8/onBhpk1BrK
Cb344/31x7u3cZFwfhxeVtzOV07eHXJBR6iu+o0KmDINT4yTkv29N07xnTKn
Ktp4HXae8EGS3FsWp/ToSGID/qGCO8uAu0BwbIFqxDL//ymqQ5bzIgAA

-->

</rfc>
