asciidoctor-rfc 0.2.0 → 0.8.0

data/spec/examples/draft-ietf-core-block-xx.xml.orig

@@ -0,0 +1,1251 @@
+<?xml version="1.0" encoding="us-ascii"?>
+  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
+  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.7 -->
+
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY RFC2616 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2616.xml">
+<!ENTITY I-D.ietf-core-coap SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
+<!ENTITY SELF "[RFCXXXX]">
+]>
+
+<?rfc toc="yes"?>
+<?rfc sortrefs="yes"?>
+<?rfc symrefs="yes"?>
+
+<rfc ipr="trust200902" docName="draft-ietf-core-block-05" category="std">
+
+  <front>
+    <title>Blockwise transfers in CoAP</title>
+
+    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
+      <organization>Universitaet Bremen TZI</organization>
+      <address>
+        <postal>
+          <street>Postfach 330440</street>
+          <city>Bremen</city>
+          <code>D-28359</code>
+          <country>Germany</country>
+        </postal>
+        <phone>+49-421-218-63921</phone>
+        <facsimile>+49-421-218-7000</facsimile>
+        <email>cabo@tzi.org</email>
+      </address>
+    </author>
+    <author initials="Z." surname="Shelby" fullname="Zach Shelby" role="editor">
+      <organization>Sensinode</organization>
+      <address>
+        <postal>
+          <street>Kidekuja 2</street>
+          <city>Vuokatti</city>
+          <code>88600</code>
+          <country>Finland</country>
+        </postal>
+        <phone>+358407796297</phone>
+        <email>zach@sensinode.com</email>
+      </address>
+    </author>
+
+    <date year="2012" month="January" day="13"/>
+
+    <area>Applications</area>
+    <workgroup>CoRE Working Group</workgroup>
+    <keyword>Internet-Draft</keyword>
+
+    <abstract>
+
+
+<t>CoAP is a RESTful transfer protocol for constrained nodes and networks.
+Basic CoAP messages work well for the small payloads we expect
+from temperature sensors, light switches, and similar
+building-automation devices.
+Occasionally, however, applications will need to transfer
+larger payloads &#8212; for instance, for firmware updates. With
+HTTP, TCP does the grunt work of slicing large payloads up
+into multiple packets and ensuring that they all arrive and
+are handled in the right order.</t>
+
+<t>CoAP is based on datagram transports such as UDP or DTLS,
+which limits the maximum size of resource representations that
+can be transferred without too much fragmentation.
+Although UDP supports larger payloads through IP
+fragmentation, it is limited to 64 KiB and, more importantly,
+doesn't really work well for constrained applications and
+networks.</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.</t>
+
+<t>In summary, the Block options provide a minimal way to
+transfer larger representations in a block-wise fashion.</t>
+
+
+
+    </abstract>
+
+
+  </front>
+
+  <middle>
+
+
+<section anchor="problems" title="Introduction">
+
+<t>The CoRE WG is tasked with standardizing an
+Application Protocol for Constrained Networks/Nodes, CoAP.
+This protocol is intended to provide RESTful <xref target="REST"/> services not
+unlike HTTP <xref target="RFC2616"/>,
+while reducing the complexity of implementation as well as the size of
+packets exchanged in order to make these services useful in a highly
+constrained network of themselves highly constrained nodes.</t>
+
+<t>This objective requires restraint in a number of sometimes conflicting ways:</t>
+
+<t><list style="symbols">
+  <t>reducing implementation complexity in order to minimize code size,</t>
+  <t>reducing message sizes in order to minimize the number of fragments
+needed for each message (in turn to maximize the probability of
+delivery of the message), the amount of transmission power needed
+and the loading of the limited-bandwidth channel,</t>
+  <t>reducing requirements on the environment such as stable storage,
+good sources of randomness or user interaction capabilities.</t>
+</list></t>
+
+<t>CoAP is based on datagram transports such as UDP, which limit the
+maximum size of resource representations that can be transferred
+without creating unreasonable levels of IP fragmentation.  In
+addition, not all resource representations will fit into a single link
+layer packet of a constrained network, which may cause adaptation
+layer fragmentation even if IP layer fragmentation is not required.
+Using fragmentation (either at the adaptation layer or at the IP
+layer) to enable the transport of larger representations is possible
+up to the maximum size of the underlying datagram protocol (such as
+UDP), but the fragmentation/reassembly process loads the lower layers
+with conversation state that is better managed in the application
+layer.</t>
+
+<t>This specification defines a pair of CoAP options to enable <spanx style="emph">block-wise</spanx> access to
+resource representations.
+The Block options provide a minimal way to transfer larger
+resource representations in a block-wise fashion.
+The overriding objective is to avoid
+creating conversation state at the server for block-wise GET requests.
+(It is impossible to fully avoid creating conversation state for
+POST/PUT, if the creation/replacement of resources is to be atomic;
+where that property is not needed, there is no need to create server
+conversation state in this case, either.)</t>
+
+<t>In summary, this specification adds a pair of Block options to CoAP that
+can be used for block-wise transfers.  Benefits of using these options
+include:</t>
+
+<t><list style="symbols">
+  <t>Transfers larger than can be accommodated in constrained-network
+link-layer packets can be performed in smaller blocks.</t>
+  <t>No hard-to-manage conversation state is created at the adaptation
+layer or IP layer for fragmentation.</t>
+  <t>The transfer of each block is acknowledged, enabling retransmission
+if required.</t>
+  <t>Both sides have a say in the block size that actually will be used.</t>
+  <t>The resulting exchanges are easy to understand using packet
+analyzer tools and thus quite accessible to debugging.</t>
+  <t>If needed, the Block options can also be used as is to provide random
+access to power-of-two sized blocks within a resource representation.</t>
+</list></t>
+
+<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119, BCP 14
+<xref target="RFC2119"/> and indicate requirement levels for compliant CoAP
+implementations.</t>
+
+<t>In this document, the term "byte" is used in its now customary sense
+as a synonym for "octet".</t>
+
+<t>Where bit arithmetic is explained, this document uses the notation
+familiar from the programming language C, except that the operator "**"
+stands for exponentiation.</t>
+
+</section>
+<section anchor="block-wise-transfers" title="Block-wise transfers">
+
+<t>As discussed in the introduction, there are good reasons to limit the
+size datagrams in constrained networks:</t>
+
+<t><list style="symbols">
+  <t>by the maximum datagram size (~ 64 KiB for UDP)</t>
+  <t>by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)</t>
+  <t>by the desire to avoid adaptation layer fragmentation (60&#8211;80 bytes
+for 6LoWPAN)</t>
+</list></t>
+
+<t>When a resource representation is larger than can be comfortably
+transferred in the payload of a single CoAP datagram, a Block option
+can be used to indicate a block-wise transfer.  As payloads can be
+sent both with requests and with responses, this specification
+provides two separate options for each direction of payload transfer.</t>
+
+<t>In the following, the term "payload" will be used for the actual
+content of a single CoAP message, i.e. a single block being
+transferred, while the term "body" will be used for the entire
+resource representation that is being transferred in a block-wise
+fashion.</t>
+
+<t>In most cases, all blocks being transferred for a body will be of the
+same size.  The block size is not fixed by the protocol.  To keep the
+implementation as simple as possible, the Block options support only a
+small range of power-of-two block sizes, from 2**4 (16) to 2**10
+(1024) bytes.  As bodies often will not evenly divide into the
+power-of-two block size chosen, the size need not be reached in the
+final block; still this size will be given as the block size even for
+the final block.</t>
+
+<section anchor="block-option" title="The Block Options">
+
+<texttable title="Block Option Numbers" anchor="block-option-numbers">
+      <ttcol align='right'>Type</ttcol>
+      <ttcol align='left'>C/E</ttcol>
+      <ttcol align='left'>Name</ttcol>
+      <ttcol align='left'>Format</ttcol>
+      <ttcol align='left'>Length</ttcol>
+      <ttcol align='left'>Default</ttcol>
+      <c>19</c>
+      <c>Critical</c>
+      <c>Block1</c>
+      <c>uint</c>
+      <c>1-3 B</c>
+      <c>0 (see below)</c>
+      <c>17</c>
+      <c>Critical</c>
+      <c>Block2</c>
+      <c>uint</c>
+      <c>1-3 B</c>
+      <c>0 (see below)</c>
+</texttable>
+
+<t>Both Block1 and Block2 options can be present both in request and
+response messages.  In either case, the Block1 Option pertains to the
+request payload, and the Block2 Option pertains to the response payload.</t>
+
+<t>Hence, for the methods defined in <xref target="I-D.ietf-core-coap"/>, Block1 is
+useful with the payload-bearing POST and PUT requests and their
+responses.  Block2 is useful with GET, POST, and PUT requests and
+their payload-bearing responses (2.01, 2.02, 2.04, 2.05 &#8212; see
+section "Payload" of <xref target="I-D.ietf-core-coap"/>).</t>
+
+<t>(As a memory aid: Block_1_ pertains to the payload of the <spanx style="emph">1st</spanx> part
+of the request-response exchange, i.e. the request, and Block_2_
+pertains to the payload of the <spanx style="emph">2nd</spanx> part of the request-response
+exchange, i.e. the response.)</t>
+
+<t>Where Block1 is present in a request or Block2 in a response (i.e., in
+that message to the payload of which it pertains) it indicates a
+block-wise transfer and describes how this block-wise payload forms
+part of the entire body being transferred ("descriptive usage").
+Where it is present in the opposite direction, it provides additional
+control on how that payload will be formed or was processed ("control usage").</t>
+
+<t>Implementation of either Block option is intended to be optional.
+However, when it is present in a CoAP message, it MUST be processed
+(or the message rejected);
+therefore it is identified as a critical option.</t>
+
+<t>Three items of information may need to be transferred in a Block
+option:</t>
+
+<t><list style="symbols">
+  <t>The size of the block (SZX);</t>
+  <t>whether more blocks are following (M);</t>
+  <t>the relative number of the block (NUM) within a sequence of blocks
+with the given size.</t>
+</list></t>
+
+<t>The value of the option is a 1-, 2- or 3-byte integer which encodes
+these three fields, see <xref target="block"/>.</t>
+
+<figure title="Block option value" anchor="block"><artwork><![CDATA[
+        0
+        0 1 2 3 4 5 6 7
+       +-+-+-+-+-+-+-+-+
+       |  NUM  |M| SZX |
+       +-+-+-+-+-+-+-+-+
+
+        0                   1
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |          NUM          |M| SZX |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        0                   1                   2
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                   NUM                 |M| SZX |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork></figure>
+
+<t>The block size is encoded as a three-bit unsigned integer (0 for 2**4 to 6
+for 2**10 bytes), which we call the <spanx style="verb">SZX</spanx> (size exponent); the
+actual block size is then <spanx style="verb">2**(SZX + 4)</spanx>.  SZX is transferred in the
+three least significant bits of the option value (i.e., <spanx style="verb">val &amp; 7</spanx>
+where <spanx style="verb">val</spanx> is the value of the option).</t>
+
+<t>The fourth least significant bit, the M or "more" bit (<spanx style="verb">val &amp; 8</spanx>),
+indicates whether more blocks are following or the current block-wise
+transfer is the last block being transferred.</t>
+
+<t>The option value divided by sixteen (the NUM field) is the sequence
+number of the block currently being transferred, starting from
+zero. The current transfer is therefore about the <spanx style="verb">size</spanx> bytes
+starting at byte <spanx style="verb">NUM &lt;&lt; (SZX + 4)</spanx>.  (Note that, as an implementation
+convenience, <spanx style="verb">(val &amp; ~0xF) &lt;&lt; (val &amp; 7)</spanx>, i.e. the option value with
+the last 4 bits masked out, shifted to the left by the value of SZX,
+gives the byte position of the block.)</t>
+
+<t>The default value of both the Block1 and the Block2 Option is zero,
+indicating that the current block is the first and only block of the
+transfer (block number 0, M bit not set); however, there is no
+explicit size implied by this default value.</t>
+
+<t>More specifically, within the option value of a Block1 or Block2
+Option, the meaning of the option fields is defined as follows:</t>
+
+<t><list style="hanging">
+  <t hangText='NUM:'>
+  Block Number. The block number is a variable-size (4, 12, or 20 bit)
+unsigned integer (uint, see Appendix A of <xref target="I-D.ietf-core-coap"/>)
+indicating the block number being requested or provided. Block
+number 0 indicates the first block of a body.</t>
+  <t hangText='M:'>
+  More Flag (not last block). For descriptive usage, this flag, if
+unset, indicates that the payload in this message is the last block
+in the body; when set it indicates that there are one or more
+additional blocks available.  When a Block2 Option is used in a
+request to retrieve a specific block number ("control usage"), the M
+bit MUST be sent as zero and ignored on reception.  (In a Block1
+Option in a response, the M flag is used to indicate atomicity, see
+below.)</t>
+  <t hangText='SZX:'>
+  Block Size. The block size is a three-bit unsigned integer indicating the size of a block to
+  the power of two. Thus block size = 2**(SZX + 4).  The allowed
+  values of SZX are 0 to 6, i.e., the minimum block size is 2**(0+4) = 16
+  and the maximum is 2**(6+4) = 1024.
+  The value 7 for SZX (which would indicate a block size of 2048) is
+  reserved, i.e. MUST NOT be sent and MUST lead to a 4.00 Bad Request
+  response code upon reception in a request.</t>
+</list></t>
+
+<t>The Block options are used in one of three roles:</t>
+
+<t><list style="symbols">
+  <t>In descriptive usage, i.e. a Block2 Option in a response (e.g., a
+2.05 response for GET), or a Block1 Option in a request (e.g., PUT
+or POST):
+  <list style="symbols">
+      <t>The NUM field in the option value describes what block number is
+contained in the payload of this message.</t>
+      <t>The M bit indicates whether further
+blocks are required to complete the transfer of that body.</t>
+      <t>The block size given by SZX MUST match the size of the payload in
+bytes, if the M bit is set. (The block size given is irrelevant if
+M is unset).  For Block2, if the request suggested a larger value
+of SZX, the next request MUST move SZX down to the size given
+here.  (The effect is that, if the server uses the smaller of its
+preferred block size and the one requested, all blocks for a body
+use the same block size.)</t>
+    </list></t>
+  <t>A Block2 Option in control usage in a request (e.g., GET):
+  <list style="symbols">
+      <t>The NUM field in the Block2 Option gives the block number of the
+payload that is being requested to be returned in the response.</t>
+      <t>In this case, the M bit has no function and MUST be set to zero.</t>
+      <t>The block size given (SZX) suggests a block size (in the case of
+block number 0) or repeats the block size of previous blocks
+received (in the case of block numbers other than 0).</t>
+    </list></t>
+  <t>A Block1 Option in control usage in a response (e.g., a 2.xx
+response for a PUT or POST request):
+  <list style="symbols">
+      <t>The NUM field of the Block1 Option indicates what block number is
+being acknowledged.</t>
+      <t>If the M bit was set in the request, the server can choose whether
+to act on each block separately, with no memory, or whether to
+handle the request for the entire body atomically, or any mix of
+the two.  If the M bit is also set in the response, it indicates
+that this response does not carry the final response code to the
+request, i.e. the server collects further blocks and plans to
+implement the request atomically (e.g., acts only upon reception
+of the last block of payload).  Conversely, if the M bit is unset
+even though it was set in the request, it indicates the block-wise
+request was enacted now specifically for this block, and the
+response carries the final response to this request (and to any
+previous ones with the M bit set in the response's Block1 Option
+in this sequence of block-wise transfers); the client is still
+expected to continue sending further blocks, the request method
+for which may or may not also be enacted per-block.</t>
+      <t>Finally, the SZX block size given in a control Block1 Option
+indicates the largest block size preferred by the server for
+transfers toward the resource that is the same or smaller than the
+one used in the initial exchange; the client SHOULD use this block
+size or a smaller one in all further requests in the transfer
+sequence, even if that means changing the block size (and possibly
+scaling the block number accordingly) from now on.</t>
+    </list></t>
+</list></t>
+
+</section>
+<section anchor="block-usage" title="Using the Block Options">
+
+<t>Using one or both Block options, a single REST operation can be split
+into multiple CoAP message exchanges.  As specified in
+<xref target="I-D.ietf-core-coap"/>, each of these message exchanges uses their own
+CoAP Message ID.</t>
+
+<t>When a request is answered with a response carrying a Block2 Option with
+the M bit set, the requester may retrieve additional blocks of the
+resource representation by sending further
+requests with the same options and a Block2 Option giving the block
+number and block size desired.  In a request, the client MUST set the M bit of a Block2 Option
+to zero and the server MUST ignore it on reception.</t>
+
+<t>To influence the block size used in a response, the
+requester also uses the Block2 Option, giving the desired size, a block
+number of zero and an M bit of zero.  A server MUST use the block
+size indicated or a smaller size.  Any further block-wise requests for
+blocks beyond the first one MUST indicate the same block size that was
+used by the server in the
+response for the first request that gave a desired size using a Block2
+Option.</t>
+
+<t>Once the Block2 Option is used by the requester, all requests in a
+single block-wise transfer
+MUST ultimately use the same size, except that there may not be enough
+content to fill the last block (the one returned with the M bit not
+set).
+(Note that the client may start using the Block2 Option in a second
+request after a first request without a Block2 Option resulted in a
+Block option in the response.)
+The server SHOULD use the block
+size indicated in the request option or a smaller size, but the
+requester MUST take note of the actual block size used in the response
+it receives
+to its initial request and proceed to use it in subsequent requests. The
+server behavior MUST ensure that this client behavior results in the
+same block size for all responses in a sequence (except for the last
+one with the M bit not set, and possibly the first one if the initial
+request did not contain a Block2 Option).</t>
+
+<t>Block-wise transfers can be used to GET resources the representations
+of which are entirely static (not changing over time at all, such as
+in a schema describing a device), or for dynamically changing
+resources.  In the latter case, the Block2 Option SHOULD be used in
+conjunction with the ETag Option, to ensure that the blocks being
+reassembled are from the same version of the representation: The
+server SHOULD include an ETag option in each response.  If an ETag
+option is available, the client's reassembler, when reassembling the
+representation from the blocks being exchanged, MUST compare ETag
+Options.  If the ETag Options do not match in a GET transfer, the
+requester has the option of attempting to retrieve fresh values for
+the blocks it retrieved first.  To minimize the resulting
+inefficiency, the server MAY cache the current value of a
+representation for an ongoing sequence of requests.  The client MAY
+facilitate identifying the sequence by using the Token Option with a
+non-default value.  Note well that this specification makes no
+requirement for the server to establish any state; however, servers
+that offer quickly changing resources may thereby make it impossible
+for a client to ever retrieve a consistent set of blocks.</t>
+
+<t>In a request with a request payload (e.g., PUT or POST), the Block1
+Option refers to the payload in the request (descriptive usage).</t>
+
+<t>In response to a request with a payload (e.g., a PUT or POST
+transfer), the block size given in the Block1 Option indicates the
+block size preference of the server for this resource (control usage).
+Obviously, at this point the first block has already been transferred
+by the client without benefit of this knowledge.  Still, the client
+SHOULD heed the preference and, for all further blocks, use the block
+size preferred by the server or a smaller one.  Note that any
+reduction in the block size may mean that the second request starts
+with a block number larger than one, as the first request already
+transferred multiple blocks as counted in the smaller size.</t>
+
+<t>To counter the effects of adaptation layer fragmentation on packet
+delivery probability, a client may want to give up retransmitting a
+request with a relatively large payload even before MAX_RETRANSMIT has
+been reached, and try restating the request as a block-wise transfer
+with a smaller payload.  Note that this new attempt is then a new
+message-layer transaction and requires a new Message ID.
+(Because of the uncertainty whether the request or the acknowledgement
+was lost, this strategy is useful mostly for idempotent requests.)</t>
+
+<t>In a blockwise transfer of a request payload (e.g., a PUT or POST) that is intended to be implemented in an
+atomic fashion at the server, the actual creation/replacement takes
+place at the time the final block, i.e. a block with the M bit unset
+in the Block1 Option, is received.  If not
+all previous blocks are available at the server at this time, the
+transfer fails and error code 4.08 (Request Entity Incomplete) MUST be returned.  The error
+code 4.13 (Request Entity Too Large) can be returned at any time by a server that does not
+currently have the resources to store blocks for a block-wise request payload transfer that it would intend to implement in an atomic fashion.</t>
+
+<t>If multiple concurrently proceeding block-wise request payload
+transfer (e.g., PUT or POST) operations
+are possible, the requester SHOULD use the Token Option to clearly separate the different sequences.
+In this case, when reassembling the representation from the blocks
+being exchanged to enable atomic processing, the reassembler MUST
+compare any Token Options present (and, as usual, taking an absent Token Option
+to default to the empty Token).
+If atomic processing is not desired, there is no need to process the
+Token Option (but it is still returned in the response as usual).</t>
+
+</section>
+</section>
+<section anchor="examples" title="Examples">
+
+<t>This section gives a number of short examples with message flows for a
+block-wise GET, and for a PUT or POST.
+These examples demonstrate the basic operation, the operation in the
+presence of retransmissions, and examples for the operation of the
+block size negotiation.</t>
+
+<t>In all these examples, a Block option is shown in a decomposed way
+separating the kind of Block option (1 or 2), block number (NUM), more bit (M), and block size exponent
+(2**(SZX+4)) by slashes.  E.g., a Block2 Option value of 33 would be shown as
+2/2/0/32), or a Block1 Option value of 59 would be shown as 1/3/1/128.</t>
+
+<t>The first example (<xref target="simple-get"/>) shows a GET request that is split
+into three blocks.
+The server proposes a block size of 128, and the client agrees.
+The first two ACKs contain 128 bytes of payload each, and third ACK
+contains between 1 and 128 bytes.</t>
+
+<figure title="Simple blockwise GET" anchor="simple-get"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                            |
+  | CON [MID=1234], GET, /status                       ------> |
+  |                                                            |
+  | <------   ACK [MID=1234], 2.05 Content, 2/0/1/128          |
+  |                                                            |
+  | CON [MID=1235], GET, /status, 2/1/0/128            ------> |
+  |                                                            |
+  | <------   ACK [MID=1235], 2.05 Content, 2/1/1/128          |
+  |                                                            |
+  | CON [MID=1236], GET, /status, 2/2/0/128            ------> |
+  |                                                            |
+  | <------   ACK [MID=1236], 2.05 Content, 2/2/0/128          |
+]]></artwork></figure>
+
+<t>In the second example (<xref target="early-get"/>), the client anticipates the blockwise transfer
+(e.g., because of a size indication in the link-format description)
+and sends a size proposal.  All ACK messages except for the last carry
+64 bytes of payload; the last one carries between 1 and 64 bytes.</t>
+
+<figure title="Blockwise GET with early negotiation" anchor="early-get"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], GET, /status, 2/0/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.05 Content, 2/0/1/64         |
+  |                                                          |
+  | CON [MID=1235], GET, /status, 2/1/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.05 Content, 2/1/1/64         |
+  :                                                          :
+  :                          ...                             :
+  :                                                          :
+  | CON [MID=1238], GET, /status, 2/4/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1238], 2.05 Content, 2/4/1/64         |
+  |                                                          |
+  | CON [MID=1239], GET, /status, 2/5/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1239], 2.05 Content, 2/5/0/64         |
+]]></artwork></figure>
+
+<t>In the third example (<xref target="late-get"/>), the client is surprised by the
+need for a blockwise transfer, and unhappy with the size chosen
+unilaterally by the server.  As it did not send a size proposal
+initially, the negotiation only influences the size from the second
+message exchange onward.  Since the client already obtained both the first and
+second 64-byte block in the first 128-byte exchange, it goes on
+requesting the third 64-byte block ("2/0/64").  None of this is (or
+needs to be) understood by the server, which simply responds to the
+requests as it best can.</t>
+
+<figure title="Blockwise GET with late negotiation" anchor="late-get"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], GET, /status                     ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.05 Content, 2/0/1/128        |
+  |                                                          |
+  | CON [MID=1235], GET, /status, 2/2/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.05 Content, 2/2/1/64         |
+  |                                                          |
+  | CON [MID=1236], GET, /status, 2/3/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1236], 2.05 Content, 2/3/1/64         |
+  |                                                          |
+  | CON [MID=1237], GET, /status, 2/4/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1237], 2.05 Content, 2/4/1/64         |
+  |                                                          |
+  | CON [MID=1238], GET, /status, 2/5/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1238], 2.05 Content, 2/5/0/64         |
+]]></artwork></figure>
+
+<t>In all these (and the following) cases, retransmissions are handled by
+the CoAP message exchange layer, so they don't influence the block
+operations (<xref target="late-get-lost-con"/>, <xref target="late-get-lost-ack"/>).</t>
+
+<figure title="Blockwise GET with late negotiation and
+  lost CON" anchor="late-get-lost-con"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], GET, /status                     ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.05 Content, 2/0/1/128        |
+  |                                                          |
+  | CON [MID=1235], GE/////////////////////////              |
+  |                                                          |
+  | (timeout)                                                |
+  |                                                          |
+  | CON [MID=1235], GET, /status, 2/2/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.05 Content, 2/2/1/64         |
+  :                                                          :
+  :                          ...                             :
+  :                                                          :
+  | CON [MID=1238], GET, /status, 2/5/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1238], 2.05 Content, 2/5/0/64         |
+]]></artwork></figure>
+
+<figure title="Blockwise GET with late negotiation and
+  lost ACK" anchor="late-get-lost-ack"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], GET, /status                     ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.05 Content, 2/0/1/128        |
+  |                                                          |
+  | CON [MID=1235], GET, /status, 2/2/0/64           ------> |
+  |                                                          |
+  | //////////////////////////////////tent, 2/2/1/64         |
+  |                                                          |
+  | (timeout)                                                |
+  |                                                          |
+  | CON [MID=1235], GET, /status, 2/2/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.05 Content, 2/2/1/64         |
+  :                                                          :
+  :                          ...                             :
+  :                                                          :
+  | CON [MID=1238], GET, /status, 2/5/0/64           ------> |
+  |                                                          |
+  | <------   ACK [MID=1238], 2.05 Content, 2/5/0/64         |
+]]></artwork></figure>
+
+<t>The following examples demonstrate a PUT exchange; a POST exchange
+looks the same, with different requirements on atomicity/idempotence.
+To ensure that the blocks relate to the same version of the resource
+representation carried in the request, the client in
+<xref target="simple-put-atomic"/> sets the Token to
+"v17" in all requests.  Note that, as with the GET, the responses to
+the requests that have a more bit in the request Block2 Option are
+provisional; only the final response tells the client that the PUT
+succeeded.</t>
+
+<figure title="Simple atomic blockwise PUT" anchor="simple-put-atomic"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], PUT, /options, v17, 1/0/1/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.04 Changed, 1/0/1/128        |
+  |                                                          |
+  | CON [MID=1235], PUT, /options, v17, 1/1/1/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.04 Changed, 1/1/1/128        |
+  |                                                          |
+  | CON [MID=1236], PUT, /options, v17, 1/2/0/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1236], 2.04 Changed, 1/2/0/128        |
+]]></artwork></figure>
+
+<t>A stateless server that simply builds/updates the resource in place
+(statelessly) may indicate this by not setting the more bit in the
+response (<xref target="simple-put-stateless"/>); in this case, the response codes are valid separately for
+each block being updated.  This is of course only an acceptable
+behavior of the server if the potential inconsistency present during
+the run of the message exchange sequence does not lead to problems,
+e.g. because the resource being created or changed is not yet or not currently in
+use.</t>
+
+<figure title="Simple stateless blockwise PUT" anchor="simple-put-stateless"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], PUT, /options, v17, 1/0/1/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.04 Changed, 1/0/0/128        |
+  |                                                          |
+  | CON [MID=1235], PUT, /options, v17, 1/1/1/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.04 Changed, 1/1/0/128        |
+  |                                                          |
+  | CON [MID=1236], PUT, /options, v17, 1/2/0/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1236], 2.04 Changed, 1/2/0/128        |
+]]></artwork></figure>
+
+<t>Finally, a server receiving a blockwise PUT or POST may want to indicate a
+smaller block size preference (<xref target="simple-put-atomic-nego"/>).
+In this case, the client SHOULD continue with a smaller block size; if
+it does, it MUST adjust the block number to properly count in that smaller size.</t>
+
+<figure title="Simple atomic blockwise PUT with
+negotiation" anchor="simple-put-atomic-nego"><artwork><![CDATA[
+CLIENT                                                     SERVER
+  |                                                          |
+  | CON [MID=1234], PUT, /options, v17, 1/0/1/128    ------> |
+  |                                                          |
+  | <------   ACK [MID=1234], 2.04 Changed, 1/0/1/32         |
+  |                                                          |
+  | CON [MID=1235], PUT, /options, v17, 1/4/1/32     ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.04 Changed, 1/4/1/32         |
+  |                                                          |
+  | CON [MID=1236], PUT, /options, v17, 1/5/1/32     ------> |
+  |                                                          |
+  | <------   ACK [MID=1235], 2.04 Changed, 1/5/1/32         |
+  |                                                          |
+  | CON [MID=1237], PUT, /options, v17, 1/6/0/32     ------> |
+  |                                                          |
+  | <------   ACK [MID=1236], 2.04 Changed, 1/6/0/32         |
+]]></artwork></figure>
+
+</section>
+<section anchor="http-mapping" title="HTTP Mapping Considerations">
+
+<t>In this subsection, we give some brief examples for the influence the
+Block options might have on intermediaries that map between CoAP and
+HTTP.</t>
+
+<t>For mapping CoAP requests to HTTP, the intermediary may want to map
+the sequence of block-wise transfers into a single HTTP transfer.
+E.g., for a GET request, the intermediary could perform the HTTP
+request once the first block has been requested and could then fulfill
+all further block requests out of its cache.
+A constrained implementation may not be able to cache the entire
+object and may use a combination of TCP flow control and (in
+particular if timeouts occur) HTTP range requests to obtain the
+information necessary for the next block transfer at the right time.</t>
+
+<t>For PUT or POST requests, there is more variation in how HTTP servers
+might implement ranges.  Some WebDAV servers do, but in general the
+CoAP-to-HTTP intermediary will have to try sending the payload of all
+the blocks of a block-wise transfer within one HTTP request.  If
+enough buffering is available, this request can be started when the
+last CoAP block is received.  A constrained implementation may want to
+relieve its buffering by already starting to send the HTTP request at
+the time the first CoAP block is received; any HTTP 408 status code
+that indicates that the HTTP server became impatient with the
+resulting transfer can then be mapped into a CoAP 4.08 response code
+(similarly, 413 maps to 4.13).</t>
+
+<t>For mapping HTTP to CoAP, the intermediary may want to map a single
+HTTP transfer into a sequence of block-wise transfers.
+If the HTTP client is too slow delivering a request body on a PUT or
+POST, the CoAP server might time out and return a 4.08
+response code, which in turn maps well to an HTTP 408 status code
+(again, 4.13 maps to 413).
+HTTP range requests received on the HTTP side may be served out of a
+cache and/or mapped to GET
+requests that request a sequence of blocks overlapping the range.</t>
+
+<t>(Note that, while the semantics of CoAP 4.08 and HTTP 408 differ, this
+difference is largely due to the different way the two protocols are
+mapped to transport.  HTTP has an underlying TCP connection, which
+supplies connection state, so a HTTP 408 status code can immediately
+be used to indicate that a timeout occurred during transmitting a
+request through that active TCP connection.
+The CoAP 4.08 response code indicates one or more missing blocks,
+which may be due to timeouts or resource constraints; as there is no
+connection state, there is no way to deliver such a response
+immediately; instead, it is delivered on the next block transfer.
+Still, HTTP 408 is probably the best mapping back to HTTP, as the
+timeout is the most likely cause for a CoAP 4.08.
+Note that there is no way to distinguish a timeout from a missing
+block for a server without creating additional state, the need for
+which we want to avoid.)</t>
+
+</section>
+<section anchor="iana-considerations" title="IANA Considerations">
+
+<t>This draft adds the following option numbers to the CoAP Option
+Numbers registry of
+<xref target="I-D.ietf-core-coap"/>:</t>
+
+<texttable title="CoAP Option Numbers" anchor="tab-option-registry">
+      <ttcol align='right'>Number</ttcol>
+      <ttcol align='left'>Name</ttcol>
+      <ttcol align='left'>Reference</ttcol>
+      <c>17</c>
+      <c>Block2</c>
+      <c>&SELF;</c>
+      <c>19</c>
+      <c>Block1</c>
+      <c>&SELF;</c>
+</texttable>
+
+<t>This draft adds the following response code to the CoAP Response Codes registry of
+<xref target="I-D.ietf-core-coap"/>:</t>
+
+<texttable title="CoAP Response Codes" anchor="tab-response-code-registry">
+      <ttcol align='right'>Code</ttcol>
+      <ttcol align='left'>Description</ttcol>
+      <ttcol align='left'>Reference</ttcol>
+      <c>136</c>
+      <c>4.08 Request Entity Incomplete</c>
+      <c>&SELF;</c>
+</texttable>
+
+</section>
+<section anchor="security-considerations" title="Security Considerations">
+
+<t>Providing access to blocks within a resource may lead to
+surprising vulnerabilities.
+Where requests are not implemented atomically, an attacker may be able
+to exploit a race condition or confuse a server by inducing it to use
+a partially updated resource representation.
+Partial transfers may also make certain problematic data invisible to
+intrusion detection systems; it is RECOMMENDED that an intrusion
+detection system (IDS) that analyzes resource representations transferred by
+CoAP implement the Block options to gain access to entire resource representations.
+Still, approaches such as transferring even-numbered blocks on one path and odd-numbered
+blocks on another path, or even transferring blocks multiple times
+with different content and
+obtaining a different interpretation of temporal order at the IDS than
+at the server, may prevent an IDS from seeing the whole picture.
+These kinds of attacks are well understood from IP fragmentation and
+TCP segmentation; CoAP does not add fundamentally new considerations.</t>
+
+<t>Where access to a resource is only granted to clients making use of a specific security
+association, all blocks of that resource MUST be subject to the same
+security checks; it MUST NOT be possible for unprotected exchanges to
+influence blocks of an otherwise protected resource.
+As a related consideration, where object security is employed,
+PUT/POST should be implemented in the atomic fashion, unless the
+object security operation is performed on each access and the
+creation of unusable resources can be tolerated.</t>
+
+<section anchor="mitigating-exhaustion-attacks" title="Mitigating Resource Exhaustion Attacks">
+
+<t>Certain blockwise requests may induce the server to create state, e.g. to
+create a snapshot for the blockwise GET of a fast-changing resource
+to enable consistent access to the same
+version of a resource for all blocks, or to create temporary
+resource representations that are collected until pressed into
+service by a final PUT or POST with the more bit unset.
+All mechanisms that induce a server to create state that cannot simply
+be cleaned up create opportunities for denial-of-service attacks.
+Servers SHOULD avoid being subject to resource exhaustion based on state
+created by untrusted sources.
+But even if this is done, the mitigation may cause a denial-of-service
+to a legitimate request when it is drowned out by other state-creating
+requests.
+Wherever possible, servers should therefore minimize the opportunities
+to create state for untrusted sources, e.g. by using stateless approaches.</t>
+
+<t>Performing segmentation at the application layer is almost always
+better in this respect than at the transport layer or lower (IP fragmentation,
+adaptation layer fragmentation), e.g. because there is application
+layer semantics that can be used for mitigation or because lower
+layers provide security associations that can prevent attacks.
+However, it is less common to apply timeouts and keepalive mechanisms
+at the application layer than at lower layers.  Servers MAY want to
+clean up accumulated state by timing it out (cf. response code 4.08), and
+clients SHOULD be prepared to run blockwise transfers in an expedient
+way to minimize the likelihood of running into such a timeout.</t>
+
+</section>
+<section anchor="mitigating-amplification-attacks" title="Mitigating Amplification Attacks">
+
+<t><xref target="I-D.ietf-core-coap"/> discusses the susceptibility of
+CoAP end-points for use in amplification attacks.</t>
+
+<t>A CoAP server can reduce the amount of amplification it provides to an
+attacker by offering large resource representations only in relatively
+small blocks.  With this, e.g., for a 1000 byte resource, a 10-byte request might
+result in an 80-byte response (with a 64-byte block) instead of a
+1016-byte response, considerably reducing the amplification provided.</t>
+
+</section>
+</section>
+<section anchor="acknowledgements" title="Acknowledgements">
+
+<t>Much of the content of this draft is the result of
+discussions with the <xref target="I-D.ietf-core-coap"/> authors, and via many CoRE
+WG discussions. Tokens were suggested by Gilman Tolle and refined by
+Klaus Hartke.</t>
+
+<t>Charles Palmer provided extensive editorial comments to a previous
+version of this draft, some of which the authors hope to have covered
+in this version.</t>
+
+</section>
+
+
+  </middle>
+
+  <back>
+
+    <references title='Normative References'>
+
+&RFC2119;
+&RFC2616;
+&I-D.ietf-core-coap;
+
+
+    </references>
+
+    <references title='Informative References'>
+
+<reference anchor="REST" >
+  <front>
+    <title>Architectural Styles and the Design of Network-based Software Architectures</title>
+    <author initials="R." surname="Fielding" fullname="Roy Fielding">
+      <organization>University of California, Irvine</organization>
+    </author>
+    <date year="2000"/>
+  </front>
+</reference>
+
+
+    </references>
+
+
+<section anchor="compat" title="Historical Note">
+
+<t>(This appendix to be deleted by the RFC editor.)</t>
+
+<t>An earlier version of this draft used a single option:</t>
+
+<texttable>
+      <ttcol align='right'>Type</ttcol>
+      <ttcol align='left'>C/E</ttcol>
+      <ttcol align='left'>Name</ttcol>
+      <ttcol align='left'>Format</ttcol>
+      <ttcol align='left'>Length</ttcol>
+      <ttcol align='left'>Default</ttcol>
+      <c>13</c>
+      <c>Critical</c>
+      <c>Block</c>
+      <c>uint</c>
+      <c>1-3 B</c>
+      <c>0 (see below)</c>
+</texttable>
+
+<t>Note that this option number has since been reallocated in
+<xref target="I-D.ietf-core-coap"/>; no backwards compatibility is provided after
+July 1st, 2011.</t>
+
+</section>
+
+
+  </back>
+
+<!-- ##markdown-source:
+H4sIAMEV/FkAA+19aXcbx5Xo9/oV9ehzJoANQARJbVQyZyiKsvmihSNRcZKZ
+OVYBKBAdNbrxuhukYEn57XO32hoNSY5jO8kzc2KRQHctt+6+1XA4VE3W5PZY
+P8zL6ZubrLa6qUxRz21V66zQp+XJhfpCm8mkstfH9OeQHlWzclqYJbw5q8y8
+GWa2mQ+nZWWHE/x6uH9bzUwDXx/sjw+G++Ph+BDGST5K/lbwV92YYvadycsC
+PmyqtVUqW1X0a90c7O/f3z9QprLmWJ+sVnk2NU1WFrW6ucKFvTjT35bVm6y4
+0l9X5Xql3twc6/OisVVhm+EjXKSCN45hlplS03IGTx7rdT009TTL1Co71vDz
+hZ6aAj612lSV2eheNtcmz/XG1n1dVnph6oVe2MrCcvVQN+WUf6nLqqnsvJa/
+Nkv6Q+MDx/gy/OoeOaZpZnZu1nlTwxPue36JH1dm3SzK6lhp+hnKvxrOBJ44
+HemHZbU0ReE/57M4NVXd2GLr27KCvb4qsms41qwxttEPK7uEBy//fO4fCsec
+flrDsm1zHH0y1Bdl3czNdKEPD/ePjvaT7x5mkzwrm4V9A2+O9Nh/KQPtfHma
+NZtjWVn4sJzBxh4ND+4d3r4ffboumgqe/triTjf+i9WCsOero/vDo4Px8GB8
+b3jn8P5BWARMXGfLLG89dHd/PyzELk2WHwMqTMr/aL7PRgC+7oP480i/XNh8
+smmdw59xd61v6Axe2qLOCtiS/7gqcSl2ljVltQWp32cz+2b9F6MPWkD6w7p8
+Y5oma4Hp3r070TY8kB5nRQ6k1QbS3leHt+8d7d+9e//Owf27e+3tfw+b+I/a
+LXg0LZdKFYhYDeDRMWK6wERX8+nBeHy//dGd8Z34o/Pho1FgE9PSrGDGF49P
+8dVj+RVewV+3Hz0GXlDMw+zw+NnLS0ZKYWEn1XSRNXbarCuT65fNJre1hm1r
+QEX9yNbZVaHLuX5mmxtgFMOJqe1MvyznzQ0wlfhtIketHQl+0Xn0L0YAVpsj
+G2kd/otys/1VSoEbXMipyTPYUZGZgT6vrrOCkcLxRDhIZYsGj9uP8vLsyWM4
+t/8CUP0Rfv5nD9nmcDjURdnY787PXn793TP4TX0BH09y4/6vFD5jJoBWZtoo
+pZCP6wygQ1Ccr3PP9fWqKoFplbmGpQEGFfgOLG2mEQkYngVDsB6ph6bOpiQV
+9NLWtbmCJ/ArfWNzHgFhXy+Rha7MJi/NDB6w2r5dAaTVvCqXurHLla0Mwl0j
+tpVVPdB5drVodH2TNdOFhb9xWiJbU6nJOiPYDuGAyiUJAWCn19nUwoqeT6ew
+prKAGTcDvShvLEAc3o8Ehr7JYDmFhT0B83UbVzD0Fe7fLRNBhjuA0wa5NLUD
++mueVUvCl/UKD6oe6W+zZqG+uby8GOjL0ws9KwEGuOurCqiPoQGHXcP0KJto
+ljAJyKmsgFUsQRZkqxy/mb6xDcMZgLGu8KVmYRocc0OyCCQToBE+gdIQRFIx
+y2EvIK1x2oogV1YzW43CQTOyI6BMY64qs+R9r0Am1bpeA7cytX716AJl3KPL
+Jy8H6maRwac5wLzh/SzN22y5XsIxfG9xR0Am5bqawox2Bb8Dqgp4cbUKxegk
+KBMVzA6HuSjXsJES9wuDzytztXTvjdRJjt9fLWgd9XrFi2sfS7Oo6KHzC5W8
+P9BZgzulFfPR3jkCBvoQATXQS2AkOlvimKZoADcUHlTxmwaWj7jSQtsY8RPc
+QagH/Ffn8Jg1M4ZHvsHDAiCfX+jW2poFLK0GpM/mMpSyb0FSz+hoHA0hhIAm
+VyarcMQ90rT2dLmiuQkBlYcozuXRhpSuGl/yXBLWQfRl/Emp9KQQY/wAlf1/
+a1s3Q/h+BXNZWgRg9zk8g/LVgw6kYo0UiShB63PLA3Q1ExjJABVXQHR4AoQB
+63yjgIQaC/wYGCdxBH4CkYTRV1uUmLSLQJG1XZkK3wNKJtAUJZMtnpDBMyqA
+i+BOatusV4i7qHbgizj8sAbpCXwJjp74Lez9OivXdWsaPkZAuOXSVJuujQFL
+vMahjF5mRQbMTN+AatiU/iwckrYpAQBseLYhqdZz0B4J1ZkhL7MZbB1nb6py
+tuatyM+7L2BWAOey/qB+F/0odQnrY3X3a8T3xtRvhLhYgTbVLPsekcMUKtKT
+9UXM2E8j/BaBWN96hhx+QKg4gmmyOgiDDDeD+MqU5SDipMe7d/jbhw90sMiI
+USCpdZFnb6xG3ohPsHj/8IF4C6Ec7JnZm4XDXAIavhXRmOEfnnyQNxFlGuZE
+woGU45X27RSw6Ip5IHE+XOPSwNzweG3DqkCxx+XSuSyAUQJmJiKOIYErgBeX
+tc2v4SV+cFsWjhQDqZz8BdHwmokoAwxAiqNHG56qWC8nlki6Lpe2yUBW4nBz
+OJsGAQDoVIOCMwwgaQEggk6yRURHBAZqfwSWQTyIiGT6ou5+EcEZVueYFuo/
+SGhCakSbbrAeypl1VTCI34ZhEF/NJMv5CGGEmc1R3dkION0IfSYxs0TtlL5D
+KlpmNYptvQKJXcnkMIZT35D3E3PloYTJgw5XzG6yGaA+YkBh82T/chy0I2TL
++KYtrrOqLPAzL/eAbJBx1aCBw/oGMO1VWYK+QUyTmCqscFYuC9gAMhnAoorI
+AbUpOh6z4p1nhBU/VOgCdwvCFlepfpCs1duyVjlZOwXpRii2LuC3umQWnYNS
+lNPG2pJqBLp3ocwMzBGSW0DGpHPsXADpUnMUvajGAO+HyXCGrHgDGtWGJDdS
+KU5mdAexuc0vgaVODVneM7Pi4WWEZIUa1g6ii5be9XVGvMed/WykXuGSWg/1
+bIaCQrNaFc0oQ5b+K1Az6KM+4rtIOPzcnyRubBf7BwZaAlrDOwrEEyqbHXoU
+frYGxlqx+uBxxfPenqCKAlQB4pmseWXJjm7h6dZ2OQFGBS9OEVOdvoTUc0NC
+CvZRE2rgQaAlwnsm4cyohFhrG8BslPrmKqiVkRLEAHHcL1Fq0K0Bh1tHSgwR
+g5OkAYZfBrH4pTZTWjBI1F14NiKx93liWbfE8s5Bd8tnnKy8RiWLuY7n8Bnt
+wVyX2Ux52uoApmCP6DnIRKNpvj67dPoWbKx3TmBHBYtxBWcAKQUnSfPoj82D
+GuHF85eXty5eXQ6QKkiW0guEFKvcTIkBxlyklm1McJ3lMps+AIlsK0EBACvY
+YyhpmJKYFxPTrix/6I0nmsltU3Wsj7AH3kGlcaCZ6kZ91da4tvAIOFCMROnB
+w8SEVbGhsa5FWEVwDhqe1g9tAajZENNb16J1wDMyJlhh03w9syCFv9SX3gMq
+hA0TFY7LAq6Wy2WJxh8RR8TShsLSQIAg/xvG/K927wNsUUHnl8kytrJowIUv
+9bMSNOJqNmzKIVNg16kjQAnys20OhpM7HhZYZFm1rS3Y5iKACMESqeDoGpi+
+KcobMCyv8PCJalmmxuIaJsvmEa/9Uj8sUQ/N0FWwMNdkDZiNYyI8eM0aA6wc
+xOeajS+UInKKbmmArWicwJxOv4NFVWgp1ETlxDNJ45UDZUCT0mDyzfek6ZS5
+cwGB3g+rbKwwG0doMztZX13B6zjt+TzG9hbW4fmZvC49thlHR44RsZaAC3D8
+jNWZYTkfAmLQxmfOVEM2TPxnB3casab/xpJpCtSw9/TVy8u9Af+rnz2n31+c
+/eer8xdnj/D3l9+cPHnif+EnFPzx/NUT+R5/C2+ePn/69OzZI3756cmf9tjN
+svf84vL8+bOTJ3uOetHXvyYmgvBnxkHqD6y3YUDAeU+rbMJYDZq+RqfeQD88
+vdDjI8XKP3wCFgJOkRUzJHQba2hOKWHrG9TdDI1Nij+kyrDYa8Q03ML4vGBF
+S7032TR2D0+GDgmWg1QPqKyn6xr9RaCQopvJKoMcpt4UZbFZ0rR75bSxzR6M
+/y3xukmGO4ZzQp19ikPat8BQkdQH6fw4F4ta4JhMhnOzBI3QVGyEi4KMgn3J
+bqDiao3UfTpA9Larxjt5dEnuMFzPf3/531/uKcJxBgzMXxboFHQo8rCD2yX2
+YrAbT2C5WQ1AqINUzyLL03F4PGPSf1lhJDQOmikRr9NR6hYD9J5BYqOTTaLv
+eMWGhuj91blncF+o2YQ3AJkyRjQWgG0lVfeeXr5CjjU+uLdP759fXN/5yABb
++l1ruDv7wyGMhJiDpg+OeOdJ+e3FybM+4cJHyJRcTttSAjB4jv4S0MdU7AMT
+uIs3i5ViUZlJpDkgASkm7CcRc7AvT0GmS+CBvIPT9i4zflfhmvUE+TOpgE4D
+IYqUT9j3U3f6q4TLAT4gKxPXjOeO3k6cAeTZKkKXi+zTL0xIFxWXHLRS2HlM
+uvL4XiIPvBuZpQVqGY0oNCnsxL4ENWhkR+E7FjoTi9746CjI7nDKPDOOcrbZ
+MTWSXGV3KZKR6kyKRXre8Qmp4AFCx1pZe3caGlkiGbZHYX8Xrs8vjw0HVZsl
+2/dw5JephBX1bZ69RaGzcSyIbAp8ugTZYlc0yra7paaP8DenlXaJRHHSgomL
+yqpiP3+FopoOP5Z9YWHox0SWeIDc7Uj3xnfItqI/x/uqN94/OOozLTIew74z
+MsMxssm+e9gXmoEw6ywj0UvWJ25lx6R6uijhvAbBf0QqLA40weMEzPXUqcCE
+MXIaD0DjwhmZHvA9dwBXGdqh4pGKJiLzlBy1iOVhJJHnDMDnAkD97gtGDobo
+B3QLJj9KvdeXm5XV7/XprTN2Db7Xz/DU8ZfH5OqFX57Y4goo+L1+xHFl8SK+
+V+95nOOvwphffcYv8gPvwyjj+zg9CEJgBTn8SnsYwy9r9HDhOsbDQ/0Qf9kH
+a9UCPCwQd1/L63c7Xj/4rNffHesEQEP2VdUc8vvdXgxN/Yy/2/sAYhG5nCwT
+2ZtMGatyqIozDTNPhLMXjkg+fu8Hd3Et8oyIBSPmjCeIsVsCGk4gCWux9ZUb
+URjbwPuzZEHdr+nICU/vAe58Y30Iin1pzaKc1WJvE+a+e7cdNf3wYeBWCGqc
+eD+J10dSaDixhqIJaEjSCsGYTMUDPJ1VHiZkT/EGMu9TpVHBsh3QMIPOcRSN
+szWvH1f3Dkb744GG/x7Qf4/ov7cpFgeIASKMRcvehZMUwGe6N94HoPVOUMWT
+CIDJZpLm8t34uy2QRxIZ//xuXDfwkKkaJZ9sBUicVSLyJnpmEHDuu4Pv1Kem
+OihmPJXeMZXqnIq/G/WdturP2eO1mBeMgoA47sxEneFt9HBIGLhQJMWcm3d7
+reymAzXQ7adPETdRRADQqkMTIUg446DGeCyz0uhRNwVaxbWK4cBSl+XetlDs
+7fG4K3LMrHHVe3DoDAyOBUaAYMUahBmagF5HoaChV2yc21OUjKrM0XnLazae
+iL0EEDMeAHtjaud1o4W5t/2i1HkqYdHaZk4SC9R2lGXi1CuTj9Q3LpR9g/ro
+1v5MWwdqNNmJxOZkZarnuQcfcmXRr2Vn/QeKdP956UEHAAHozzM274yeOv7N
+KyJpVll82i634o7oy3UuolYQmJbKGWQ8EntcQlQnkqe9l3/+IyztS9wyAYuC
+uKIloZnilUiwCOhBpoycckSiuEY05LNXT/vB9q6ROICx4kM8Lqj/nj+yiCft
+ioX3tcnXfo3hzAwIMGBUQ0SFwyFqLnSMaBMw0cAUGDBS7HJqCHBzzBABXQjl
+3bt3NPmHDzCPjn7207/0WB/oQ32kb+s7+m783VfD1v/iL0EGw67h36fvNUAU
+xOpH32zNuf0z/tiq9D19P/7so3N9YtXuh1bvP/+sXfwNu+r47OCH7LT92Q9a
+32dCohskPwoyWzN7nStVsgTdiQRQxVLb5gajuTAMwvIhulDWBaZeEe0zUfTY
+aBcDABM1lP97LGZ438WFbkB3N6SBW/0atvcaVETSs8UV0n9AmhYbh60FNcgq
+Xx98+SVyEv2VPuq/BtUFf8cvt8xyxZSZWwPyEtdMxi8qiOI4jsieWYEIz9fw
+l/43ffe1+NHx79eygC6m0Rd+MgdrEnhN54SsXj5FnrKHfG+P3FE9mere6/5A
+Bdn7aQYpnH+6hv3iBMEk9aJa1pvjYiKjOQaUrDuBAVtgZGLW2dvGAsh7OA6i
+KDG5vhvZcVvVxZllZXmHqB+g27tqOIxXLtX3tipHJDPcdlp7EElmJqXEyl4j
+RrwWB48fDGQ6MevXuNTf/lYnWNLDRDoS/ANC6KIVk+doR5GxXv66x+fy1/23
+j/s0lqBE/3WktCVwQzGjPMCPGMmWnM0B64ZNL7K5ZDLRY3beODve4xSseKBQ
+TokditshJUe0DA9f1BMvyTXG9qEfgYyfyJLptlAArgh1j3NxVlqKVO6w51nF
+phR7B/g78Vr44+rxx4IP+wPAd8RyNMtri6TtE/ii6JNCL2w2zRqhc/QVOxdH
+Vqc7BIR9iqjgXVm5SybyOmF0JORSEjh4fVkxCAaiOZkiykOQt1mW6yzYY6YW
+2kNXKKDXsRLbQ6zUUeStkd2TInENFhHGR4fsJAX7ZwyWEDLHfYRMH1j7NjtF
+O5oViZPVCrTH7K0++YhhhEGb+BRb62DyE7OB9VvRkGcj0dy0P7FI/w+H7s+a
+fVZ4Brh/OojHuQFtDQ848Jn+CB0ZekudFzfkHF7B2Cbv3TaDZFLBQaecu4Cj
+U3G3mBrtnncNa3vA6jSMmhozblzxh4OkQTgge8XwjrcTPK+9NlmO5waMQ/zF
+W/TjwhEGRnBGGZA2BtQyy5EyQdL0PLbMCZEMMMwk0vLJEDBMphxkuSrKivNP
+wNqxK0nv6J371aEi59YX24RO9CDg/coTpzNFjbNmQ1iHC0GHDbIY4Ed41ILr
+L8kxua0ofFQ7aOGmMwuMS9srsawCT5ySGpAQb0ga+MQ+euN3rE54li7+UYM0
+SZlFRPG18FA65H1SRZhdC7VjXsF62Vo9D7z/1VEfZhnfibKUXKjDP3RHHto/
+OBopXgFzmrukAeHMPVFzynU+23Lr+90f7B/dQzlKuEPh9pnIFRcNDDgAi6EP
+c0xMpaSco9H+vn4If71gvONR2P6n1LH1KsaSxHGQ+C2dA40SoAWfiTbmYtVg
+NQOnsp0XXQQtrvkWcaQOCTu6AvgjmZDvx3+BEPv67LJP/NC0PG+Jr0OGuHh1
+qTDznjxSfcyiH9IReM1EdwmB4K24QSbQ4tGkWyNBGud323LpBO4z8lOyXNtW
+2OaoAFou/Ij0NhdRpxwLyv1rorSjudOdcHnEYN00EdKw8QpCEZGM8AGM8+ki
+oamUcfIiUEXymSSy7BoZ5Ej3OqdAZwHI/9xeo+ZKbFrDi8g3kFsj5T32wtSP
+7I6qXl9dsZwxLo5Gx0CjiILDgVX7tvFv8X5KwCvc3ay8KZyWFBZGIyAHR6aH
+K7fzuZ02LBFQq5OVSI6Oj+C6nAz0aTR83itQKNlQiHbviB7x30vLJJATwjY0
+yrrmM6SYTRgI2eYQBPYWTSRsvxPBkRo+gtbpiJGWGKO0qGS0TRetS8JZQRNg
+bw4IrHUV4b73RNJCzpOEn4BDC0OJQ/N1wR5cz6WIbZEkJLV+NyqTN8jhS51y
+yJ6sBWfl5FOd7nKfqvcqu7Km2QrZbOWG86kjP4SZZ+3Rk5FrTjnn4O8+Gnb+
+LMefOssWwwN29/ZtzJoZf9CJLjzMnUXnoQs9t6cOHGcHM+NTjtN95CRjFoAe
+TlKSiph6BzEBYVBluihLWLhwNy7OKjFwi1pIlF/UldnPbnpi7o47kqzXrkQg
+ZhtpYJZdxKyVsIaPkCs2IMDfOnQg7omaQrox1EYwqSfZnFODYpYtg5BamNXh
+kKjeB/XZqamqjWjBqBqmElYCQoxXAjxvFzoIgsUAHKp2UsFLBKCVVW4ogkAj
+eEs0gUnYv0epKSU+wwepgHfMtWXuh4A9Mu1TzjujM2qLA+LsNAqFO6Vu5yN4
+0lKubeyAiGBC79vCoFOacnZiu00O3UUPfDBNBnDQxvIob44kB0FnQGcnXJQG
+QG1549g8M4ESU1i9G5h33YEgv6lTauOzEQa45VpuZemw30pPwXYtWMRioJlh
+StVxTvoDhhdr0u0oFzXFjUGCARwVpDHmZRUlVqPtgj55yubmFDYH5ZWthhKg
+Rqp/nEnpHI6LwnVb3hecyE38rGv/8TGTSPcIRqNEwnQTY/9c6l9D/XlT3phq
+5kDOmRdONnlBCltzEpt4sEMIFMvrJNUJbDbABhdLS8AvqXEsoR2C0TAsIJAP
+e72gYAaOee9yFj7GKXP5CiYaQRBh4DPXJdCGBE1rSc1wFmhE85x6wchZAw10
+2uuYkFohauSbPmdWIOFQiOaVS3Rtpx2ExAMSSNt5Bz79gIcQ+3fiw+qhJs3n
+2WAFkOSucU0ExdjrVZ41rRrHOFIVkjs52UMIns5N7QppkyRh/hUi9FGaqNPl
+MHn4puB6jKfy1PmjUZTTxXSDQqCowZx0hVQm5SeUmN+2Wrz/zvOHhBgtk1ww
+77ecBqJ57UoqmmzaNK88nnnexCTgrLJitrVKoNkEa5zvFZ+N8I0z5mac5GBS
++S40QtoaqWp+z8Ff5uZTosd57ViIm15mjwTKgsQnAQYm+hbmOfPLFiV4t0nq
+nlABzMTRvPqeLGcQ71/2yHVSTn+MfNF+3YC5fn/sawaVLt6I0+R5BPYLCNub
+pcxCUrNOQBdJGDcLA3+eyPt89temFNixNw1pj8HnnAMdRgTzFJCeiuCVclaJ
+biR6ZRjf+6JwhCvO2Y5BJdnVJnWHwqk9d6fV7eqSNfhzGkghUWCVRsUpeql8
+VAxo4BhL0hNT64mPsJU4W1kv5Ei+oU7iswWxpiKTMFKk8vSCBSdWTUvsYx0j
+WbEqBARiqsAZKaAQqgq6vBu1hYXMfD6QmRPitk7AFW21aZgz4Z33MM0YaNlg
+fXLWyLknUm0HtqaKmht2C4d92VFEd3RCDVZZYvcBp09uB+JiKexTWrLG2Vc1
+8oyMMIIldJSGxbkLrAnhNkiNBBtwwkLVg64mL6PU/cLpLwwocrJCqqL3B4em
+KZ+cf4rB64S3alMWWWF5UCNrd6Ki3/UEDR1VIXYpRKltTGIhEYv2Fp2Lni2Q
+8OgyyzhVUfxObQTp70gE162kYa47cjVAfBxJQZTyaT5UaEG2VU74jfnv5LX3
+CktJJd7ZkmqdAD4DV9GoGDzThV0a50xjBsJNGth/h9CabQrjLBY3rheHknDH
+EKWKtFbSnScPQfOJxzQk+r84R4M/hbNLc+XFAhWixXjhw6acKOzL6dAxhYFU
+l8RP2EFNPEKALYXicYyKsjapLkLJQssI1EuqjCdfMk7lIRUlmLjwQiyQf1Pr
+sEqXF+Q/EV7ULvn3+4h3GwqoB0wy6HLEXdMyRGkMhnMESKyAIMxk3yKdPGKZ
+Q8G2qF5IvqxjM7DZBvt/sLc/CobMYdEL56N32bSyZmId/NyMaYfTmZOiZl89
+BOho52BBYqB2kzgsnp78CXBquuAXXBAzRAK3YEdOBaDTqxKXGxt4gQ1xWFo0
+ppM/qbmZYmEwVW1xStXGRzbcAJNNJDwuyzdwjpGOCQspymKYhjW1JmlEVfGB
+s6U1dFgAT/HSuMrG92TxPRoslT9nAG70mFCBWRR35edqTg4s5+h6hsGmbyKS
+jXgKSkOSxLAlqr9Hhu0LG5X0bWDo4NTXZDz5ABiWkmQ1yeuaS4b5yDld3iSC
+MvrT+S2D2987/eMkXeXFqViX9F0SOAyCsLcVvOjzKmJvwtaKWitJnHc+6i2L
+6jKsP+bAQ0raMqMdAqZ2tHdRsWHRS7yPsI/nE/JzoJnvUGdVZuJOimO4SK8m
+B6ZCGZjo6YlqzEXBk+N0ysuECy19KMS7FTHzBl0cMQ9Twh8XJOMXya6obYsT
+vm2vR4dOs8uv0DbeHe1wBWKxUdQvINamIigjQqOlHsQEa3IhfoG6nxRVm9Qw
+j8uCYN6BKxZIlT4Bb1Il1G7rYmru5RX0qMS+IAOKHxCvKEU6yML8ROkTJp9z
+2aTv1hD1cRgEakVA3Bgm2yuiiVWoBW04nUZt0SdnYgKvSNoesSNkwkk6T0/+
++N2Ls8sXJ89ePj2/RIxThGlSkyFevgotadJDhE168PlIQMt+kDU4QLlM+vjw
+CT8Le+OEkE8ZM/ipEr+ClPHSwCYEL3yvD3o4cS/0HlruZOCr+6ecMt1sgms7
+VrpdfZOnFTwghb7QvGQrnPyD6DG/2kQ591hAJH5REC7AZ5tEJ+4L2yTwpGnZ
+ZLnv4J8J1+p7j1srM9n7oMUuKRT7n10RfVoCP4htg876dDQkakV/u1dJuwx+
+XPH6SgiZSa2lY7NfuouRDjRxRI7osC6Dph01JktjP6TveY2rVcnvsAaXxsqN
+B+kc3pC+XVVFRayg8B2N9u/pnoTd9Rm1cwO11sV0+z4G5uxP0SBoCCVDjA+3
+hrgsS/0EaarvlHxvwDJXY+ABJwztmPAcXbRChXQ7KtOOfawkGrEZiuc/Esjc
+clxs1fcJsjQ+nQFRhlJHfMSCcEWnuIKSdR64HjDYsDyxAJHudy8gyijb1gGC
+U7KmhmlpRVtQTlvmcqKIoSc+t6ZCa8iVPpJPKZuTvGq8NgfKShoD7dTL286+
+ll6uWnp51DhDICdJ/b6AMjIFCKeU0+ERF+KthKqBHklYg9wEqHKAFMhto7BT
+ID4Qv6aoVp5VUNGckGXK2KBToOHSXpqrQRR3UncPCdeuBIkpgXkPXQ5ZiI3s
+jDz7PaCKdvbWIK6FKmjXp0RKhzgMnvRkWmANo5X3mKU4n/IcU/gY/+PyFqpz
+QlLfCtFS7xCqDpLhgC9zgbRgDLd78yg5EHvIuc3FCcFn5IyLuOWCNEP04zuF
+PgwhfuVIiynsVRlqxs85eNEk62wXHBPUF5hYQUbdzCI+lWhf35iN68zmkBnw
+ZtZu06F7lEN5gB1rknQ2rMCQfnyU0Yx/tbzRLrdb9XwS11dH/T65xHNgGeQc
+OBNhlToDvPl2eChMCIMQtBHQLA5uHdzav3V40J1D5N+9fX/7XT2+dXhrfGt8
+cM8lb5MaJ/DTvXfvuGZ2eGWbDx/69F4t5nDiYiU7zQdFOG3KmTmR8w7bsJS1
+bSU6cNF7qCMU7cxcwSjyPq8Ly19PTn9fe58RvMbJPXFdNupYbrCsmuEbSl6g
+RkA3qIlxTrB/H7b/1/CjTp+cnz277ChR+PTPy7MXfzh7oborHD775z0NcPr8
+mf6vp+ePfjc+ODz6nwFT6C3UGNf1jhc5xPXvMsCPXsFveTz4G6CYrIXS2E7Z
+EQ1/AQYSHrUH+NEriGFwuwUDnHeMM8fz/kwwuN0Bg/HPAIM7HTA4+IVgcKcD
+BltreZ9QFhbiBJ7iqnFecmV+0Olhh1SPI85SsU8jvkRqi7ClJKIH5lw2zVZp
+TkZqRYk6NQkGjdFxBCGymqnlEdcAhszPsugr6t1LrU6Nc10gazPYheAEBBGC
+yXcP7nCmcwhW3Tna4l8PwjPoPXepHynjcu9h181/IMb1abbFrGL/Fmwg/Pyd
+kPVvYVnROv4us38Ou/q5976LVbX2fvy3z3788ddHo9GPef1zZk8hf68D8ke/
+AOTvdUD+6CfGuvsde7/9C+z9fsfeW+vYFg2erSd1mr7BIJkxbLFG6v+e/uAl
+Bat8kaDIQRJ0yQnUWNfVqspCWF9FfZi3xQarlOtiYVarTZSsEhqxqHWR4XQV
+Bf8Shy3nAWUh6omyoy06lIRIXaZatEVOePT5JFHL4BDE42h8O3EI3sSEM3RU
+Zy63wYlKcYKXE0n892Vzvs5NieS9c8Ql4FINV0RPgbDn76KGDo2+Qp8MWNhi
+JTijio8nHa23d0BosdcnR6arvMio9qxXVnQs0tux7zrkYS+vBMKutJaUi42Y
+0bN20xJyO2fo0CcRXPzTyc/O135B+Rmpej+L/Dz4B5GfBz8xF+9S8w9/gb13
+qfiHP/He7/6DSO+7v4D07tJcfgnp3aW5fFJ6O1n7EeGNj3TJ7uC86zk3kK/z
+77t+ci2noY5vCplsKJ2iMw2Xo4QDXZMs2OhZiXdkdGRnquBVj3WHIUashiAI
+MU+3/bHBHif9XwXJ1uz/aILk1q6frtd/5Ow9jFSV66b/t73+I2f/Jxai/+JG
+6D8dK/es7wfwdM3XsuGbCBBi8b8yx3T2fzTm+HMyiJ2M2P/8lFr2r6z5V9b8
+L8SaTaun2eezZlgIsebLWNfujvFzNkCoMjRcue0+UHlZvgnli1L+HNJI2ncW
++VYrt3yG19SOMOFvR/46Jd35/p3d6erd18Fx+KSdCZt6ArEmT2JSqzVAlFZH
+935JWT1ncDSl2rse391zhZJRfnTaVsv7BgnF4qQOKnaO1iE9eeRSCZ8+0Erb
+TZMBwOjhtuV8I+QDdg2GjLKQy2vzvI436qGKPUTq9XRK10L8U1gudBPMLV+f
+Cccw0ONYNP58wvlIn7q6gvHPIpy79z7+Wfd+u2Pv459473d27j2KMf98LrBk
+760o984Yd+AnrVC3fBjCDLBT4sYn2l8rmSQ5il+b7omtb8lFrQnrQ7ZBqaaq
+54fA8ukl3VXjyyyxEnzjCre8Y77Fe0JdZS/hjX7gDx/6D1oXISXZa1O+WLei
+3lDZLGqOQZUvUdsMzgrkDXGmKHv+gbFPYV8YoKdO/AXdQLOia+2Ur3NLywSk
+1IxzhrHsLit8+cV045MEZ3QDLTPitRchW14jX8vi22G47lPuGsuBwlQCn0mQ
+nAbvy11phLmz7j5HHmtjKUma6s98YijIojV2nfmVJbdm/yEsef//Y5b80+79
+X4UlBxabcuXw+TZj9k1EfPI5Z95zGWjyvG9tFBeYhDZ4KrkhbavyqdehjQ5R
+hyc383YvqrTdh++t0qoVCXM9wH5mGafNh57qZvaXdR0p3S61lbndCm9y5HIc
+5vookdJynV9ZVmv2H6ZFHh60Xv877n03yzoKM/9CLOvoJ977bpZ1+xff++2f
+eO93d+79DmWM/1x772LX0Qr49U9q0MQDP0ON5iY27Rijohu7n5rVChk2XhWe
+zXys790Xi6ZZDZf87YfOy+Z85YVnwdSyQa7cuOGCV7oLW0+qzM63qxmSgGPS
+8qLWy+xqIY4Ayj7F27vsLDPS9gt7K5mVTwKlKCe6cnBTwHsfUy8stzX4LvgX
+SrqqfCAL8MNuEtkE76qkentHfy+dXohMIA3XoHHxAudPRRUCHXNPqRBBbg2l
+r3EoX2pZuqBsu2xXiihd70aMFPNQVOE4X+fYDkVt1dYGcGAxL/fA5Cr5Edhb
+8V1/rUvDotYrRu7WDMX1cn8a36NLa8HH6bJnbDYwAX3Bla5cnl5Q1Y1vMYZP
+90DZx5thsuk6N2y7sGcaljkFk6DP8OWrx+ID5XwtQqL4gpLCYskRgtchHLUX
+ZQiEu2ukvx7hG04o6NPRkbGOapvIPqRG3i49Gq+QoQW6anpG4VAUV7kOWC+R
+Jr61k0cnf3APg/LB3VdgoCtbYMoc7QeRF6+JpYETlKELarisr6TSWddHKq53
+x1RuQIDIcxiaLLfu8JF26ZhuxmCWzsBYRam4zw4sED2YUvOV9KuIGu65nmBY
+M42VRAvLR0MZ3ESMkjSXlGp+Eu2ENIEmcmokgCgb1oM1kJK95zv/Y4GjldyJ
+eEtw5KpVeVrtXNoDqq2j14/272kJh6E1z90SOrqUR0hAlvCS6mhhJ66C3jkU
+5OZbfwRT7mxH4EPuxf2yS3ftD5WZJg4F1QOhAIdQoRp+ND7Et4gisJy03+KD
+zJz4VuVPsz/P1FTC1DzD+wRjpFJBD4yQYtqUcChI+FKJzsaCOxjq8IkuXaE+
+xbeM+TwWAerS0yrxLy7UxqpB7oJ9TyVAcomQyCHwGYIR99TATmDdZ9szV4CJ
+A67L9VAloHYxId9FtiwiFMA7CxGsE/HHzBy7NYq5Jqz8lpyQb96jUle4x9mO
+a4yoPU8ux0tMDFeFV6JF/vdwAWZtl1QMUvsb2wmjEHweBhyjYIpWLmAxtf4C
+VLyMce0DDyGiccM9Qagizd0/Se4uFTZHyIFXSQK504QLvnKDMlhz6piCcgH4
+QOG1CDw5hTdQ5ij3w1dsmVIGk+k8QSKmbEnYjV421XWvKneHcGKGpQy2ZmB/
+mN7R+KBZVMQN3e3WqOakC+cavR1EG7GM6MYBTUlcrv65HqjQ1xNW7mDu5WEV
+/Gqebzb1A+k+4S/R2AZYXJxLh1Y6UpTWTlH3rgA9dG2ChoGXG3KtrrwTML5D
+tI6UtALx50O3mWHjCQnQUNax408Titw59Yw3otzRSDNQukw1z94gHrKLkbUr
+D+qRShq4bW01o9TrNTXC8edOKePGnYDU1PLAwnFc3xNuaoDYEBo9BsBqly+v
+/K1GjqPSFcXYq0Gdnzw7aanbXeq1FDTPKjNvcLY6TQF09bf+qswycEmp5Zab
+MuE8r2DXwOHL+Y5em8d4ASk/rqN7R194D4y/YTS6YjS+RVTuAJVbQCU8916/
+e/dvL8+ePP7wIXx/X0c3i8bfo4XTmIm7AtQvWsybaGPxFaCfAFJXd2aG0Qv3
+zSn55T8TRviwxutXfeFbp+XXAbnj9qWrWz/b8Bwf3oGxiIHs7C2xA4pu40Pc
+eDcwUwgQMF9a4H84/qfRk1H0gq6M4c7iXN5fOtHkb9/zfApZmcQLlFSa4JvX
+6xzVXepFk2EBH9/tGOoTKmo9mLQiiZuAU5+JBtvbVI5bUkQEmym8XeUlXu8O
+gpEZ5SxznQ/hjzmbJk5To6DQekrabSO9CJWhOzupBsWFZMKO0tD6SF3wo5F5
+iAuizqXUJ0saxLhoCfXbw7vAYWKMXrNBhRXj1ZpC+TM4YGHemxqvYHwg3PfF
+2enzp0/Pnj06eyRSiExkfk21X9O980cv++5Bk2++t/WuTaQ3pk023FY3bUWe
+GurYKojaFXoMkHbtu2bwYgH4flWiHlS7roJhcsq8uLbuLmB3KQNlS6DUBHV6
+wfdOzWb+GRWeMQV37MfnqA0AtzCPh5eHfUMSlAbS4ynoNa6zKPoW2MyULof+
+CVKiYYPh0k9sM1SiAVdWs2BgwhngEWAHnaRKB1EEm9PwLPQYyaPaWqfW3SxK
+WN8qm4L+al3vCWzHUEtzPeM62pBaG1UE0UjnF61+ULgZVFhqGz58IFfTu8ge
+cFO8x2Fm6ImcCsxuuHebZwwjdyttOPuI3jPpSn8FQHd9zskOQLKgJiSh2Njd
+iVQLB1KmrstpJs0zots23I0ofhZ/vcSa3Q5RSoxyo2nAMXj5gffty006rkcM
+yfp1gXort2QPTaaJHp2XKjKhC74Rgu+29e+5VY0U3UnMWTqzFGrUKwZvm+L1
++jXi1YpAZuXGzgYKzJ9b5HmoF65FRasVE24y7a8zgC3krsdKe/So90jt/Eys
+vFHkWQ7Q9dp3vZtwq+tiXZOvJ3QOEgu/AaysKEit1FNgrFesGr1wR3P2dgEq
+Go1zIjj67oulf3Bo/fdDweGdLcpbP0qdCisNjk4vMCS8v57aiM4I+yj07PQ1
+ClTD8cqngIQFmHmLMpSlJ9X3jKgA6ma41RJRhcY9UXPDQBQeIaMcrYhQXPs7
+1/aujFcrzKTa7GohLnYiUr9cLWGxKhNYLIX3a3EiUK/SbCrdojgzKnZx+Rwt
+n/hAbbYAk2FlS4t7zuqlTCbgNTuAyw8BllBSBeVpoPmFvZXQubNeuafxruaq
+WRck+blbrC1Agg7L+dCtV1ADpIZ4yiSuRxq1JBVExO+hFLALu/EwrtPqlEtB
+wI6cJDTxD9ePVj0ENT/08OfUixl19iPoCPqKU4ptELO9bEW8MAfFi3tbhx6S
+4WLnWVXeFOIUgLWwwKIlDp2d4Z0BohZRzxjf2cr5DoVJNP5OzKRJagJk1T4q
+Zn0tKAh1+JalIQwcZDYQ/QXzEe6TGssXlnAGrfZp3JaQ7mEhG87kYJFhByxq
++uvyZlBtpXNcGD+K9xrIGLDenC6F67Xl2kB9vA9i320rZKewfRgtVPF7wVXi
+UNl3HkaARVhQVn48WhYPULvbFAMHjiRaNKqX/A7L/Q3gjCMEdFD2l9yeDFe6
+CW4A5NdvrF0ZNMYjKlU7T8BBlkHIa0WPtGASdst1jlYiVyRWYGRr0JKIZhhp
+JrQG0ZQRfXvT+ahlbaHdwk2flBP7oYczbBv7lpFSgBlH29XltfSQw2tSZhl3
+SiQTPsFtcgVkC1R1sIfWuiD1jHyU4s0QWKUi6gRvE/UtdDuFk4kf+Xz5pHaY
+j+h5mK5rf/3YuqaLEbgDJ1qdpH3ZYjakHq3MDKkZOkAhWa3HFHWSOEURm6jJ
+KUPGLCk3ASVN8jocmKAm62uoj4r1hDzI+dO5ledOkSPV91HzT87hcD2utP6W
+5UkmvMSFwcb7+3z3sx97QJ8O5TO54gYdvOIhFzy45x9xeXiSz5HUzvedn4q9
+rOP98Z30tUFQxiZUFS8WH4MsBpS/DhUM45O0aee2RQzYtfa3lXijwZXts38i
+89mJuCs4ckEJAqgXvzvQx6ybRVlJW7jrzID0KdBOf3Gmvv1aRyONODkbPdx4
+I66/eA8O9+ssh7fg+zy34jTne2zBzPt9DixMfwMG7Bt0IJ8uTIWR2gtg1zZc
+DQvUCBurkdkAUTZlhdYucicibxJ5rs+mSvLRHRAGHA/2HegJ7Lw1vQAdFceg
+mNa0JO+icpJBRqO0GnSQoLNQqW8y7GCJngDOOH/3BTVEbLYC1kr1yFNk3NW5
+3N50ZtGH4hsnvHh8KvtCT91JQZ01MryssGsvLA587JftYXITXW5W6Jg5vXXm
+HELsU3uPdyRi56T3+oktruDE0ZfE7RZd1H/bXfRV69+OXxK3kR4f4uQgdAgw
+4m+Df/EGYVrNeHioH+Iv+7qHFwrTxa59eFupVt/cxMtI/vqamma45r05DC03
+TOxgfA/Q+4qnhU03am467/leVgfUotsy1P9dA1WOMUZ+sD8ej/iwwf6az5X6
+7f/BRIonMGP+LZjW9bEWm9U0BozMJZGDBnLAS4qwcy4oCNTGPmqbCeP9e9dA
+QQBFFRg6ShuO5OzLP/9x1zCt7r5bBdrUrA8zQbzK9ZkjcWdeyjuTts2tsXeN
+8xDsfF9eQhcJSuAZ/dD00v8CANnxsiCqAAA=
+
+-->
+
+</rfc>
+