<?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.2.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7540 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml">
<!ENTITY RFC6202 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6202.xml">
<!ENTITY RFC8441 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8441.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>


<rfc ipr="trust200902" docName="draft-xie-bidirectional-messaging-02" category="std" submissionType="IETF">

  <front>
    <title abbrev="HTTP-PUBSUB">An HTTP/2 Extension for Bidirectional Message Communication</title>

    <author initials="G." surname="Xie" fullname="Guowu Xie">
      <organization>Facebook Inc.</organization>
      <address>
        <email>woo@fb.com</email>
      </address>
    </author>
    <author initials="A." surname="Frindell" fullname="Alan Frindell">
      <organization>Facebook Inc.</organization>
      <address>
        <email>afrind@fb.com</email>
      </address>
    </author>

    <date year="2019" month="July" day="08"/>

    <area>Internet</area>
    <workgroup>httpbis Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft proposes an HTTP/2 protocol extension that enables bidirectional
messaging communication between client and server.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>HTTP/2 <xref target="RFC7540"/> transports HTTP messages via a framing layer that includes
many technologies and optimizations designed to make communication more
efficient between clients and servers. These include multiplexing of multiple
streams on a single underlying transport connection, flow control, stream
dependencies and priorities, header compression, and exchange of configuration
information between endpoints.</t>

<t>Many of these capabilities are generic and can be useful in applications beyond
web browsing, such as Publish/Subscribe protocols or RPC. However, HTTP/2
framing’s request/response client to server communication pattern prevents wider
use in this type of application. This draft proposes an HTTP/2 protocol
extension that enables bidirectional communication between client and server.</t>

<t>Currently, the only mechanism in HTTP/2 for server to client communication is
server push. That is, servers can initiate unidirectional push promised streams
to clients, but clients cannot respond to them and either accept or discard
them silently. Additionally, intermediaries along the path may have different
server push policies and may not forward push promised streams to the downstream
client. This best effort mechanism is not sufficient to reliably deliver content
from servers to clients, limiting additional use-cases, such as sending messages
and notifications from servers to clients immediately when they become
available.</t>

<t>Several techniques have been developed to workaround these limitations: long
polling <xref target="RFC6202"/>, WebSocket <xref target="RFC8441"/>, and tunneling using the CONNECT
method. All of these approaches layer an application protocol on top of HTTP/2,
using HTTP/2 streams as transport connections. This layering defeats the
optimizations provided by HTTP/2. For example, multiplexing multiple parallel
interactions onto one HTTP/2 stream reintroduces head of line blocking. Also,
application metadata is encapsulated into DATA frames, rather than HEADERS
frames, making header compression impossible. Further, user data is framed
multiple times at different protocol layers, which offsets the wire efficiency
of HTTP/2 binary framing. Take WebSocket over HTTP/2 as an example, user data is
framed at the application protocol, WebSocket, and HTTP/2 layers. This not only
introduces overhead on the wire, but also complicates data processing.
Finally, intermediaries have no visibility to user interactions layered on a
single HTTP/2 stream, and lose the capability to collect telemetry metrics
(e.g., time to the first/last byte of request and response) for services.</t>

<t>These techniques also pose new operational challenges to intermediaries. Because
all traffic from a user’s session is encapsulated into one HTTP/2 stream, this
stream can last a very long time. Intermediaries may take a long time to drain
these streams. HTTP/2 GOAWAY only signals the remote endpoint to stop using the
connection for new streams; additional work is required to prevent new
application messages from being initiated on the long lived stream.</t>

<t>In this draft, a new HTTP/2 frame is introduced which has the routing properties
of a PUSH_PROMISE frame and the bi-directionality of a HEADERS frame. The
extension provides several benefits:</t>

<t><list style="numbers">
  <t>After a HTTP/2 connection is established, a server can initiate streams to
the client at any time, and the client can respond to the incoming streams
accordingly. That is, the communication over HTTP/2 is bidirectional and
symmetric.</t>
  <t>All of the HTTP/2 technologies and optimizations still apply. Intermediaries
also have all the necessary metadata to properly handle the communication
between the client and the server.</t>
  <t>Clients are able to group streams together for routing purposes, such that
each individual stream group can be used for a different service, within the
same HTTP/2 connection.</t>
</list></t>

</section>
<section anchor="conventions-and-terminology" title="Conventions and Terminology">

<t>The keywords <spanx style="strong">MUST</spanx>, <spanx style="strong">MUST NOT</spanx>, <spanx style="strong">REQUIRED</spanx>, <spanx style="strong">SHALL</spanx>, <spanx style="strong">SHALL NOT</spanx>,
<spanx style="strong">SHOULD</spanx>, <spanx style="strong">SHOULD NOT</spanx>, <spanx style="strong">RECOMMENDED</spanx>, <spanx style="strong">MAY</spanx>, and <spanx style="strong">OPTIONAL</spanx>, when
they appear in this document, are to be interpreted as described in
<xref target="RFC2119"/>.</t>

<t>All the terms defined in the Conventions and Terminology section in <xref target="RFC7540"/>
apply to this document.</t>

</section>
<section anchor="solution-overview" title="Solution Overview">

<section anchor="rstream-and-xstream" title="RStream and XStream">

<t>A routing stream (RStream) is a regular HTTP/2 stream. It is opened by a HEADERS
frame, and <spanx style="strong">MAY</spanx> be continued by CONTINUATION and DATA frames. RStreams are
initiated by clients to servers, and can be independently routed by
intermediaries on the network path. The main purpose for an RStream is to
facilitate XStreams’ intermediary traversal.</t>

<t>A new HTTP/2 stream called eXtended stream (XStream) is introduced for
exchanging user data bidirectionally. An XStream is opened by an XHEADERS frame,
and <spanx style="strong">MAY</spanx> be continued by CONTINUATION and DATA frames. XStreams can be
initiated by either clients or servers. Unlike a regular stream, an XStream
<spanx style="strong">MUST</spanx> be associated with an open RStream. In this way, XStreams can be routed
according to their RStreams by intermediaries and servers. XStream <spanx style="strong">MUST NOT</spanx>
be associated with any other XStream, or any closed RStream. Otherwise, it
cannot be routed properly.</t>

</section>
<section anchor="bidirectional-communication" title="Bidirectional Communication">

<t>With RStreams and XStreams, HTTP/2 framing can be used natively for
bidirectional communication. As shown in <xref target="fig-client-to-server"/> and
<xref target="fig-server-to-client"/> , as long as an RStream is open from client to server,
either endpoint can initiate an XStream to its peer.</t>

<figure title="Client initiates an XStream to server." anchor="fig-client-to-server"><artwork><![CDATA[
+--------+   RStream (5)   +---------+    RStream (1)   +--------+
| client |>--------------->|  proxy  |>---------------->| server |
+--------+                 +---------+                  +--------+
    v                        ^     v                        ^
    |    XStream(7, RS=5)    |     |    XStream(3, RS=1)    |
    +------------------------+     +------------------------+
]]></artwork></figure>

<figure title="Server initiates an XStream to client." anchor="fig-server-to-client"><artwork><![CDATA[
+--------+   RStream (5)   +---------+    RStream (1)   +--------+
| client |>--------------->|  proxy  |>---------------->| server |
+--------+                 +---------+                  +--------+
     ^                        v     ^                        v
     |    XStream(4, RS=5)    |     |    XStream(2, RS=1)    |
     +------------------------+     +------------------------+
]]></artwork></figure>

</section>
<section anchor="xstream-grouping" title="XStream Grouping">

<t>A client can multiplex RStreams, XStreams and regular HTTP/2 streams into a
single HTTP/2 connection. Additionally, all of the XStreams associated with the
same RStream form a logical stream group, and are routed to the same endpoint.
This enables clients to access different services without initiating new
connections,or including routing metadata in every message. As shown in
<xref target="fig-multiplex"/>, the client can exchange data with three different services
(PubSub, RPC, and CDN) using one HTTP/2 connection.</t>

<figure title="Client opens multiple RStreams, XStreams and an
HTTP/2 stream within one HTTP/2 connection." anchor="fig-multiplex"><artwork><![CDATA[
+--------+   RStream (5)   +---------+    RStream (1)   +----------+
| client |>--------------->|  proxy  |>---------------->|  PubSub  |
+--------+   XStream (7)   +---------+    XStream (3)   +----------+
  v   v                     ^ ^  v  v
  |   |                    |  |  |  |
  |   |     RStream (11)   |  |  |  |    RStream (5)    +----------+
  |   +--------------------+  |  |  +------------------>|    RPC   |
  |         XStream (13)      |  |       XStream (7)    +----------+
  |                           |  |
  |                           |  |
  |         Stream (21)       |  |      Stream (9)      +----------+
  +---------------------------+  +--------------------->|    CDN   |
                                                        +----------+
]]></artwork></figure>

<t>Reusing one connection for different purposes saves the latency of setting up
new connections. This is especially desirable for mobile devices which often
have higher latency network connectivity and tighter battery constraints.
Multiplexing these services also allows them to share a single transport
connection congestion control context. It also opens new optimization
opportunities, like prioritizing interactive streams over streams used to fetch
static content. It also reduces the number of connections that are adding load
to intermediaries and servers in the network.</t>

</section>
<section anchor="recommended-usage" title="Recommended Usage">

<t>RStreams and XStreams are designed for different purposes. RStreams are
<spanx style="strong">RECOMMENDED</spanx> for exchanging metadata only, and <spanx style="strong">SHOULD</spanx> be long lived, as
once an RStream is closed any routing information it carried is lost.
Unless a new RStream is re-established promptly, no new XStreams can be initiated. 
To keep an RStream open,  endpoints <spanx style="strong">SHOULD NOT</spanx> send
a HEADERS or DATA frame containing the END_STREAM flag. Implementations might
require special logic to prevent RStreams from timing out. For example, refresh
the timeouts on RStreams if a new XStream is exchanged.</t>

<t>By contrast, XStreams are <spanx style="strong">RECOMMENDED</spanx> for exchanging user data, and
<spanx style="strong">SHOULD</spanx> be short lived. In long polling, WebSocket and tunneling solutions,
streams have to be kept alive for a long time because servers need those streams
for sending data to the client in the future. With this extension, servers are able
to initiate new XStreams as long as RStreams are still open and no longer need
to keep idle streams around for future use. This allows all parties involved in
the connection to keep resource usage to a minimum. Morever, short lived
XStreams make graceful shutdown of a connection easier for intermediaries and
servers. After exchanging GOAWAY frames, short lived XStreams will naturally
drain within a short period of time.</t>

</section>
<section anchor="states-of-rstream-and-xstream" title="States of RStream and XStream">

<t>RStreams are regular HTTP/2 streams that follow the stream lifecycle described
in <xref target="RFC7540"/>, section 5.1. XStreams use the same lifecycle as regular HTTP/2
streams, but have extra dependency on their RStreams. If an RStream is reset,
endpoints <spanx style="strong">MUST</spanx> reset the XStreams associated with that RStream. If the
RStream is closed, endpoints <spanx style="strong">SHOULD</spanx> allow the existing XStreams to complete
normally. The RStream <spanx style="strong">SHOULD</spanx> remain open while communication is ongoing.
Endpoints <spanx style="strong">SHOULD</spanx> refresh any timeout on the RStream while its associated
XStreams are open.</t>

<t>A sender <spanx style="strong">MUST NOT</spanx> initiate new XStreams with an RStream that is in the
closed or half closed (remote) state.</t>

<t>Endpoints process new XStreams only when the associated RStream is in the open
or half closed (local) state. If an endpoint receives an XHEADERS frame
specifying an RStream in the closed or half closed (remote) state, it <spanx style="strong">MUST</spanx>
respond with a connection error of type ROUTING_STREAM_ERROR.</t>

</section>
<section anchor="negotiating-the-extension" title="Negotiating the Extension">

<t>The extension <spanx style="strong">SHOULD</spanx> be disabled by default. As noted in <xref target="RFC7540"/>,
section 5.5, HTTP/2 compliant implementations which do not support this
extension <spanx style="strong">MUST</spanx> ignore the unknown ENABLE_XHEADERS setting and XHEADERS
frame. Endpoints can negotiate the use of this extension through the SETTINGS
frame, and once enabled, this extension <spanx style="strong">MUST NOT</spanx> be disabled over the
lifetime of the connection.</t>

<t>This document introduces another SETTINGS parameter, ENABLE_XHEADERS, which
<spanx style="strong">MUST</spanx> have a value of 0 or 1.</t>

<t>Once a ENABLE_XHEADERS parameter has been sent with a value of 1, an endpoint
<spanx style="strong">MUST NOT</spanx> send the parameter with a value of 0.</t>

<t>If an implementation supports the extension, it is <spanx style="strong">RECOMMENDED</spanx> to include
the ENABLE_XHEADERS setting in the initial SETTINGS frame, such that the remote
endpoint can disover the support at the earliest possible time.</t>

<t>An endpoint can send XHEADERS frames immediately upon receiving a SETTINGS frame
with ENABLE_XHEADERS=1. An endpoint <spanx style="strong">MUST NOT</spanx> send out XHEADERS before
receiving a SETTINGS frame with the ENABLE_XHEADERS=1. If a remote endpoint does
not support this extension, the XHEADERS will be ignored, making the header
compression context inconsistent between sender and receiver.</t>

<t>If an endpoint supports this extension, but receives XHEADERS frames before
ENABLE_XHEADERS, it <spanx style="strong">SHOULD</spanx> to respond with a connection error
XHEADER_NOT_ENABLED_ERROR. This helps the remote endpoint to implement this
extension properly.</t>

<t>Intermediaries <spanx style="strong">SHOULD</spanx> send the ENABLE_XHEADERS setting to clients only if
intermediaries and their upstream servers support this extension. If an
intermediary receives an XStream but discovers the destination endpoint does not
support the extension, it <spanx style="strong">MUST</spanx> reset the stream with
XHEADER_NOT_ENABLED_ERROR.</t>

</section>
<section anchor="interaction-with-standard-http2-features" title="Interaction with Standard HTTP/2 Features">

<t>XStreams are extended HTTP/2 streams, thus all the standard HTTP/2 features for
streams still apply to XStreams. For example, like streams, XStreams are counted
against the concurrent stream limit, defined in <xref target="RFC7540"/>, Section 5.1.2. The
connection level and stream level flow control principles are still valid for
XStreams. However, for the stream priority and dependencies, XStreams have one
extra constraint: a XStream can have a dependency on its RStream, or any XStream
sharing with the same RStream. Prioritizing the XStreams across different
RStream groups does not make sense, because they belong to different services.</t>

</section>
</section>
<section anchor="http2-xheaders-frame" title="HTTP/2 XHEADERS Frame">

<t>The XHEADERS frame (type=0xfb) has all the fields and frame header flags defined
by HEADERS frame in HEADERS <xref target="RFC7540"/>, section 6.2. The XHEADERS frame has
one extra field, Routing Stream ID. It is used to open an XStream, and
additionally carries a header block fragment. XHEADERS frames can be sent on a
stream in the “idle”, “open”, or “half-closed (remote)” state.</t>

<t>Like HEADERS, the CONTINUATION frame (type=0x9) is used to continue a sequence
of header block fragments, if the headers do not fit into one XHEADERS frame.</t>

<section anchor="definition" title="Definition">

<figure title="XHEADERS Frame Payload" anchor="fig-ex-headers-frame"><artwork><![CDATA[
 +---------------+
 |Pad Length? (8)|
 +-+-------------+-----------------------------------------------+
 |E|                 Stream Dependency? (31)                     |
 +-+-------------+-----------------------------------------------+
 |  Weight? (8)  |
 +-+-------------+-----------------------------------------------+
 |R|                 Routing Stream ID (31)                      |
 +-+-------------+-----------------------------------------------+
 |                   Header Block Fragment (*)                 ...
 +---------------------------------------------------------------+
 |                           Padding (*)                       ...
 +---------------------------------------------------------------+
]]></artwork></figure>

<t>The RStream specified in a XHEADERS frame <spanx style="strong">MUST</spanx> be an open stream. The
recipient <spanx style="strong">MUST</spanx> respond with a connection error of type ROUTING_STREAM_ERROR
PROTOCOL_ERROR, if the specified RStream is missing, is an XStream rather than a
regualr HTTP/2 stream, or is closed or half-closed (remote). Otherwise, the
states maintained for header compression or flow control may be out of sync.</t>

</section>
<section anchor="examples" title="Examples">

<t>This section shows HTTP/1.1 request and response messages that are transmitted
on an RStream with regualar HEADERS frames, and on an XStream with HTTP/2
XHAEDERS frames.</t>

<figure title="The request message and HEADERS frame on an
RStream" anchor="c2s-rstream-req"><artwork><![CDATA[
  GET /login HTTP/1.1               HEADERS
  Host: example.org          ==>     - END_STREAM
                                     + END_HEADERS
                                       :method = GET
                                       :scheme = https
                                       :path = /login
                                       host = example.org

  {binary data .... }        ==>    DATA
                                     - END_STREAM
                                       {binary data ... }
]]></artwork></figure>

<figure title="The response message and HEADERS frame on an
RStream" anchor="c2s-rstream-resp"><artwork><![CDATA[
  HTTP/1.1 200 OK                   HEADERS
                            ==>      - END_STREAM
                                     + END_HEADERS
                                       :status = 200

  {binary data .... }       ==>     DATA
                                     - END_STREAM
                                       {binary data...}
]]></artwork></figure>

<t>The server initiates an XStream to this client.</t>

<figure title="The request message and XHEADERS frame on an
XStream" anchor="s2c-xstream-req"><artwork><![CDATA[
  POST /new_msg HTTP/1.1            XHEADERS
                                       RStream_ID = 3
  Host: example.org          ==>     - END_STREAM
                                     + END_HEADERS
                                       :method = POST
                                       :scheme = https
                                       :path = /new_msg
                                       host = example.org
  {binary data}              ==>    DATA
                                     + END_STREAM
                                       {binary data}
]]></artwork></figure>

<figure title="The response message and XHEADERS frame on an
XStream" anchor="s2c-xstream-resp"><artwork><![CDATA[
  HTTP/1.1 200 OK                   XHEADERS
                                       RStream_ID = 3
                             ==>     + END_STREAM
                                     + END_HEADERS
                                       :status = 200
]]></artwork></figure>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This specification adds an entry to the “HTTP/2 Frame Type” registry, the
“HTTP/2 Settings” registry, and the “HTTP/2 Error Code” registry, all defined in
<xref target="RFC7540"/>.</t>

<section anchor="frame-type-registry" title="FRAME TYPE Registry">

<t>The entry in the following table are registered by this document.</t>

<figure><artwork><![CDATA[
   +---------------+------+--------------+
   | Frame Type    | Code | Section      |
   +---------------+------+--------------+
   | XHEADERS      | 0xfb |              |
   +---------------+------+--------------+
]]></artwork></figure>

</section>
<section anchor="settings-registry" title="Settings Registry">

<t>The entry in the following table are registered by this document.</t>

<figure><artwork><![CDATA[
+------------------------+--------+---------------+---------------+
| Name                   | Code   | Initial Value | Specification |
+------------------------+--------+---------------+---------------+
| ENABLE_XHEADERS        | 0xfbfb | 0             |               |
+------------------------+--------+---------------+---------------+
]]></artwork></figure>

</section>
<section anchor="error-code-registry" title="Error Code Registry">

<t>The entry in the following table are registered by this document.</t>

<figure><artwork><![CDATA[
+----------------------+------+-------------------+---------------+
| Name                 | Code | Description       | Specification |
+----------------------+------+-------------------+---------------+
| ROUTING_STREAM_ERROR | 0xfb | Routing stream is |               |
|                      |      | not open          |               |
| XHEADERS_NOT_        | 0xfc | XHEADERS is not   |               |
| ENABLED_ERROR        |      | enabled yet       |               |
+----------------------+------+-------------------+---------------+
]]></artwork></figure>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC7540;
&RFC6202;
&RFC8441;
&RFC2119;


    </references>




  </back>

<!-- ##markdown-source:
H4sIAGnEI10AA91c63MbN5L/jr8Cp3yIHyQjyclmoyvnTpZoW7XWYyX57NyH
dYEzIInycIY7mJHMjZS/fbsbDQwwpGwpcaWujpWKSc4M0OjHr5/UcDgUjWkK
vSf3S/n68vLsu105/tTo0pqqlNOqli9MbmqdNfBZFfJYW6tmWh5Ui0Vbmkzh
9yKvslItYJG8VtNm+Mno4SR+bLigx0w5G27vCjWZ1Ppqj7Ybnr19cfH2hTDL
ek82dWub3e3tn/CmWqs9eVQ2ui51I66r+uOsrtrlnpw3zXJirHwHX8GK8hV+
LWw7WRiLVDerJVByNL58KYA8Pavq1Z60TS4+6hUsk3erDg+RXPFNDrftyd3t
nZ+G28+G2zuX29t79N//CmF1bbQ9KqfVnpBDIeHljtpbBC9cqaK9LxPwftvA
IRdMq/tCNa1FalWZqzoXQrXNvKrD1qaEq1uvRvK90VsRMVuv2uq67b6t6pkq
zb9IOnD1pcr0pKo+AtHZyN2hF8oUe/K6qv57Ohll1SLdYn8kX9amzHVRJPvs
F6rsXbn3XmqKz/ntxHA4lGoCPFBZI8TlHERKnJPLulpWVlupgkrCV02VVYXU
QTebuWqkLtWkgDsTRovAaJnFaionurnWupRZYXTZwPK5BPFe6XrkqFmYPC+0
EN+gcOsqb2lBIZiIX3/9j/OXBz/+8P327S3oqirtsqobSzRKtyeQcmWUVHJa
qwUSUKiVrh2tpsyKNtdWLFS5ko3O5mVVVDNDB81ltWzMgtkInNDWzEqdy6aS
C/VR906yqGot9HRqMjpJejAbncyO5OVcW+13l4u2aMyy0J+QumoaPgunjFbC
6kpauFpo2YKY62KFt4bzAiVl6Vg9kNOiusYvgFvFgPVZ5Hqp4cEy80db1qaq
TQMfB3KuFayJx1nWmux1QPfoT9lclYAsQBMsODWztnbgYsD26kUqQVh/WRk4
KkjuGNkJTzV0zkwt1cQUtJsEEJEzXYIJZ7RJpnAJ2Vo9bQtgiVTLZcE8BSXS
q6rMxbWeyEldXSMP4ExtNpfKyrN2Uhg7/+6indisNrCK10lgWS3Pzw5G8nV1
rYHnA9ZawUrwrZW1/merbfMdHHkJW2mvgiBdJ6eefJeqQXSBPWBBlOi1Aa6J
lgQJJwVbQZjDY0dHQFnfx4rEfazoAbZz0NY1fFmsBigE0KBiBfaA8jR2gQTz
/uhO+LhwcF4p3cZYwXcsWzvHA6HlgN6wOpMITQniBcwG/UwoxkfwkOAIwHJY
oUXYClaZtE0wEliprBrpREKGBsQvnDIaeFtLlWV62aB4c2MzxGO6w5qCTjuS
+3lu3N54doMeYaFzo2pSvqJCuwGGgDTnYMUrOVdXGtaaTjXyKz6pXFaFCQaD
9yJtwLBr2HbzwZhimVfXJVueOxqrwQQUTgJGoM1G0rC0sm0DeMAytS4MqMAK
YKcwThvhLEDhFPYMrI8ZWQBWNYgLKrAAzWqYKYtW7q3GgqHiXR4dBZ4O9jfT
YHV3bCHNgljZaCDreq5RVfUKDgX6ooW6Ao+CSgvad4E2B9sTohq0M8fnCapr
DheLaumAFIMIBdECSpvAgk7h6NiTKC4BYiiQYIf1f9nd3r29Hch3enJRZR91
w9//9fvvd/B7PE3TAhzSM601LPCD05OT8cElOCLw3jnoSVF0CAUGW1cqg/fs
HVSCQ52vQ/Oslvigs5+BcDuwNXk1ADZvAmfLakB74GO5nmoFjAUqROpsYMcr
wJdcTla8OHh/0Hr9SS3ANQxSp+E/gFoD2wtdCFJ85XYFqoHTValTMkHFDPtU
lA84ATwXsA3kVABrYWFkk60GIuYFMFBBdKZQbcGhqKVtC1CJHG2tkof7l/vk
aVHlwFvMnasFvBnvH47PL4S/Bh4UKV/3PaBlAJLWoCbJl22NSwxQkcHkeVta
Ixfh1MA4tNKms+NOYsRr2O96bkD/q+nUasdwwG9wRd5hZysRhAqgW6p65QMG
EBp6+07hKjRHvlURmAepxGS6o+ZIF263SZ8iNXaay6s6ollbEBsQv0UkLSTB
SawMZ3FQqkBgxE7aDG4lamDDDNkLpxEvzWZwJAstK4iWgPnorldooHSiRJuI
OE1bK8FRSaJY7igFeDqiLbh/Wg9OXYA1ADQUGlSpRrfUQDBgxSM9mo0GJEyP
o1NTg4cuFKDmZNWQb2W3TVt41/04uDEDpxxh5IpWHaEPcQV9ryz1NcR12gUy
6FLnaDAlhomwacqSkXyhMwUcEHAPWjQqi0NHRYz5FuGUtXaTNazZ3IACBQ7s
yHHS4ZQEea6k805w/pFLZTrZoPdpUAtVdxPSC3GFKYUDMQafkd/x1en+u/1f
nOvHyBV4QEyt9aICXvp4jQIeBLWAlaJDLGIssowX/8/YuSB247lRJKZ2eM7R
ET7TQw2OxYl7E41b+ZghaDEdDb2dd6ggyiOOrSiCAs0ianzwggaGFATLyNnO
54rPWrXkEjHy0jUGoGjmSp69vXj94ez89PjoYszLKOeCwPiHUQCDWktPMH65
mymCj0I2RmvUBuf4JhDhTk1j94TYARCdNuhTPNkRe1FrILOkOFbneDwfe8Yx
VRddCDIojvfQCFakCoNAvY/g4PE0isJso6L8xwdhEEpB6o32u4qCOlokif9i
uDP9iBT2FXa1cDYM4tqNPat/6guJlW0MPILasuorviDDJWQiE5yjASOSKQcc
zhOR3qGAC4znyrzQ68cQPlqOOchMC1Hzs5E88PkaOAeMZnBxqnJEUphp8mto
G0HB2ppCe46zMIYXGiIKYHtuQDda4BVbvVuty3tyWkhFzouRDJwWBL2UXEAu
iDq6pkAjzIwPqhJtjniJR7oEBhri94qgUHKVxconT47fXlw+eTLgd/LklD+d
j//+9uh8fOg+Xbzef/Mmesv3Cfx4+vZNuAvfx2scnB4fj08O/TLH+7/gG6Tp
yZPTs8uj05N9WhaDR0HBI0hdqzpkUHmVtQs4y4D4D6yfaIfJgCsIFIrScEr2
EGKFi/12d3Z+ur0FXuyzjqAK4Z1TU9J9LgK8m03AcbbHMikpEIStnAVF1BHX
L6qipWdOr1BcgHfim2/k+YUTMm7w3r0HsoKasAo84tseo0EpsNQZeI06dRVg
CmiR6KxKFweqNIjyjCUuI6MwQzBl626GePfy6OTtPjKdbowis5Enk9RcdDgM
z/lYP6TBdhDn6VhlcqUEyLboWPSY6MUSDOgl2Bw6Ccy2CDPBkQGL2Vic3peB
Z4YQbqoyDBYQ95iB9tvYL6/QESNdqkCJx/4guFXw6JAxvm+Q0Dww/X3E9Mhj
ABWCSx0uZfAhXIJ0lFuWnqSeYOD7xD8MxO8XjT80czyVDmfBXkgheYfn3paF
oQDBa1MXjAVN9PaPJClrq8wtjDCDt+GJvDQQiZ3WXyuIFXtUseQ7H8JextSd
agG5/fQ7roF5TsZIJDbSBR6YTs1PDCSpDapqhegZCD7Fu64hH4fQthFcSwi0
BhcxIkNNa+hp7Vy8w407G+ls2Q7i2IPKmRGOl/D4FSbHqFKfqdyAJoHXm1fX
DDhTMxs6kQ6baug4dHtLvtVddF/hRXcbXBwgFlLA5FKQ81QxXZzVL2kNBCtQ
CP6SOKPTFIqFQcGWmvzib7/9Jp4O+fVUyrDbox8ew6dwia51F3eSi0/FjSfo
5udh+vr5RqJ8Pq3k+jW8yFHRTUpF+upRccfFp64tsH6He/1Dfv4yPX2D/2NO
PfpxAAd+TnxwF9LLz+jyjrssUjp7r6fy85dJDL/uyW826YukntHzLRe/BJna
nlA51Nm6/X8oVBbehtfVFy6Ldbl9/3mx7q6J9SvJtW/qXq4Xjll3yZXLjChX
ADd/gfpwgFLoJ6PMINSOAsZFAO8S6w0BiXU5bT/nj4LRXvFVdYlAt3oP3UNo
6/ULGwuU5c4ALNOY2QUiGBgyonNmQ897RBu5tpWvn0fhDJaOrV0Psy1RAit6
5iKsY/4aFe4GVc3tGrzoo7muFFZKTRk8p7kJwDOGB6ZjlbKXqoVOC63GjKm1
3kCseHTWTi7ayQD7G44jB4cnjzl7jwoOSZLwVWz9j1m7dHTLvr17XX304wZK
wsVna5Q4q96M1P9AW79yhn0TDLj3ugn/JXd1h6fT30T/9dnWJ+jmLjN/6lfY
cPVnt/DZgewoca9w+B06vezIWGPbJkruet3097nHLX6z3Z3HCffiaz/xpR4p
d+Ke48vmy44poNgywOvveCWUxCDbAWDqNTFysl01/Q50VKVIEw5O0zcbH0Ly
ue7Ms1dci0rWXEIAPLvSrnyFpcQyowqU1Q1hTrsUmPGsNxWolLTUAK4FdY2s
qal+gZssqomBt7lmvONaOCwuqLYyNzOMCv12Pm3zm1xhFYyKJXAflrIm1Atd
4Q04LOC6vsdxR4JLkh5hqYwDhFXX1rX0MBSZU43FN7ZDwyQuP8Lbmbb+Lba0
XR/sU0PpMS3rhObqul1ZSVRLXKwtuclNyZHvev/LlR+5qH3VVdio1uU/UEwP
hE51k80FDoKYzLfhuu1r7UrylO+2iwks4PrlXj6uoUtnzcl9FJXKxVqxOc6O
fMmCBeEylnPssy1cSvuWJn5AsTblKLRXmFbYrGS9EkCveEMPRTlxcHRYTPZ1
B18KwvSnq9xiXiKqMtO9pISTNczbvPuMpwgMOsIa+JDjzXAvOHLIaNFhu5Jv
tFSth1HRlJqwS+p0lxXd2s9VQwY9kuKykh+1XsbEof4MZDe/0KtsUcNUdAVg
4EyXr5M6gP77LiPw78PF5fl4/1hOCzUDLcG+ENaMuNa5QAsSXDGXbK8u2onL
50E4lMahViN6tE2vCVjraa3tnKrCWAeGO6j2Eh43U2ZfVLfwwUYOavVi5exK
2WaQ6s8XNCJUSUgbRKoNEPnUjVMHKiOQdnAbN+7cpr1aywU1OwiDLwROrgr4
Edv+CtfkcmnXB5m4Jk0wnlKj3c6rriciXH/INb59yTiKwdjcpm3T1hC8vXMB
GPGKS/zdtIMvDDsL5sw5UbsoMY+NjOvclJ27njvdpmsiGJcjzTRYvg6NZNca
R/Idcch4BnyGU4yyl4p6G0DPVVVcudKoq4AHJPXLg75UbZ3hQgghGBeDUpZm
0S5G8riq3bRMJEERzkVDTzOATBrVsfO2wTkH1x6JdtLKGq6OryOcCPUf1xSJ
VIr7Vb5BHJHQsfYaOVgq4AR6OUHtL+9+FT+y1IDy1MumVhph50VDORN8t7FA
m4jpjuSHUHxaIdNd1uHWKcxUZ6uMvCsXpkWvijwI5eUfRjtRga/lBinlL906
yvZI8ObgGrxkE6CXtZJhqmvFBdeo/AaGN+1BMIheNwMRAx2XA+nKlxI11XSl
tiNK68Qavg82wCisrwLXIDqwBP5ho4bb1brRokR/ULh+VJcSRgvVmgrIZEMQ
xRT9XhVWv8pZRX3u8SZKGDFD5wzTPi5W++3culj96nggEmzE7an2jJACShyX
MO/ABF9i9Zu48UPv6AV7RzCZuSqm3lk+cq3axzSEiprcHYkb+ukm1Or1gzmx
BCM5MdThEUR/u6KClNvvxvoTKoW1zrS54sJDUu0W5MamNJMYa5zvtX35aFiw
DdoofOPS8SyBlrquKLyiSbvz07eXRyev2OF+GJ+fn547cz/Rs8pn8uSWPYy7
fljXuE39Vm4sIjtV2nM9VRDQUiZfVq6jn1q16Kz6h0EX+OPkhUKf0vP8LujO
K571oujUTQPE5LBBQuhW1Q4d2vJjiTA7Ptl/8Wb8IbDeJwQEZEljaCQ7PcEQ
qGRu8HpWu6pM7N6w3FC1M6rHyIvxJfI1aTNRROeKKvmg/3Ci/zEfKZxG/UZ0
I1/N9aC4aOQHjbm5JqMxF1W6yr+niOabIBhFF9XjB0/4dC0O1zR2A+C47Taq
4A7oxykFp2v8DEvT8ABNqlkkh7UwrLMziM1CJGdHPODxQr9Y//FtnGkgy0oV
xKuEZZgMcYchnOiHYxR80PiwcHHnZuVgG3SYVHR8ZMmGXnU0GCKS3gCI0gsx
KC3frlUN0ZNtpB/X8v52v0z7C8SVFDLSWcIWzJ3xhTS6R6cgHvaO+HyH+nFh
o3U5ILSHXSd6ivPZd28SypGbNkKBrc3N5JW2om/MseTIn3oCKHLBZIQsOw8D
cHiTG4IT8RAcZ7k0tQHL2SaeKWe34yq1hMp10KpAXqRPKVkYRAQw74uF+bRm
XITPAStpPvWzIC340Q8gkA9utUNGaBe9znWxvHMeKZhGHyCjHl5vQiqiLljh
XVYRjbSSyzTTfv+aJ0MgnmqXHOj5+H+ztNldiqRRnbhM9orIfRxdrtxw7Zzi
RqDKgUCiXOgpRLddHxU2RG9RPeozAiAXedSN9DkZXvAPXLwne6kxzAYVT2Mf
ogFLEGl4jNre2jCkY3uLTXkx6oz6iDqa+0GRvA+Ra5LjUuEm7JLQkkFyRF3o
GQSFtvGeJXOz712EvjCQ3UbTIGlwfhEF57tusivS5gKnlV1thpejL+JfWWBZ
qcyw9BXneYD4xg0XdAcLv0bA5CgSGNelXJEt/q1GdGDyZ1VJY2e1ikpve2B+
XrsQbtnxpckBhrPnvf65T3+wEIdmERAwbsiM5FlcNEtzhKyu4o5KyAeoXWOD
ErvMEcwSW/M+W+fZcZfGVxs6HTRlw/oTTPglOQSK4lLoko8wJny+/Wk6eUwe
3Kvi1OgidxbtbuSRY6zPhBkhgWPWyXImjCzfkcv9hZWlT8ec6l8+RaPdB/Kc
S17Mn6NDP93ja4xcFehmHDBXVlE7jctjWA7jA9CQNm46o5mkNSjn6hcFMW5W
N4nLt7DQsDWQW7j1FinFFkbow16EvhWyjzdoicEj8FB9N8mSiuGnx/Hx/PwL
DTj+swWt1DiIufEkoPRmGvlF64PmqWm6sdr0tA7TDlGYxo1wYLl/rbnwVMib
M5XLN7qcNfP/ko/++vgG70rv+1zHYmMXA1Ydr7dTWNaHwQ5hv2ehf9JruHwd
KqR8p7HASCf7aquer59tTZ/vPtrXO9va67VTnxekPi9ZfeSjJ+uEjEajdW14
6OsOKvzrjMv7m/b/qlTEnSz9achWMnT2xw2tFDCBthV2HbAXFVdWXOJunFdU
fSRLpsW46OJnE9FLQnhjllQ/jUOR3526i7Pz08vTg9M37mNAgY7IqIxBPyzG
arJJoqv4FydKYBlNFXV/BB8Lk7ZXl+ijXjJNRkMKroKI5Scs+HNjZcPPV7BU
GwcHOLoPDKRC01TaVZk5sBq7AMdy+uvdCk4NuN+vfrcz2tn4c4dumD50lqh5
BmEORkNVGVdhSBKOEVhQTFyET+1jDtL9XHd8/3p/HN3OcwRSvhpfyu+wZ1F2
hPYsk+sR8K6yEKFwNDeq6ll30/PnP9O/w6htcr9e71N6otvkXq8999Mv+Rzp
v/dDNptDJgIP4W/c7b0fo98XPmcu3fepOfAKHoqYJeDRX/nnSNS3AAgZyVv/
AHMQ+1H32+PhrF7fX94GBMp27bB2ZjUETfXgc0lZnVNc1lX366YEXkjvfMjo
B9Jkp1G729vy9G8bCLqP3L1u/WnK5f5OAEgPyP681Dxpf57UYPe7ZGaXqdBS
hLmP1C7DDyjuHE6jVJkn1LyYz04vAERKff1hYWcbYeT9A0XANH2AYOS5fPZ/
FHrw2H8W9jBz/wD6pGp0m97/YPB5+gfVuNNhu5sNP90fd95vUuH3DweeP6yR
n3l5jXw4k74CXm3m6z2w4UucpT/csX+yjz++sfj3ElwzxMc8LrLj3h2Ez+7H
tCX+KpQb9Fu+GkXrX0LsuIXRjAEi3Z82EP6OC1fcs/F1/wMvf8+YgtCDKk9W
wUpBVx0ScbrvQrWX5/vHY3n5y9lYnvNT3EgiUv30APWGqUhCg1fcS8babe16
Sv0fETm9W89Sk3+i7ANH7jpGSPqMh4F/fBGLXjcPXjXI0T0vsYzST3YetCoe
jRrvLJWvz7i756nX3tz1WdzIE+Tm+ov5im+OuHfyP9TBAU4nSnvzlejol6oD
HSgJksV2j8C+cL4GHV5qnZ38aXLbrEh38muj3II1HNIoxrKziPvL7YF0bEpk
O/s5T3/2B8xYl9sdJYUb/w/9/B9T78/IvjNgKvcn2pPF5s1/TmDzGkmXYI0O
bv7KlW4eqoMP4inpILyTE5V9FP8GDVj4Qg5NAAA=

-->

</rfc>

