<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- [CS] updated by Chris 03/10/21 -->

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lpwan-coap-static-context-hc-19" category="std"> number="8824" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortRefs="true"
tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="LPWAN CoAP compression">LPWAN Static abbrev="SCHC for CoAP">Static Context Header Compression (SCHC) for CoAP</title> the Constrained&nbsp;Application&nbsp;Protocol&nbsp;(CoAP)</title>

    <seriesInfo name="RFC" value="8824"/>
    <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
      <organization>Acklio</organization>
      <address>
        <postal>
          <street>1137A avenue des Champs Blancs</street>
          <city>35510 Cesson-Sevigne
          <city>Cesson-Sevigne Cedex</city>
	  <code>35510</code>
          <country>France</country>
        </postal>
        <email>ana@ackl.io</email>
      </address>
    </author>
    <author initials="L." surname="Toutain" fullname="Laurent Toutain">
      <organization>Institut
      <organization abbrev="IMT Atlantique">Institut MINES TELECOM; IMT Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street> <street>CS 17607</street>
          <city>35576 Cesson-Sevigne
	  <extaddr>CS 17607</extaddr>
          <city>Cesson-Sevigne Cedex</city>
          <code>35576</code>
          <country>France</country>
        </postal>
        <email>Laurent.Toutain@imt-atlantique.fr</email>
      </address>
    </author>

    <author initials="R." surname="Andreasen" fullname="Ricardo Andreasen">
      <organization>Universidad de Buenos Aires</organization>
      <address>
        <postal>
          <street>Av. Paseo Colon 850</street>
          <city>C1063ACV Ciudad
          <city>Ciudad Autonoma de Buenos Aires</city>
          <code>C1063ACV</code>
          <country>Argentina</country>
        </postal>
        <email>randreasen@fi.uba.ar</email>
      </address>
    </author>
    <date year="2021" month="March" day="08"/>

    <workgroup>lpwan Working Group</workgroup> month="June"/>

<keyword>header compression</keyword>
<keyword>fragmentation</keyword>
<keyword>IoT</keyword>
<keyword>constrained networks</keyword>
<keyword>LPWAN</keyword>
<keyword>sensor network</keyword>
<keyword>constrained node</keyword>
<keyword>wireless sensor network</keyword>
<keyword>core</keyword>
<keyword>OSCORE</keyword>

    <abstract>
      <t>This draft document defines how to compress the Constrained Application Protocol (CoAP) headers using the Static Context Header Compression (SCHC). and fragmentation (SCHC) framework.
   SCHC is defines a header compression mechanism adapted for Constrained Devices.
   SCHC uses a static description of the header to reduce the header’s header's redundancy and size.
   While RFC 8724 describes the SCHC compression and fragmentation framework,
   and its application for IPv6/UDP headers, this document applies SCHC for to CoAP headers. The CoAP header structure differs from
   IPv6 and UDP UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP protocol
   messages message format is asymmetric: the request messages have a header format different from the one format in the response messages.
 This
   specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction">

<t>CoAP numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Constrained Application Protocol (CoAP) <xref target="RFC7252"/> target="RFC7252" format="default"/> is a command/response protocol designed for micro-controllers microcontrollers with a small RAM and ROM and optimized for REST-based (Representative state transfer) services. services based on REST (Representational State Transfer). Although the Constrained Devices leads are a leading factor in the CoAP design, design of CoAP, a CoAP header’s header's size is still too large for LPWAN (Low Power Wide Area LPWANs (Low-Power Wide-Area Networks).
SCHC header compression Static Context Header Compression and fragmentation (SCHC) over CoAP header headers is required to increase performance or to use CoAP over LPWAN technologies.</t>

<t>The <xref target="RFC8724"/> technologies.
</t>
      <t><xref target="RFC8724" format="default"/> defines SCHC, the SCHC framework, which includes a header compression mechanism for the LPWAN network LPWANs that is based on a static context. Section 5 of the
<xref target="RFC8724"/> target="RFC8724" sectionFormat="of" section="5"/> explains where compression and decompression occur in the architecture. The SCHC compression scheme assumes as a prerequisite that both end-points endpoints know the static context before transmission. The way the context is configured, provisioned, or exchanged is out of this document’s document's scope.</t>
      <t>CoAP is an application protocol, so CoAP compression requires installing common Rules between the two SCHC instances. SCHC compression may apply at two different levels: at IP and UDP in the LPWAN network and another at the application level for CoAP. These two compressions compression techniques may be independent. Both follow the same principle as that described in <xref target="RFC8724"/>. target="RFC8724" format="default"/>. As different entities manage the CoAP compression process at different levels, the SCHC Rules driving the compression/decompression are also different. The <xref target="RFC8724"/> target="RFC8724" format="default"/> describes how to use SCHC for IP and UDP headers.       This document specifies how to apply SCHC compression to CoAP headers.</t>
      <t>SCHC compresses and decompresses headers based on common contexts between Devices. The SCHC context includes multiple Rules. Each Rule can match the header fields to specific values or ranges of values. If a Rule matches, the matched header fields are replaced by the RuleID and the Compression Residue that contains the residual bits of the compression. Thus, different Rules may correspond to different protocol headers in the packet that a Device expects to send or receive.</t>
      <t>A Rule describes the packets’ packets' entire header with an ordered list ordered list of fields descriptions; Field Descriptors; see section 7 of <xref target="RFC8724"/>. Thereby each description target="RFC8724" sectionFormat="of" section="7"/>. Thereby, each description contains the field Field ID (FID), its length Field Length (FL), and its position Field Position (FP), as well as a direction indicator Direction Indicator (DI) (upstream, downstream, and bidirectional), and bidirectional) and some associated Target Values (TV). (TVs). The direction indicator DI is used for compression to give the best TV to the FID when these values differ in the their transmission direction. So So, a field may be described several times.</t>
      <t>A Matching Operator (MO) is associated with each header field description. Field Descriptor. The Rule is selected if all the MOs fit the TVs for all fields of the incoming header.
A Rule cannot be selected if the message contains an unknown a field that is unknown to the SCHC compressor.</t>
      <t>In that case, a Compression/Decompression Action (CDA) associated with each field gives the method to compress and decompress each field.
Compression mainly results in one of 4 four actions:</t>

<t><list style="symbols">
  <t>send
      <ul spacing="normal">
        <li>send the field value (value-sent),</t>
  <t>send (value-sent),</li>
        <li>send nothing (not-sent),</t>
  <t>send (not-sent),</li>
        <li>send some least significant bits Least Significant Bits (LSBs) of the field (LSB) or,</t>
  <t>send field, or</li>
        <li>send an index (mapping-sent).</t>
</list></t> (mapping-sent).</li>
      </ul>
      <t>After applying the compression, there may be some bits to be sent.
These values are called Compression Residue.</t> "Compression Residue".</t>
      <t>SCHC is a general mechanism applied to different protocols, with the exact Rules to be used depending on the protocol and the Application.<vspace />
Section 10 of the application. <xref target="RFC8724"/> target="RFC8724" sectionFormat="of" section="10"/> describes the compression scheme for IPv6 and UDP headers. This document targets the CoAP header compression using SCHC.</t>
      <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
       <t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and
“OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC2119"/><xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="schc-applicability-to-coap" title="SCHC numbered="true" toc="default">
      <name>SCHC Applicability to CoAP"> CoAP</name>
      <t>SCHC Compression compression for CoAP header MAY headers <bcp14>MAY</bcp14> be done in conjunction with the lower layers (IPv6/UDP) or independently. The SCHC adaptation layers, described in Section 5 of <xref target="RFC8724"/>, target="RFC8724" sectionFormat="of" section="5"/>, may be used as shown in Figures&nbsp;<xref target="Fig-SCHCCOAP1" format="counter"/>, <xref target="Fig-SCHCCOAP1"/>, <xref target="Fig-SCHCCOAP2"/>, target="Fig-SCHCCOAP2" format="counter"/>, and <xref target="Fig-SCHCCOAP3"/>.</t> target="Fig-SCHCCOAP3" format="counter"/>.</t>
      <t>In the first example, <xref target="Fig-SCHCCOAP1"/>, target="Fig-SCHCCOAP1" format="default"/>, a Rule compresses the complete header stack from IPv6 to CoAP.  In this case, the Device and the NGW Network Gateway (NGW) perform SCHC C/D (Static Context Header Compression Compressor/Decompressor). (SCHC Compression/Decompression; see <xref target="RFC8724"/>). The Application application communicating with the Device does not implement SCHC C/D.</t>
      <figure title="Compression/Decompression anchor="Fig-SCHCCOAP1">
        <name>Compression/Decompression at the LPWAN boundary." anchor="Fig-SCHCCOAP1"><artwork><![CDATA[ Boundary</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
      (Device)            (NGW)                              (App)

      +--------+                                           +--------+
      |  CoAP  |                                           |  CoAP  |
      +--------+                                           +--------+
      |  UDP   |                                           |  UDP   |
      +--------+     +----------------+                    +--------+
      |  IPv6  |     |      IPv6      |                    |  IPv6  |
      +--------+     +--------+-------+                    +--------+
      |  SCHC  |     |  SCHC  |       |                    |        |
      +--------+     +--------+       +                    +        +
      |  LPWAN |     | LPWAN  |       |                    |        |
      +--------+     +--------+-------+                    +--------+
          ((((LPWAN))))             ------   Internet  ------
]]></artwork></figure>
]]></artwork>
      </figure>
      <t><xref target="Fig-SCHCCOAP1"/> target="Fig-SCHCCOAP1" format="default"/> shows the use of SCHC header compression above layer Layer 2 in the Device and the NGW. The SCHC layer receives non-encrypted packets and can apply compression Rules to all the headers in the stack. On the other end, the NGW receives the SCHC packet and reconstructs the headers using the Rule and the Compression Residue. After the decompression, the NGW forwards the IPv6 packet toward the destination. The same process applies in the other direction when a non-encrypted packet arrives at the NGW. Thanks to the IP forwarding based on the IPv6 prefix, the NGW identifies the Device and compresses headers using the Device’s Device's Rules.</t>
      <t>In the second example, <xref target="Fig-SCHCCOAP2"/>, the target="Fig-SCHCCOAP2" format="default"/>, SCHC compression is applied in the CoAP layer, compressing the CoAP header independently of the other layers. The RuleID, the Compression Residue, and CoAP payload are encrypted using a mechanism such as DTLS. Only the other end (App) can decipher the information. If needed, layers below use SCHC to compress the header as defined in <xref target="RFC8724"/> target="RFC8724" format="default"/> (represented in by dotted lines).</t> lines in the figure).</t>
      <t>This use case needs an end-to-end context initialization between the Device and the Application. application. The context initialization is out of the scope of for this document.</t>
      <figure title="Standalone anchor="Fig-SCHCCOAP2">
        <name>Standalone CoAP end-to-end Compression/Decompression" anchor="Fig-SCHCCOAP2"><artwork><![CDATA[ End-to-End Compression/Decompression</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
      (Device)            (NGW)                               (App)

      +--------+                                           +--------+
      |  CoAP  |                                           |  CoAP  |
      +--------+                                           +--------+
      |  SCHC  |                                           |  SCHC  |
      +--------+                                           +--------+
      |  DTLS  |                                           |  DTLS  |
      +--------+                                           +--------+
      .  udp   .                                           .  udp   .
      ..........     ..................                    ..........
      .  ipv6  .     .      ipv6      .                    .  ipv6  .
      ..........     ..................                    ..........
      .  schc  .     .  schc  .       .                    .        .
      ..........     ..........       .                    .        .
      .  lpwan .     . lpwan  .       .                    .        .
      ..........     ..................                    ..........
          ((((LPWAN))))             ------   Internet  ------

]]></artwork></figure>
]]></artwork>
      </figure>
      <t>The third example, <xref target="Fig-SCHCCOAP3"/>, target="Fig-SCHCCOAP3" format="default"/>, shows the use of Object Security for Constrained RESTful Environments (OSCORE) <xref target="RFC8613"/>. target="RFC8613" format="default"/>. In this case, SCHC needs two Rules to compress the CoAP header. A first Rule focused focuses on the inner Inner header. The result of this first compression is encrypted using the OSCORE mechanism. Then Then, a second Rule compresses the outer Outer header, including the OSCORE Options.</t> options.</t>
      <figure title="OSCORE compression/decompression." anchor="Fig-SCHCCOAP3"><artwork><![CDATA[ anchor="Fig-SCHCCOAP3">
        <name>OSCORE Compression/Decompression</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
      (Device)            (NGW)                              (App)

      +--------+                                           +--------+
      |  CoAP  |                                           |  CoAP  |
      |  inner  Inner |                                           |  inner  Inner |
      +--------+                                           +--------+
      |  SCHC  |                                           |  SCHC  |
      |  inner  Inner |                                           |  inner  Inner |
      +--------+                                           +--------+
      |  CoAP  |                                           |  CoAP  |
      |  outer  Outer |                                           |  outer  Outer |
      +--------+                                           +--------+
      |  SCHC  |                                           |  SCHC  |
      |  outer  Outer |                                           |  outer  Outer |
      +--------+                                           +--------+
      .  udp   .                                           .  udp   .
      ..........     ..................                    ..........
      .  ipv6  .     .      ipv6      .                    .  ipv6  .
      ..........     ..................                    ..........
      .  schc  .     .  schc  .       .                    .        .
      ..........     ..........       .                    .        .
      .  lpwan .     . lpwan  .       .                    .        .
      ..........     ..................                    ..........
          ((((LPWAN))))             ------   Internet  ------

]]></artwork></figure>
]]></artwork>
      </figure>
      <t>In the case of several SCHC instances, as shown in <xref target="Fig-SCHCCOAP2"/> Figures&nbsp;<xref target="Fig-SCHCCOAP2" format="counter"/> and <xref target="Fig-SCHCCOAP3"/>, target="Fig-SCHCCOAP3" format="counter"/>, the Rules may come from different provisioning domains.</t>
      <t>This document focuses on CoAP compression compression, as represented in by the dashed boxes in the previous figures.</t>
    </section>
    <section anchor="coap-headers-compressed-with-schc" title="CoAP numbered="true" toc="default">
      <name>CoAP Headers compressed Compressed with SCHC"> SCHC</name>
      <t>The use of SCHC over the CoAP header uses applies the same description, description and compression/decompression techniques like as the one technique used for IP and UDP UDP, as explained in the <xref target="RFC8724"/>. target="RFC8724" format="default"/>. For CoAP, the SCHC Rules description uses the direction information to optimize the compression by reducing the number of Rules needed to compress headers. The field description MAY Field Descriptor <bcp14>MAY</bcp14> define both request/response headers and target values TVs in the same Rule, using the DI (direction indicator) to make indicate the difference.</t> header type.
</t>
      <t>As for other header compression protocols, when the compressor does not find a correct Rule to compress the header, the packet MUST <bcp14>MUST</bcp14> be sent uncompressed using the RuleID dedicated to this purpose. Where purpose, and where the Compression Residue is the complete header of the packet. See section 6 of <xref target="RFC8724"/>.</t> target="RFC8724" sectionFormat="of" section="6"/>.
</t>
      <section anchor="differences-between-coap-and-udpip-compression" title="Differences numbered="true" toc="default">
        <name>Differences between CoAP and UDP/IP Compression"> Compression</name>
        <t>CoAP compression differs from IPv6 and UDP compression in the following aspects:</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>The CoAP protocol message format is asymmetric; the headers are different for a request or a response.
For example, the URI-Path Uri-Path option is mandatory in the request, and it might not be present in the response.
A request might contain an Accept option, and the response might include a Content-Format option.
In comparison, the IPv6 and UDP returning path swap swaps the value of some fields in the header. However, all the directions have the same fields (e.g., source and destination address fields).  <vspace blankLines='1'/>
The  </t>
            <t>
<xref target="RFC8724"/> target="RFC8724" format="default"/> defines the use of a direction indicator (DI) DI in the
Field Descriptor, which allows a single Rule to process a message
header differently differently, depending on the direction.</t>
  <t>Even
          </li>
          <li>Even when a field is “symmetric” "symmetric" (i.e., found in both directions), the values carried in each direction are different.
The compression may use a “match-mapping” "match-mapping" MO to limit the range of expected values
in a particular direction and reduce the Compression Residue’s Residue's size.
Through the direction indicator (DI), DI, a field description Field Descriptor in the Rules splits the possible field value into two parts,
one for each direction. For instance, if a client sends only CON requests, Confirmable (CON) requests <xref target="RFC7252"/>, the Type can be elided by compression,
and the answer may use one single bit to carry either the ACK or RST Reset (RST) type.
The field Code has the same behavior, behavior: the 0.0X code format value in the request, request and the Y.ZZ code format in the response.</t> response.
</li>
          <li>
            <t>In SCHC, the Rule defines the different header fields’ fields' length, so SCHC does not need to send it.
In IPv6 and UDP headers, the fields have a fixed size, known by definition.
On the other hand, some CoAP header fields have variable lengths, and the Rule description specifies it.
For example, in a URI-path Uri-Path or URI-query, Uri-Query, the Token size may vary from 0 to 8 bytes,
and the CoAP options use the Type-Length-Value encoding format.  <vspace blankLines='1'/>  </t>
            <t>
When doing SCHC compression of a variable-length field,
Section 7.5.2 from
<xref target="RFC8724"/> target="RFC8724" sectionFormat="of" section="7.4.2"/> offers the possibility to define option of defining a function for the Field length Length in the Field Description Descriptor to know the length before compression. If the field length Field Length is unknown, the Rule will set it as a variable, and SCHC will send the compressed field’s field's length in the Compression Residue.</t>
  <t>A
          </li>
          <li>A field can appear several times in the CoAP headers.
It is found typically for elements of a URI (path or queries).
The SCHC specification <xref target="RFC8724"/> target="RFC8724" format="default"/> allows a Field ID FID to appear several times in the Rule
and uses the Field Position (FP) to (FP) to identify the correct instance, thereby removing the matching operation’s ambiguity.</t>
  <t>Field lengths removing the MO's ambiguity.</li>
          <li>Field Lengths defined in the CoAP protocol can be too large regarding large when it comes to LPWAN traffic constraints.
For instance, this is particularly true for true for the Message-ID field Message ID field and the Token field.
SCHC uses different Matching operators (MO) different MOs to perform the compression. See section 7.4 of
<xref target="RFC8724"/>. target="RFC8724" sectionFormat="of" section="7.4"/>.
In this case, SCHC can apply the Most Significant Bits (MSB) (MSBs) MO to reduce the information carried on LPWANs.</t>
</list></t> LPWANs.</li>
        </ul>
      </section>
    </section>
    <section anchor="CoAPcomp" title="Compression numbered="true" toc="default">
      <name>Compression of CoAP header fields"> Header Fields</name>
      <t>This section discusses the compression of the different CoAP header fields. The  CoAP compression with SCHC follows Section 7.1 of the information provided in <xref target="RFC8724"/>.</t> target="RFC8724" sectionFormat="of" section="7.1"/>.</t>
      <section anchor="coap-version-field" title="CoAP version field">

<t>CoAP numbered="true" toc="default">
        <name>CoAP Version Field</name>
        <t>The CoAP version is bidirectional and MUST <bcp14>MUST</bcp14> be elided during the  SCHC compression compression, since it always contains the same value.
In the future, or if a new version of CoAP is defined, new Rules will be needed to avoid ambiguities between versions.</t>
      </section>
      <section anchor="coap-type-field" title="CoAP type field">

<t>The CoAP protocol numbered="true" toc="default">
        <name>CoAP Type Field</name>
        <t>CoAP <xref target="RFC7252"/> target="RFC7252" format="default"/> has four types of messages: two requests (CON, NON), one response (ACK), and one empty message (RST).</t>
        <t>The SCHC compression SHOULD scheme <bcp14>SHOULD</bcp14> elide this field if, for instance, a client is sending only NON Non-confirmable (NON) messages or only CON messages.
For the RST message, SCHC may use a dedicated Rule. For other usages, SCHC can use a “match-mapping” "match-mapping" MO.</t>
      </section>
      <section anchor="coap-code-field" title="CoAP code field"> numbered="true" toc="default">
        <name>CoAP Code Field</name>
        <t>The code field is Code field, defined in an IANA registry <xref target="RFC7252"/>, and it target="RFC7252" format="default"/>, indicates the Request Method used in CoAP.
 The compression of the CoAP code Code field follows the same principle as that of the CoAP type Type field. If the Device plays a specific role, SCHC may split the code values into two fields description, Field Descriptors: (1) the request codes with the 0 class and (2) the response values. SCHC will use the direction indicator DI to identify the correct value in the packet.</t>
        <t>If the Device only implements a CoAP client, SCHC compression may reduce the request code to the set of requests the client can process.</t>
        <t>For known values, SCHC can use a “match-mapping” "match-mapping" MO. If SCHC cannot compress the code Code field, it will send the values in the Compression Residue.</t>
      </section>
      <section anchor="coap-message-id-field" title="CoAP numbered="true" toc="default">
        <name>CoAP Message ID field"> Field</name>
        <t>SCHC can compress the Message ID field with the “MSB” "MSB" MO and the “LSB” "LSB" CDA.
See section 7.4 of <xref target="RFC8724"/>.</t> target="RFC8724" sectionFormat="of" section="7.4"/>.</t>
      </section>
      <section anchor="coap-token-fields" title="CoAP numbered="true" toc="default">
        <name>CoAP Token fields"> Fields</name>
        <t>CoAP defines the Token using two CoAP fields, fields: Token Length in the
 mandatory header and Token Value directly following the mandatory
 CoAP header.</t> header.
</t>
        <t>SCHC processes the Token length Length as it would any header field. If the value does not change, the size can be stored in the TV and elided during the transmission. Otherwise, SCHC will send the token length Token Length in the Compression Residue.</t>
        <t>For the Token Value, SCHC MUST NOT <bcp14>MUST NOT</bcp14> send it as a
variable-length data in the Compression Residue Residue, to avoid ambiguity with the Token Length. Therefore, SCHC MUST <bcp14>MUST</bcp14> use the Token length Length value to define the size of the Compression Residue. SCHC designates a specific function “tkl” function, "tkl", that the Rule MUST <bcp14>MUST</bcp14> use to complete the field description. Field Descriptor. During the decompression, this function returns the value contained in the Token Length field.</t>
      </section>
    </section>
    <section anchor="coap-options" title="CoAP options"> numbered="true" toc="default">
      <name>CoAP Options</name>
      <t>CoAP defines options placed after the basic header in Option Numbers order; header, ordered by option number; see <xref target="RFC7252"/>. target="RFC7252" format="default"/>. Each Option instance in a message uses
the format Delta-Type (D-T), Length (L), Value (V). The SCHC Rule builds the description of the option by using in the Field ID following:</t>

<ul spacing="normal">
<li>in the Option Number FID: the option number built from D-T; in TV, the Option Value; and D-T;</li>
<li>in the TV: the option value; and</li>
<li>for the Option Length uses section 7.4 Length: the information provided in Sections&nbsp;<xref target="RFC8724" section="7.4.1" sectionFormat="bare"/> and <xref target="RFC8724" section="7.4.2" sectionFormat="bare"/> of <xref target="RFC8724"/>. When target="RFC8724"/>.</li>
</ul>

<t>When the Option Length has a well-known size, the Rule may keep the length value. Therefore, SCHC compression does not send it. Otherwise, SCHC Compression compression carries the length of the Compression Residue, in addition to the Compression Residue value.</t>
      <t>CoAP requests and responses do not include the same options. So Compression So, compression Rules may reflect this asymmetry by tagging the direction indicator.</t> DI.</t>
      <t>Note that length coding differs between CoAP options and SCHC variable size Compression Residue.</t>
      <t>The following sections present how SCHC compresses some specific CoAP options.</t>
      <t>If CoAP introduces a new option, the SCHC Rules MAY <bcp14>MAY</bcp14> be updated, and the new Field ID FID description MUST <bcp14>MUST</bcp14> be assigned to allow its compression.
Otherwise, if no Rule describes this new option, the SCHC compression is not achieved, and SCHC sends the CoAP header without compression.</t>
      <section anchor="coap-content-and-accept-options" title="CoAP numbered="true" toc="default">
        <name>CoAP Content and Accept options."> Options</name>
        <t>If the client expects a single value, it can be stored in the TV and elided during the transmission.
Otherwise, if the client expects several possible values, a “match-mapping” SHOULD "match-mapping" MO  <bcp14>SHOULD</bcp14> be used to limit the Compression Residue’s Residue's size. If not, SCHC has to send the option value in the Compression Residue (fixed or variable length).</t>
      </section>
      <section anchor="coap-option-max-age-uri-host-and-uri-port-fields" title="CoAP option numbered="true" toc="default">
        <name>CoAP Option Max-Age, Uri-Host, and Uri-Port fields"> Fields</name>
        <t>SCHC compresses these three fields in the same way. When the value values of these options is are known, SCHC can elide these fields.
If the option uses well-known values, SCHC can use a “match-mapping” "match-mapping" MO. Otherwise, SCHC will use “value-sent” the "value-sent" MO, and the Compression Residue will send these options’ options' values.</t>
      </section>
      <section anchor="coap-option-uri-path-and-uri-query-fields" title="CoAP option numbered="true" toc="default">
        <name>CoAP Option Uri-Path and Uri-Query fields"> Fields</name>
        <t>The Uri-Path and Uri-Query fields are repeatable options; this means that in the CoAP header, they may appear several times with different values. The SCHC Rule description uses the Field Position (FP) FP to distinguish the different instances in the path.</t>
        <t>To compress repeatable field values, SCHC may use a “match-mapping” "match-mapping" MO to reduce the size of variable Paths paths or Queries. queries. In these cases, to optimize the compression, several elements can be regrouped into a single entry. The Numbering numbering of elements does not change, and the first matching element sets the MO comparison.</t>

<figure title="complex path example" anchor="Fig--complex-path"><artwork><![CDATA[
   +--------+---+--+--+--------+-------------+------------+
   | Field  |FL |FP|DI| Target |  Matching   |     CDA    |
   |        |   |  |  | Value  |  Operator   |            |
   +--------+---+--+--+--------+-------------+------------+
   |Uri-Path|   | 1|up|["/a/b",|match-mapping|mapping-sent|
   |        |   |  |  |"/c/d"] |             |            |
   |Uri-Path|var| 3|up|        |ignore       |value-sent  |
   +--------+---+--+--+--------+-------------+------------+

]]></artwork></figure>

        <t>In <xref target="Fig--complex-path"/>, target="Table-complex-path" format="default"/>, SCHC can use a single bit in the Compression Residue to code one of the two paths.
If regrouping were not allowed, 2 bits in the Compression Residue would be needed. SCHC sends the third path element as a variable size in the Compression Residue.</t>

<table anchor="Table-complex-path">
  <name>Complex Path Example</name>
  <thead>
    <tr>
      <th align="center">Field</th>
      <th align="center">FL</th>
      <th align="center">FP</th>
      <th align="center">DI</th>
      <th align="center">TV</th>
      <th align="center">MO</th>
      <th align="center">CDA</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Uri-Path</td>
      <td></td>
      <td>1</td>
      <td>Up</td>
      <td>["/a/b",&br;"/c/d"]</td>
      <td>match-&br;mapping</td>
      <td>mapping-sent</td>
    </tr>
    <tr>
      <td>Uri-Path</td>
      <td>var</td>
      <td>3</td>
      <td>Up</td>
      <td></td>
      <td>ignore</td>
      <td>value-sent</td>
    </tr>
  </tbody>
</table>

        <t>The length of URI-Path Uri-Path and URI-Query Uri-Query may be known when the rule Rule is defined. In any case, SCHC MUST <bcp14>MUST</bcp14> set the field length Field Length to variable. a variable value. The unit to indicate the Compression Residue size is expressed in Byte.</t> bytes.</t>
        <t>SCHC compression can use the MSB MO to a Uri-Path or Uri-Query element. However, attention to the length is important because the MSB value is in bits, and the size MUST <bcp14>MUST</bcp14> always be a multiple of 8 bits.</t>
        <t>The length sent at the beginning of a variable-length Compression Residue indicates the LSB’s LSB's size in bytes.</t>
        <t>For instance, for a CORECONF path /c/X6?k=”eth0” /c/X6?k=eth0, the Rule description can be:</t>

<figure title="CORECONF be as follows (<xref target="Table-CoMicompress"/>):</t>

<table anchor="Table-CoMicompress">
  <name>CORECONF URI compression" anchor="Fig-CoMicompress"><artwork><![CDATA[
   +-------------+---+--+--+--------+---------+-------------+
   | Field       |FL |FP|DI| Target | Match   |     CDA     |
   |             |   |  |  | Value  | Opera.  |             |
   +-------------+---+--+--+--------+---------+-------------+
   |Uri-Path     |   | 1|up|"c"     |equal    |not-sent     |
   |Uri-Path     |var| 2|up|        |ignore   |value-sent   |
   |Uri-Query    |var| 1|up|"k=\""  |MSB(24)  |LSB          |
   +-------------+---+--+--+--------+---------+-------------+
]]></artwork></figure> Compression</name>
  <thead>
    <tr>
      <th align="center">Field</th>
      <th align="center">FL</th>
      <th align="center">FP</th>
      <th align="center">DI</th>
      <th align="center">TV</th>
      <th align="center">MO</th>
      <th align="center">CDA</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Uri-Path</td>
      <td></td>
      <td>1</td>
      <td>Up</td>
      <td>"c"</td>
      <td>equal</td>
      <td>not-sent</td>
    </tr>
    <tr>
      <td>Uri-Path</td>
      <td>var</td>
      <td>2</td>
      <td>Up</td>
      <td></td>
      <td>ignore</td>
      <td>value-sent</td>
    </tr>
    <tr>
      <td>Uri-Query</td>
      <td>var</td>
      <td>1</td>
      <td>Up</td>
      <td>"k="</td>
      <td>MSB(16)</td>
      <td>LSB</td>
    </tr>
  </tbody>
</table>

        <t><xref target="Fig-CoMicompress"/> target="Table-CoMicompress" format="default"/> shows the Rule description for a URI-Path Uri-Path and a URI-Query. Uri-Query. SCHC compresses the first part of the URI-Path Uri-Path with a “not-sent” "not-sent" CDA.
SCHC will send the second element of the URI-Path Uri-Path with the length (i.e., 0x2 X 6) "X6") followed by the query option (i.e., 0x05 eth0”).</t> 0x4 "eth0").
</t>
        <section anchor="variable-number-of-path-or-query-elements" title="Variable number numbered="true" toc="default">
          <name>Variable Number of Path or Query elements"> Elements</name>
          <t>SCHC fixed the number of Uri-Path or Uri-Query elements in a Rule at
the Rule creation time. If the number varies, SCHC SHOULD create <bcp14>SHOULD</bcp14> either</t>
<ul spacing="normal">
<li>create several Rules to cover all the possibilities.
Another one is to define the length of possibilities or</li>
<li>create a Rule that defines several entries for Uri-Path to variable cover the longest path and sends send a Compression Residue with a length of 0 to indicate that this a Uri-Path entry is empty. However, empty.</li>
</ul>
<t>However, this adds 4 bits to the variable Compression Residue size. See section 7.5.2
<xref target="RFC8724"/>.</t> target="RFC8724" sectionFormat="of" section="7.4.2"/>.</t>
        </section>
      </section>
      <section anchor="coap-option-size1-size2-proxy-uri-and-proxy-scheme-fields" title="CoAP option numbered="true" toc="default">
        <name>CoAP Option Size1, Size2, Proxy-URI Proxy-URI, and Proxy-Scheme fields"> Fields</name>

        <t>The SCHC Rule description MAY <bcp14>MAY</bcp14> define sending some field values by setting the TV to “not-sent,” "not-sent", the MO to “ignore,” "ignore", and the CDA to “value-sent.” "value-sent". A Rule MAY <bcp14>MAY</bcp14> also use a “match-mapping” "match-mapping" MO when there are different options for the same FID. Otherwise, the Rule sets the TV to the value, the MO to “equal,” "equal", and the CDA to “not-sent.”</t> "not-sent".</t>
      </section>
      <section anchor="coap-option-etag-if-match-if-none-match-location-path-and-location-query-fields" title="CoAP option numbered="true" toc="default">
        <name>CoAP Option ETag, If-Match, If-None-Match, Location-Path, and Location-Query fields"> Fields</name>
        <t>A Rule entry cannot store these fields’ fields' values. The Rule description MUST <bcp14>MUST</bcp14> always send these values in the Compression Residue.</t>
      </section>
    </section>
    <section anchor="schc-compression-of-coap-extension-rfcs" title="SCHC compression numbered="true" toc="default">
      <name>SCHC Compression of CoAP extension RFCs"> Extensions</name>

      <section anchor="block" title="Block"> numbered="true" toc="default">
        <name>Block</name>
        <t>When a packet uses a Block option <xref target="RFC7959"/> option, target="RFC7959" format="default"/>, SCHC compression MUST <bcp14>MUST</bcp14> send its content in the Compression Residue.
The SCHC Rule describes an empty TV with a the MO set to “ignore” "ignore" and a the CDA set to “value-sent.” "value-sent".
The Block option allows fragmentation at the CoAP level that is compatible with SCHC fragmentation.
Both fragmentation mechanisms are complementary, and the node may use them for the same packet as needed.</t>
      </section>
      <section anchor="observe" title="Observe">

<t>The <xref target="RFC7641"/> numbered="true" toc="default">
        <name>Observe</name>
        <t><xref target="RFC7641" format="default"/> defines the Observe option. Option. The SCHC Rule description will not define the TV, TV but will set the MO to “ignore,” "ignore" and the CDA to “value-sent.” "value-sent". SCHC does not limit the maximum size for this option (3 bytes). To reduce the transmission size, either the Device implementation MAY <bcp14>MAY</bcp14> limit the delta between two consecutive values, values or a proxy can modify the increment.</t>
        <t>Since the Observe option MAY Option <bcp14>MAY</bcp14> use an a RST message to inform a server that the client does not require the Observe response, a specific SCHC Rule SHOULD <bcp14>SHOULD</bcp14> exist to allow the message’s message's compression with the RST type.</t>
      </section>
      <section anchor="no-response" title="No-Response">

<t>The <xref target="RFC7967"/> numbered="true" toc="default">
        <name>No-Response</name>
        <t><xref target="RFC7967" format="default"/> defines a No-Response option limiting the responses made by a server to a request. Different behaviors exist while using this option to limit the responses made by a server to a request. If both ends know the value, then the SCHC Rule will describe a TV to this value, with a the MO set to “equal” "equal" and the CDA set to “not-sent.”</t> "not-sent".</t>
        <t>Otherwise, if the value is changing over time, the SCHC Rule will set the MO to “ignore” "ignore" and the CDA to “value-sent.” "value-sent". The Rule may also use a “match-mapping” "match-mapping" MO to compress this option.</t>
      </section>
      <section anchor="Sec-OSCORE" title="OSCORE"> numbered="true" toc="default">
        <name>OSCORE</name>
        <t>OSCORE <xref target="RFC8613"/> target="RFC8613" format="default"/> defines end-to-end protection for CoAP messages.
This section describes how SCHC Rules can be applied to compress OSCORE-protected messages.</t>

<figure title="OSCORE Option" anchor="Fig-OSCORE-Option"><artwork><![CDATA[
      0 1 2 3 4 5 6 7 <--------- n bytes ------------->
     +-+-+-+-+-+-+-+-+---------------------------------
     |0 0 0|h|k|  n  |      Partial IV (if any) ...
     +-+-+-+-+-+-+-+-+---------------------------------
     |               |                                |
     |<--  CoAP   -->|<------ CoAP OSCORE_piv ------> |
        OSCORE_flags

      <- 1 byte -> <------ s bytes ----->
     +------------+----------------------+-----------------------+
     | s (if any) | kid context (if any) | kid (if any)      ... |
     +------------+----------------------+-----------------------+
     |                                   |                       |
     | <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->|

]]></artwork></figure>

<t>The <xref target="Fig-OSCORE-Option"/>

        <t><xref target="Fig-OSCORE-Option" format="default"/> shows the OSCORE Option Value option value encoding defined in Section 6.1 of
<xref target="RFC8613"/>, target="RFC8613" sectionFormat="of" section="6.1"/>, where the first byte specifies the Content content of the OSCORE options using flags. The three most significant bits of this byte are reserved and always set to 0. Bit h, when set, indicates the presence of the kid context field in the option. Bit k, when set, indicates the presence of a kid field. The three least significant bits n bits, n, indicate the length of the piv (Partial Initialization Vector) field in bytes. When n = 0, no piv is present.</t>

        <figure anchor="Fig-OSCORE-Option">
          <name>OSCORE Option</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      0 1 2 3 4 5 6 7 <--------- n bytes ------------->
     +-+-+-+-+-+-+-+-+---------------------------------
     |0 0 0|h|k|  n  |      Partial IV (if any) ...
     +-+-+-+-+-+-+-+-+---------------------------------
     |               |                                |
     |<--  CoAP   -->|<------ CoAP OSCORE_piv ------> |
        OSCORE_flags

      <- 1 byte -> <------ s bytes ----->
     +------------+----------------------+-----------------------+
     | s (if any) | kid context (if any) | kid (if any)      ... |
     +------------+----------------------+-----------------------+
     |                                   |                       |
     | <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->|
]]></artwork>
        </figure>
        <t>The flag byte is followed by the piv field, the kid context field, and the kid field field, in this that order, and and, if present,
the kid context field’s field's length (in bytes) is encoded in the first byte denoting byte, denoted by ‘s’ the length of the kid context in bytes.</t> "s".
</t>
        <t>To better perform OSCORE SCHC compression, the Rule description needs to identify the OSCORE Option option and the fields it contains. Conceptually, it discerns up to 4 four distinct pieces of information within the OSCORE option: the flag bits, the piv, the kid context, and the kid. The SCHC Rule splits into four field descriptions the OSCORE option into four Field Descriptors in order to compress them:</t>

<t><list style="symbols">
  <t>CoAP OSCORE_flags,</t>
  <t>CoAP OSCORE_piv,</t>
  <t>CoAP OSCORE_kidctx,</t>
  <t>CoAP OSCORE_kid.</t>
</list></t> them:
</t>
        <ul spacing="normal">
          <li>CoAP OSCORE_flags</li>
          <li>CoAP OSCORE_piv</li>
          <li>CoAP OSCORE_kidctx</li>
          <li>CoAP OSCORE_kid</li>
        </ul>
        <t><xref target="Fig-OSCORE-Option"/> target="Fig-OSCORE-Option" format="default"/> shows the OSCORE Option option format with those four fields superimposed on it.
Note that the CoAP OSCORE_kidctx field directly includes the size octet s.</t> octet, s.
</t>
      </section>
    </section>
    <section anchor="examples-of-coap-header-compression" title="Examples numbered="true" toc="default">
      <name>Examples of CoAP header compression"> Header Compression</name>
      <section anchor="mandatory-header-with-con-message" title="Mandatory header numbered="true" toc="default">
        <name>Mandatory Header with CON message"> Message</name>
        <t>In this first scenario, the SCHC Compressor at compressor on the Network Gateway NGW side
receives a POST message from an Internet client, which is immediately acknowledged by the Device.
<xref target="Fig-CoAP-header-1"/> target="Table-CoAP-header-1" format="default"/> describes the SCHC Rule descriptions for this scenario.</t>

<figure title="CoAP
<table anchor="Table-CoAP-header-1">
  <name>CoAP Context to compress header Compress Header without Token" anchor="Fig-CoAP-header-1"><artwork><![CDATA[
RuleID 1
+-------------+--+--+--+------+---------+-------------++------------+
| Field       |FL|FP|DI|Target| Match   |     CDA     ||    Sent    |
|             |  |  |  |Value | Opera.  |             ||   [bits]   |
+-------------+--+--+--+------+---------+-------------++------------+
|CoAP version | 2| 1|bi|  01  |equal    |not-sent     ||            |
|CoAP Type    | 2| 1|dw| CON  |equal    |not-sent     ||            |
|CoAP Type    | 2| 1|up|[ACK, |match-   |matching-    ||            |
|             |  |  |  | RST] |mapping  |sent         || T          |
|CoAP TKL     | 4| 1|bi| 0    |equal    |not-sent     ||            |
|CoAP Code    | 8| 1|bi|[0.00,|         |             ||            |
|             |  |  |  | ...  |match-   |matching-    ||            |
|             |  |  |  | 5.05]|mapping  |sent         ||  CC CCC    |
|CoAP MID     |16| 1|bi| 0000 |MSB(7 )  |LSB          ||        M-ID|
|CoAP Uri-Path|var 1|dw| path |equal 1  |not-sent     ||            |
+-------------+--+--+--+------+---------+-------------++------------+

]]></artwork></figure>

<t>In this example, SCHC compression elides the Token</name>
  <thead>
    <tr>
      <th align="left" colspan="8">RuleID 1</th>
    </tr>
    <tr>
      <th align="center">Field</th>
      <th align="center">FL</th>
      <th align="center">FP</th>
      <th align="center">DI</th>
      <th align="center">TV</th>
      <th align="center">MO</th>
      <th align="center">CDA</th>
      <th align="center">Sent [bits]</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>CoAP version</td>
      <td>2</td>
      <td>1</td>
      <td>Bi</td>
      <td>01</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Type</td>
      <td>2</td>
      <td>1</td>
      <td>Dw</td>
      <td>CON</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Type</td>
      <td>2</td>
      <td>1</td>
      <td>Up</td>
      <td>[ACK,&br;RST]</td>
      <td>match-mapping</td>
      <td>matching-sent</td>
      <th>T</th>
    </tr>
    <tr>
      <td>CoAP TKL</td>
      <td>4</td>
      <td>1</td>
      <td>Bi</td>
      <td>0</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Bi</td>
      <td>[0.00,&br;...&br;5.05]</td>
      <td>match-mapping</td>
      <td>matching-sent</td>
      <th>CC CCC</th>
    </tr>
    <tr>
      <td>CoAP MID</td>
      <td>16</td>
      <td>1</td>
      <td>Bi</td>
      <td>0000</td>
      <td>MSB(7)</td>
      <td>LSB</td>
      <th>MID</th>
    </tr>
    <tr>
      <td>CoAP Uri-Path</td>
      <td>var</td>
      <td>1</td>
      <td>Dw</td>
      <td>path</td>
      <td>equal 1</td>
      <td>not-sent</td>
      <th></th>
    </tr>
  </tbody>
</table>

        <t>In this example, SCHC compression elides the version and the Token Length fields. The 26 method 25 Method and response codes Response Codes defined in <xref target="RFC7252"/> has target="RFC7252" format="default"/> have been shrunk to 5 bits using a “match-mapping” "match-mapping" MO. The Uri-Path contains a single element indicated in the TV and elided with the CDA “not-sent.”</t> "not-sent".</t>
        <t>SCHC Compression compression reduces the header header, sending only the Type, a mapped code, and the least significant bits of the Message ID (9 bits in the example above).</t>
        <t>Note that a client located in an Application Server sending a request to a server located in the Device may not be compressed through this Rule Rule, since the MID might not start with 7 bits equal to 0. A CoAP proxy placed before the SCHC C/D can rewrite the message Message ID to fit the value and match the Rule.</t>
      </section>
      <section anchor="Sec-OSCORE-Examples" title="OSCORE Compression"> numbered="true" toc="default">
        <name>OSCORE Compression</name>
        <t>OSCORE aims to solve the problem of end-to-end encryption for CoAP messages. Therefore, the goal is to hide the message as much as possible the message
while still enabling proxy operation.</t>

<t>Conceptually
        <t>Conceptually, this is achieved by splitting the CoAP message into an Inner Plaintext and Outer OSCORE Message. message. The Inner Plaintext contains sensitive information that is not necessary for proxy operation. However, it is part of the message that can be encrypted until it
reaches its end destination. The Outer Message acts as a shell matching the regular CoAP message format and includes all Options options and information
needed for proxy operation and caching. <xref target="Fig-inner-outer"/> target="Fig-inner-outer" format="default"/> below illustrates this analysis.</t>

<t>The CoAP protocol
        <t>CoAP arranges the options into one of 3 classes; three classes, each granted a specific type of protection by the protocol:</t>

<t><list style="symbols">
  <t>Class E: Encrypted
     <dl spacing="normal">
          <dt>Class E:</dt><dd>Encrypted options moved to the Inner Plaintext,</t>
  <t>Class I: Integrity-protected Plaintext.</dd>
          <dt>Class I:</dt><dd>Integrity-protected options included in the AAD Additional Authenticated Data (AAD) for the encryption of the Plaintext but otherwise left untouched in the Outer Message,</t>
  <t>Class U: Unprotected Message.
</dd>
          <dt>Class U:</dt><dd>Unprotected options left untouched in the Outer Message.</t>
</list></t> Message.</dd>
     </dl>
        <t>These classes point out that the Outer option contains the OSCORE Option option and that the message is OSCORE protected; this option carries the information necessary to retrieve the Security Context. The end-point endpoint will use this Security Context to decrypt the message correctly.</t>
        <figure title="A CoAP packet is split anchor="Fig-inner-outer">
          <name>CoAP Packet Split into an OSCORE outer Outer Header and plaintext" anchor="Fig-inner-outer"><artwork><![CDATA[ Plaintext</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                      Original CoAP Packet
                   +-+-+---+-------+---------------+
                   |v|t|TKL| code  |  Msg Id. Message ID    |
                   +-+-+---+-------+---------------+....+
                   | Token                              |
                   +-------------------------------.....+
                   | Options (IEU)            |
                   .                          .
                   .                          .
                   +------+-------------------+
                   | 0xFF |
                   +------+------------------------+
                   |                               |
                   |     Payload                   |
                   |                               |
                   +-------------------------------+
                          /                \
                         /                  \
                        /                    \
                       /                      \
     Outer Header     v                        v  Plaintext
  +-+-+---+--------+---------------+          +-------+
  |v|t|TKL|new code|  Msg Id. Message ID    |          | code  |
  +-+-+---+--------+---------------+....+     +-------+-----......+
  | Token                               |     | Options (E)       |
  +--------------------------------.....+     +-------+------.....+
  | Options (IU)             |                | OxFF 0xFF  |
  .                          .                +-------+-----------+
  . OSCORE Option            .                |                   |
  +------+-------------------+                | Payload           |
  | 0xFF |                                    |                   |
  +------+                                    +-------------------+

]]></artwork></figure>
]]></artwork>
        </figure>

        <t><xref target="Fig-inner-outer"/> target="Fig-inner-outer" format="default"/> shows the packet format for the OSCORE Outer header and Plaintext.</t>
        <t>In the Outer Header, header, the original header code is hidden and replaced by a default dummy value. As seen in Sections 4.1.3.5
Sections&nbsp;<xref target="RFC8613" section="4.1.3.5" sectionFormat="bare"/> and 4.2 <xref target="RFC8613" section="4.2" sectionFormat="bare"/> of <xref target="RFC8613"/>, the message code is replaced by POST for requests and Changed for responses when CoAP is not using the Observe option. Option. If CoAP uses Observe, the OSCORE message code is replaced by FETCH for requests and Content for responses.</t>
        <t>The first byte of the Plaintext contains the original packet code, followed by the message code, the class E options, and, if present, the original message Payload payload preceded by its payload marker.</t>
        <t>An AEAD Authenticated Encryption with Associated Data (AEAD) algorithm now encrypts the Plaintext. This integrity protects integrity-protects the Security Context parameters and, eventually, any class I options from the Outer Header. header. The resulting Ciphertext ciphertext becomes the new payload of the OSCORE message, as illustrated in <xref target="Fig-full-oscore"/>.</t> target="Fig-full-oscore" format="default"/>.</t>
        <t>As defined in <xref target="RFC5116"/>, target="RFC5116" format="default"/>, this Ciphertext ciphertext is the encrypted Plaintext’s Plaintext's concatenation of the authentication tag. Authentication Tag. Note that Inner Compression only affects the Plaintext before encryption. Thus only the first variable-length of the Ciphertext can be reduced.
The authentication tag is Authentication Tag, fixed in length and uncompressed, is considered part of the cost of protection.</t> protection.
</t>
        <figure title="OSCORE message" anchor="Fig-full-oscore"><artwork><![CDATA[ anchor="Fig-full-oscore">
          <name>OSCORE Message</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     Outer Header
  +-+-+---+--------+---------------+
  |v|t|TKL|new code|  Msg Id. Message ID    |
  +-+-+---+--------+---------------+....+
  | Token                               |
  +--------------------------------.....+
  | Options (IU)             |
  .                          .
  . OSCORE Option            .
  +------+-------------------+
  | 0xFF |
  +------+---------------------------+
  |                                  |
  | Ciphertext: Encrypted Inner      |
  |             Header and Payload   |
  |             + Authentication Tag |
  |                                  |
  +----------------------------------+

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>The SCHC Compression compression scheme consists of compressing both the Plaintext before encryption and the resulting OSCORE message after encryption, encryption; see <xref target="Fig-OSCORE-Compression"/>.</t> target="Fig-OSCORE-Compression" format="default"/>.</t>
        <t>The OSCORE message translates into a segmented process where SCHC compression is applied independently in 2 two stages, each with its corresponding set of Rules, with the Inner SCHC Rules and the Outer SCHC Rules. This way, compression is applied to all fields of the original CoAP message.</t>

<t>Note that since the corresponding end-point can only decrypt the Inner part of the message, this end-point will also have to implement Inner SCHC Compression/Decompression.</t>
        <figure title="OSCORE anchor="Fig-OSCORE-Compression">
          <name>OSCORE Compression Diagram" anchor="Fig-OSCORE-Compression"><artwork><![CDATA[ Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     Outer Message                             OSCORE Plaintext
  +-+-+---+--------+---------------+          +-------+
  |v|t|TKL|new code|  Msg Id. Message ID    |          | code  |
  +-+-+---+--------+---------------+....+     +-------+-----......+
  | Token                               |     | Options (E)       |
  +--------------------------------.....+     +-------+------.....+
  | Options (IU)             |                | OxFF 0xFF  |
  .                          .                +-------+-----------+
  . OSCORE Option            .                |                   |
  +------+-------------------+                | Payload           |
  | 0xFF |                                    |                   |
  +------+------------+                       +-------------------+
  |  Ciphertext       |<---------\                      |
  |                   |          |                      v
  +-------------------+          |             +-----------------+
          |                      |             |   Inner SCHC    |
          v                      |             |   Compression   |
    +-----------------+          |             +-----------------+
    |   Outer SCHC    |          |                     |
    |   Compression   |          |                     v
    +-----------------+          |             +-------+
          |                      |             |RuleID |
          v                      |             +-------+-----------+
    +--------+             +------------+      |Compression Residue|
    |RuleID' |             | Encryption | <--  +----------+--------+
    +--------+-----------+ +------------+      |                   |
    |Compression Residue'|                     | Payload           |
    +-----------+--------+                     |                   |
    |  Ciphertext        |                     +-------------------+
    |                    |
    +--------------------+

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>Note that since the corresponding endpoint can only decrypt the Inner part of the message, this endpoint will also have to implement Inner SCHC Compression/Decompression.</t>
      </section>
      <section anchor="example-oscore-compression" title="Example numbered="true" toc="default">
        <name>Example OSCORE Compression"> Compression</name>
        <t>This section gives an example with a GET Request request and its consequent Content
Response
response from a Device-based CoAP client to a cloud-based CoAP server.
The example also describes a possible set of Rules for the Inner SCHC Compression and Outer SCHC
Compression. A dump of the results and a contrast between SCHC + OSCORE
performance with SCHC + COAP CoAP performance is are also listed. This example gives an approximation of the
cost of security with SCHC-OSCORE.</t>
        <t>Our first CoAP message is the GET request in <xref target="Fig-GET-temp"/>.</t> target="Fig-GET-temp" format="default"/>.</t>
        <figure title="CoAP anchor="Fig-GET-temp">
          <name>CoAP GET Request" anchor="Fig-GET-temp"><artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Original message:
=================
0x4101000182bb74656d7065726174757265

Header:
0x4101
01   Ver
  00   CON
    0001   TKL
        00000001   Request Code 1 "GET"

0x0001 = mid
0x82 = token

Options:
0xbb74656d7065726174757265
Option 11: URI_PATH
Value = temperature

Original msg message length:   17 bytes.
]]></artwork></figure> bytes
]]></artwork>
        </figure>
        <t>Its corresponding response is the CONTENT Response Content response in <xref target="Fig-CONTENT-temp"/>.</t> target="Fig-CONTENT-temp" format="default"/>.</t>
        <figure title="CoAP CONTENT Response" anchor="Fig-CONTENT-temp"><artwork><![CDATA[ anchor="Fig-CONTENT-temp">
          <name>CoAP Content Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Original message:
=================
0x6145000182ff32332043

Header:
0x6145
01   Ver
  10   ACK
    0001   TKL
        01000101 Successful Response Code 69 "2.05 Content"

0x0001 = mid
0x82 = token

0xFF  Payload marker
Payload:
0x32332043

Original msg message length:   10
]]></artwork></figure> bytes
]]></artwork>
        </figure>

        <t>The SCHC Rules for the Inner Compression include all fields already present in a regular CoAP message. The methods described in <xref target="CoAPcomp"/> target="CoAPcomp" format="default"/> apply to these fields. As an example, see <xref target="Fig-Inner-Rules"/>.</t>

<figure title="Inner SCHC Rules" anchor="Fig-Inner-Rules"><artwork><![CDATA[
 RuleID 0
+--------------+--+--+--+-----------+---------+---------++------+
| Field        |FL|FP|DI|  Target   |    MO   |    CDA  || Sent |
|              |  |  |  |  Value    |         |         ||[bits]|
+--------------+--+--+--+-----------+---------+---------++------+
|CoAP Code     | 8| 1|up| 1         |  equal  |not-sent ||      |
|CoAP Code     | 8| 1|dw|[69,       |         |         ||      |
|              |  |  |  |132]       |match-   |mapping- ||      |
|              |  |  |  |           |mapping  |sent     || c    |
|CoAP Uri-Path |  | 1|up|temperature|  equal  |not-sent ||      |
+--------------+--+--+--+-----------+---------+---------++------+
]]></artwork></figure> target="Table-Inner-Rules" format="default"/> provides an example.</t>

<table anchor="Table-Inner-Rules">
  <name>Inner SCHC Rule</name>
  <thead>
    <tr>
      <th align="left" colspan="8">RuleID 0</th>
    </tr>
    <tr>
      <th align="center">Field</th>
      <th align="center">FL</th>
      <th align="center">FP</th>
      <th align="center">DI</th>
      <th align="center">TV</th>
      <th align="center">MO</th>
      <th align="center">CDA</th>
      <th align="center">Sent [bits]</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Up</td>
      <td>1</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Dw</td>
      <td>[69,132]</td>
      <td>match-mapping</td>
      <td>mapping-sent</td>
      <th>c</th>
    </tr>
    <tr>
      <td>CoAP Uri-Path</td>
      <td></td>
      <td>1</td>
      <td>Up</td>
      <td>temperature</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
  </tbody>
</table>

        <t><xref target="Fig-Inner-Compression-GET"/> target="Fig-Inner-Compression-GET" format="default"/> shows the Plaintext obtained for the example GET request. The packet follows the process of Inner Compression and Encryption encryption until the payload. The outer Outer OSCORE Message message adds the result of the Inner process.</t>

<t>In this case, the original message has no payload, and its resulting Plaintext compressed up to only 1 byte (size of the RuleID). The AEAD algorithm preserves this length in its first output and yields a fixed-size tag. SCHC cannot compress the tag, and the OSCORE message must include it without compression.
The use of integrity protection translates into an overhead in total message length, limiting the amount of compression that can be achieved and plays into the cost of adding security to the exchange.</t>
        <figure title="Plaintext compression anchor="Fig-Inner-Compression-GET">
          <name>Plaintext Compression and encryption Encryption for GET Request" anchor="Fig-Inner-Compression-GET"><artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   ________________________________________________________
  |                                                        |
  | OSCORE Plaintext                                       |
  |                                                        |
  | 0x01bb74656d7065726174757265  (13 bytes)               |
  |                                                        |
  | 0x01 Request Code GET                                  |
  |                                                        |
  |      bb74656d7065726174757265 Option 11: URI_PATH      |
  |                               Value = temperature      |
  |________________________________________________________|

                              |
                              |
                              | Inner SCHC Compression
                              |
                              v
                _________________________________
               |                                 |
               | Compressed Plaintext            |
               |                                 |
               | 0x00                            |
               |                                 |
               | RuleID = 0x00 (1 byte)          |
               | (No Compression Residue)        |
               |_________________________________|

                              |
                              | AEAD Encryption
                              |  (piv = 0x04)
                              v
         _________________________________________________
        |                                                 |
        |  encrypted_plaintext = 0xa2 (1 byte)            |
        |  tag = 0xc54fe1b434297b62 (8 bytes)             |
        |                                                 |
        |  ciphertext = 0xa2c54fe1b434297b62 (9 bytes)    |
        |_________________________________________________|

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In this case, the original message has no payload, and its resulting Plaintext is compressed up to only 1 byte (the size of the RuleID). The AEAD algorithm preserves this length in its first output and yields a fixed-size tag. SCHC cannot compress the tag, and the OSCORE message must include it without compression.
The use of integrity protection translates into an overhead in total message length, limiting the amount of compression that can be achieved and playing into the cost of adding security to the exchange.</t>
        <t><xref target="Fig-Inner-Compression-CONTENT"/> target="Fig-Inner-Compression-CONTENT" format="default"/> shows the process for the example CONTENT Response. Content response. The Compression Residue is 1 bit long.
Note that since SCHC adds padding after the payload, this misalignment causes the hexadecimal code from the payload to differ from the original, even if SCHC cannot compress the tag. The overhead for the tag bytes limits the SCHC’s SCHC's performance but brings security to the transmission.</t>
        <figure title="Plaintext compression anchor="Fig-Inner-Compression-CONTENT">
          <name>Plaintext Compression and encryption Encryption for CONTENT Response" anchor="Fig-Inner-Compression-CONTENT"><artwork><![CDATA[ Content Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   ________________________________________________________
  |                                                        |
  | OSCORE Plaintext                                       |
  |                                                        |
  | 0x45ff32332043  (6 bytes)                              |
  |                                                        |
  | 0x45 Successful Response Code 69 "2.05 Content"        |
  |                                                        |
  |     ff Payload marker                                  |
  |                                                        |
  |       32332043 Payload                                 |
  |________________________________________________________|

                              |
                              |
                              | Inner SCHC Compression
                              |
                              v
         _____________________________________________
      _________________________________________________
     |                                                 |
     | Compressed Plaintext                            |
     |                                                 |
     | 0x001919902180 (6 bytes)                        |
     |                                                 |
     |   00 RuleID                                     |
     |                                                 |
     |  0b0 (1 bit match-map match-mapping Compression Residue)  |
     |       0x32332043 >> 1 (shifted payload)         |
     |                        0b0000000 Padding        |
        |_____________________________________________|
     |_________________________________________________|

                              |
                              | AEAD Encryption
                              |  (piv = 0x04)
                              v
     _________________________________________________________
    |                                                         |
    |  encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes)         |
    |  tag = 0xe9aef3f2461e0c29 (8 bytes)                     |
    |                                                         |
    |  ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |
    |_________________________________________________________|

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>The Outer SCHC Rules Rule (<xref target="Fig-Outer-Rules"/>) target="Table-Outer-Rule" format="default"/>) must process the OSCORE Options options fields. <xref target="Fig-Protected-Compressed-GET"/> Figures&nbsp;<xref target="Fig-Protected-Compressed-GET" format="counter"/> and <xref target="Fig-Protected-Compressed-CONTENT"/> shows target="Fig-Protected-Compressed-CONTENT" format="counter"/> show a dump of the OSCORE Messages messages generated from the example messages. They include the Inner Compressed Ciphertext ciphertext in the payload. These are the messages that have to be compressed by via the Outer SCHC Compression.</t> Compression scheme.</t>

        <t><xref target="Table-Outer-Rule" format="default"/> shows a possible set of Outer Rule items to compress the Outer header.</t>

<table anchor="Table-Outer-Rule">
  <name>Outer SCHC Rule</name>
  <thead>
    <tr>
      <th align="left" colspan="8">RuleID 0</th>
    </tr>
    <tr>
      <th align="center">Field</th>
      <th align="center">FL</th>
      <th align="center">FP</th>
      <th align="center">DI</th>
      <th align="center">TV</th>
      <th align="center">MO</th>
      <th align="center">CDA</th>
      <th align="center">Sent [bits]</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>CoAP version</td>
      <td>2</td>
      <td>1</td>
      <td>Bi</td>
      <td>01</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Type</td>
      <td>2</td>
      <td>1</td>
      <td>Up</td>
      <td>0</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Type</td>
      <td>2</td>
      <td>1</td>
      <td>Dw</td>
      <td>2</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP TKL</td>
      <td>4</td>
      <td>1</td>
      <td>Bi</td>
      <td>1</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Up</td>
      <td>2</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Dw</td>
      <td>68</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP MID</td>
      <td>16</td>
      <td>1</td>
      <td>Bi</td>
      <td>0000</td>
      <td>MSB(12)</td>
      <td>LSB</td>
      <th>MMMM</th>
    </tr>
    <tr>
      <td>CoAP Token</td>
      <td>tkl</td>
      <td>1</td>
      <td>Bi</td>
      <td>0x80</td>
      <td>MSB(5)</td>
      <td>LSB</td>
      <th>TTT</th>
    </tr>
    <tr>
      <td>CoAP OSCORE_flags</td>
      <td>8</td>
      <td>1</td>
      <td>Up</td>
      <td>0x09</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP OSCORE_piv</td>
      <td>var</td>
      <td>1</td>
      <td>Up</td>
      <td>0x00</td>
      <td>MSB(4)</td>
      <td>LSB</td>
      <th>PPPP</th>
    </tr>
    <tr>
      <td>CoAP OSCORE_kid</td>
      <td>var</td>
      <td>1</td>
      <td>Up</td>
      <td>0x636c69656e70</td>
      <td>MSB(52)</td>
      <td>LSB</td>
      <th>KKKK</th>
    </tr>
    <tr>
      <td>CoAP OSCORE_kidctx</td>
      <td>var</td>
      <td>1</td>
      <td>Bi</td>
      <td>b''</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP OSCORE_flags</td>
      <td>8</td>
      <td>1</td>
      <td>Dw</td>
      <td>b''</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP OSCORE_piv</td>
      <td>var</td>
      <td>1</td>
      <td>Dw</td>
      <td>b''</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP OSCORE_kid</td>
      <td>var</td>
      <td>1</td>
      <td>Dw</td>
      <td>b''</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
  </tbody>
</table>

        <figure title="Protected anchor="Fig-Protected-Compressed-GET">
          <name>Protected and Inner SCHC Compressed GET Request" anchor="Fig-Protected-Compressed-GET"><artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Protected message:
==================
0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62
(25 bytes)

Header:
0x4102
01   Ver
  00   CON
    0001   TKL
        00000010   Request Code 2 "POST"

0x0001 = mid
0x82 = token

Options:
0xd8080904636c69656e74 (10 bytes)
Option 21: OBJECT_SECURITY
Value = 0x0904636c69656e74
          09 = 000 0 1 001 Flag flag byte
                   h k  n
            04 piv
              636c69656e74 kid

0xFF  Payload marker
Payload:
0xa2c54fe1b434297b62 (9 bytes)
]]></artwork></figure>
]]></artwork>
        </figure>
        <figure title="Protected anchor="Fig-Protected-Compressed-CONTENT">
          <name>Protected and Inner SCHC Compressed CONTENT Response" anchor="Fig-Protected-Compressed-CONTENT"><artwork><![CDATA[ Content Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Protected message:
==================
0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29
(22 bytes)

Header:
0x6144
01   Ver
  10   ACK
    0001   TKL
        01000100   Successful Response Code 68 "2.04 Changed"

0x0001 = mid
0x82 = token

Options:
0xd008 (2 bytes)
Option 21: OBJECT_SECURITY
Value = b''

0xFF  Payload marker
Payload:
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>For the flag bits, some SCHC compression methods are useful, depending on the Application. application. The most straightforward alternative is to
provide a fixed value for the flags, combining a MO “equal” of "equal" and a CDA “not-sent.” of "not-sent".
This SCHC definition saves most bits but could prevent flexibility. Otherwise, SCHC could use a “match-mapping” "match-mapping" MO to choose from several configurations for the exchange. If not, the SCHC description may use an “MSB” "MSB" MO to mask off the three hard-coded most significant bits.</t>
        <t>Note that fixing a flag bit will limit the choices of CoAP Options choice options that can be used in the exchange exchange, since their the values of these choices are dependent on specific options.</t> options.
</t>
        <t>The piv field lends itself to having some bits masked off with “MSB” an "MSB" MO and “LSB” an "LSB" CDA. This SCHC description could be useful in applications where the message frequency is low low, such as LPWAN technologies.
Note that compressing the sequence numbers may reduce the maximum number of sequence numbers that can be used in an exchange.
Once the sequence number exceeds the maximum value, the OSCORE keys need to be re-established.</t>
        <t>The size s size, s, that is included in the kid context field MAY <bcp14>MAY</bcp14> be masked off with “LSB” an "LSB" CDA. The rest of the field could have additional bits masked off or have the whole field fixed with a MO “equal” of "equal" and a CDA “not-sent.” of "not-sent". The same holds for the kid field.</t>

<t><xref target="Fig-Outer-Rules"/> shows a possible set of
        <t>The Outer Rules to compress the Outer Header.</t>

<figure title="Outer SCHC Rules" anchor="Fig-Outer-Rules"><artwork><![CDATA[
RuleID 0
+------------------+--+--+--+--------------+-------+--------++------+
| Field            |FL|FP|DI|    Target    |   MO  |   CDA  || Sent |
|                  |  |  |  |    Value     |       |        ||[bits]|
+------------------+--+--+--+--------------+-------+--------++------+
|CoAP version      | 2| 1|bi|      01      |equal  |not-sent||      |
|CoAP Type         | 2| 1|up|      0       |equal  |not-sent||      |
|CoAP Type         | 2| 1|dw|      2       |equal  |not-sent||      |
|CoAP TKL          | 4| 1|bi|      1       |equal  |not-sent||      |
|CoAP Code         | 8| 1|up|      2       |equal  |not-sent||      |
|CoAP Code         | 8| 1|dw|      68      |equal  |not-sent||      |
|CoAP MID          |16| 1|bi|     0000     |MSB(12)|LSB     ||MMMM  |
|CoAP Token        |tkl 1|bi|     0x80     |MSB(5) |LSB     ||TTT   |
|CoAP OSCORE_flags | 8| 1|up|     0x09     |equal  |not-sent||      |
|CoAP OSCORE_piv   |var 1|up|     0x00     |MSB(4) |LSB     ||PPPP  |
|COAP OSCORE_kid   |var 1|up|0x636c69656e70|MSB(52)|LSB     ||KKKK  |
|COAP OSCORE_kidctx|var 1|bi|     b''      |equal  |not-sent||      |
|CoAP OSCORE_flags | 8| 1|dw|     b''      |equal  |not-sent||      |
|CoAP OSCORE_piv   |var 1|dw|     b''      |equal  |not-sent||      |
|CoAP OSCORE_kid   |var 1|dw|     b''      |equal  |not-sent||      |
+------------------+--+--+--+--------------+-------+--------++------+
]]></artwork></figure>

<t>The Outer Rule of <xref target="Fig-Outer-Rules"/> is applied Rule of <xref target="Table-Outer-Rule" format="default"/> is applied to the example GET Request request and CONTENT Response.
<xref target="Fig-Compressed-GET"/> Content response.
Figures&nbsp;<xref target="Fig-Compressed-GET" format="counter"/> and <xref target="Fig-Compressed-CONTENT"/> target="Fig-Compressed-CONTENT" format="counter"/> show the resulting messages.</t>
        <figure title="SCHC-OSCORE anchor="Fig-Compressed-GET">
          <name>SCHC-OSCORE Compressed GET Request" anchor="Fig-Compressed-GET"><artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message:
==================
0x001489458a9fc3686852f6c4 (12 bytes)
0x00 RuleID
    1489 Compression Residue
        458a9fc3686852f6c4 Padded payload

Compression Residue:
0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding)
    mid tkn piv  kid

Payload
0xa2c54fe1b434297b62 (9 bytes)

Compressed message length: 12 bytes
]]></artwork></figure>
]]></artwork>
        </figure>

        <figure title="SCHC-OSCORE anchor="Fig-Compressed-CONTENT">
          <name>SCHC-OSCORE Compressed CONTENT Response" anchor="Fig-Compressed-CONTENT"><artwork><![CDATA[ Content Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message:
==================
0x0014218daf84d983d35de7e48c3c1852 (16 bytes)
0x00 RuleID
    14 Compression Residue
      218daf84d983d35de7e48c3c1852 Padded payload
Compression Residue:
0b0001 010 (7 bits -> 1 byte with padding)
  mid  tkn

Payload
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)

Compressed msg message length: 16 bytes
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In contrast, comparing these results with what would be obtained by SCHC
compressing the original CoAP messages without protecting them with OSCORE is done
by compressing the CoAP messages according to the SCHC Rules Rule in <xref target="Fig-NoOsc-Rules"/>.</t>

<figure title="SCHC-CoAP Rules target="Table-NoOsc-Rule" format="default"/>.</t>

<table anchor="Table-NoOsc-Rule">
  <name>SCHC-CoAP Rule (No OSCORE)" anchor="Fig-NoOsc-Rules"><artwork><![CDATA[
RuleID 1
+---------------+--+--+--+-----------+---------+-----------++-------+
| Field         |FL|FP|DI|  Target   |   MO    |     CDA   ||  Sent |
|               |  |  |  |  Value    |         |           || [bits]|
+---------------+--+--+--+-----------+---------+-----------++-------+
|CoAP version   | 2| 1|bi|    01     |equal    |not-sent   ||       |
|CoAP Type      | 2| 1|up|    0      |equal    |not-sent   ||       |
|CoAP Type      | 2| 1|dw|    2      |equal    |not-sent   ||       |
|CoAP TKL       | 4| 1|bi|    1      |equal    |not-sent   ||       |
|CoAP Code      | 8| 1|up|    2      |equal    |not-sent   ||       |
|CoAP Code      | 8| 1|dw| [69,132]  |match-   |mapping-   ||       |
|               |  |  |  |           |mapping  |sent       ||C      |
|CoAP MID       |16| 1|bi|   0000    |MSB(12)  |LSB        ||MMMM   |
|CoAP Token     |tkl 1|bi|    0x80   |MSB(5)   |LSB        ||TTT    |
|CoAP Uri-Path  |  | 1|up|temperature|equal    |not-sent   ||       |
+---------------+--+--+--+-----------+---------+-----------++-------+
]]></artwork></figure>

<t><xref target="Fig-NoOsc-Rules"/> OSCORE)</name>
  <thead>
    <tr>
      <th align="left" colspan="8">RuleID 1</th>
    </tr>
    <tr>
      <th align="center">Field</th>
      <th align="center">FL</th>
      <th align="center">FP</th>
      <th align="center">DI</th>
      <th align="center">TV</th>
      <th align="center">MO</th>
      <th align="center">CDA</th>
      <th align="center">Sent [bits]</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>CoAP version</td>
      <td>2</td>
      <td>1</td>
      <td>Bi</td>
      <td>01</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Type</td>
      <td>2</td>
      <td>1</td>
      <td>Up</td>
      <td>0</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Type</td>
      <td>2</td>
      <td>1</td>
      <td>Dw</td>
      <td>2</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP TKL</td>
      <td>4</td>
      <td>1</td>
      <td>Bi</td>
      <td>1</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Up</td>
      <td>2</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
    <tr>
      <td>CoAP Code</td>
      <td>8</td>
      <td>1</td>
      <td>Dw</td>
      <td>[69,132]</td>
      <td>match-mapping</td>
      <td>mapping-sent</td>
      <th>C</th>
    </tr>
    <tr>
      <td>CoAP MID</td>
      <td>16</td>
      <td>1</td>
      <td>Bi</td>
      <td>0000</td>
      <td>MSB(12)</td>
      <td>LSB</td>
      <th>MMMM</th>
    </tr>
    <tr>
      <td>CoAP Token</td>
      <td>tkl</td>
      <td>1</td>
      <td>Bi</td>
      <td>0x80</td>
      <td>MSB(5)</td>
      <td>LSB</td>
      <th>TTT</th>
    </tr>
    <tr>
      <td>CoAP Uri-Path</td>
      <td></td>
      <td>1</td>
      <td>Up</td>
      <td>temperature</td>
      <td>equal</td>
      <td>not-sent</td>
      <th></th>
    </tr>
  </tbody>
</table>

        <t>The Rule in <xref target="Table-NoOsc-Rule" format="default"/> yields the SCHC compression results as shown in <xref target="Fig-GET-temp-no-oscore"/> target="Fig-GET-temp-no-oscore" format="default"/> for request, the request and
<xref target="Fig-CONTENT-temp-no-oscore"/> target="Fig-CONTENT-temp-no-oscore" format="default"/> for the response.</t> response.
</t>
        <figure title="CoAP anchor="Fig-GET-temp-no-oscore">
          <name>CoAP GET Compressed without OSCORE" anchor="Fig-GET-temp-no-oscore"><artwork><![CDATA[ OSCORE</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message:
==================
0x0114
0x01 = RuleID

Compression Residue:
0b00010100 (1 byte)

Compressed msg message length: 2

]]></artwork></figure> bytes
]]></artwork>
        </figure>
        <figure title="CoAP CONTENT anchor="Fig-CONTENT-temp-no-oscore">
          <name>CoAP Content Compressed without OSCORE" anchor="Fig-CONTENT-temp-no-oscore"><artwork><![CDATA[ OSCORE</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message:
==================
0x010a32332043
0x01 = RuleID

Compression Residue:
0b00001010 (1 byte)

Payload
0x32332043

Compressed msg message length: 6

]]></artwork></figure> bytes
]]></artwork>
        </figure>
        <t>As can be seen, the difference between applying SCHC + OSCORE as compared to
regular SCHC + COAP CoAP is about 10 bytes.</t>
      </section>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no request to IANA.</t> IANA actions.</t>
    </section>
    <section anchor="SecConsiderations" title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The use of SCHC header compression for CoAP header fields only affects
the representation of the header information.  information.  SCHC header compression
itself does not increase or decrease the overall level of security of
the communication.  communication.  When the connection does not use a security protocol
(such as OSCORE,
(OSCORE, DTLS, etc.), it is necessary to use a layer-two Layer 2
security mechanism to protect the SCHC messages.</t>
      <t>If an LPWAN is the layer-two technology, Layer 2 technology being used, the SCHC security considerations
of
discussed in <xref target="RFC8724"></xref> target="RFC8724" format="default"/> continue to apply.  apply.  When using another layer-two Layer 2 protocol, the
use of a cryptographic integrity-protection mechanisms mechanism to protect the
SCHC headers is REQUIRED.  <bcp14>REQUIRED</bcp14>. Such cryptographic integrity protection is
necessary in order to continue to provide the properties that <xref target="RFC8724"></xref> target="RFC8724" format="default"/>
relies upon.</t>
      <t>When SCHC is used with OSCORE, the security considerations of discussed in <xref target="RFC8613"></xref> target="RFC8613" format="default"/>
continue to apply.</t>
      <t>When SCHC is used with the OSCORE outer Outer headers, the Initialization
Vector (IV) size in the Compression Residue must be carefully selected.
There is a tradeoff trade-off between compression efficiency (with a longer “MSB” "MSB"
MO prefix) and the frequency at which the Device must renew its key
material (in order to prevent the IV from expanding to an uncompressable
value).  uncompressible
value).  The key renewal key-renewal operation itself requires several message
exchanges and requires energy-intensive computation, but the optimal
tradeoff
trade-off will depend on the specifics of the device Device and expected usage
patterns.</t>
      <t>If an attacker can introduce a corrupted SCHC-compressed packet onto a
link, DoS attacks are possible can be mounted by causing excessive resource consumption
at the decompressor.  decompressor.  However, an attacker able to inject packets at the
link layer is also capable of other, potentially more damaging, attacks.</t>
      <t>SCHC compression emits variable-length Compression Residues for some
CoAP fields.  fields.  In the representation of the compressed header representation, header, the length field
that is sent is not the length of the original header field but rather
the length of the Compression Residue that is being transmitted.  transmitted.  If a
corrupted packet arrives at the decompressor with a longer or shorter
length than the original compressed representation possessed, the SCHC
decompression procedures will detect an error and drop the packet.</t>
      <t>SCHC header compression rules MUST Rules <bcp14>MUST</bcp14> remain tightly coupled between the
compressor and decompressor.  the decompressor.  If the compression rules Rules get out of sync,
a Compression Residue might be decompressed differently at the receiver
than the initial message submitted to compression procedures.
Accordingly, any time the context Rules are updated on an OSCORE
endpoint, that endpoint MUST <bcp14>MUST</bcp14> trigger OSCORE key re-establishment.
Similar procedures may be appropriate to signal Rule udpates updates when other
message-protection mechanisms are in use.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8724.xml"/>
    </references>

    <section anchor="acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank (in alphabetic order): Christian Amsuss, Dominique Barthel, Carsten Bormann, Theresa Enghardt, Thomas Fossati, Klaus Hartke, Benjamin Kaduk, Francesca Palombini, Alexander Pelov, Goran Selander and Eric Vyncke.</t>
<contact fullname="Christian Amsuss"/>, <contact fullname="Dominique Barthel"/>,  <contact fullname="Carsten Bormann"/>, <contact fullname="Theresa Enghardt"/>,
<contact fullname="Thomas Fossati"/>, <contact fullname="Klaus Hartke"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Alexander Pelov"/>, <contact fullname="Göran Selander"/>, and
<contact fullname="Éric Vyncke"/>.</t>
    </section>

  </middle>

  <back>

    <references title='Normative References'>

<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor="RFC5116" target='https://www.rfc-editor.org/info/rfc5116'>
<front>
<title>An Interface and Algorithms for Authenticated Encryption</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<date year='2008' month='January' />
<abstract><t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5116'/>
<seriesInfo name='DOI' value='10.17487/RFC5116'/>
</reference>

<reference  anchor="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>

<reference  anchor="RFC7967" target='https://www.rfc-editor.org/info/rfc7967'>
<front>
<title>Constrained Application Protocol (CoAP) Option for No Server Response</title>
<author initials='A.' surname='Bhattacharyya' fullname='A. Bhattacharyya'><organization /></author>
<author initials='S.' surname='Bandyopadhyay' fullname='S. Bandyopadhyay'><organization /></author>
<author initials='A.' surname='Pal' fullname='A. Pal'><organization /></author>
<author initials='T.' surname='Bose' fullname='T. Bose'><organization /></author>
<date year='2016' month='August' />
<abstract><t>There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant.  This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient.  However, the request/response semantics still require the server to respond with a status code indicating &quot;the result of the attempt to       understand and satisfy the request&quot;, per RFC 7252.</t><t>This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes.  The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request.  This option may be effective for both unicast and multicast requests.  This document also discusses a few examples of applications that benefit from this option.</t></abstract>
</front>
<seriesInfo name='RFC' value='7967'/>
<seriesInfo name='DOI' value='10.17487/RFC7967'/>
</reference>

<reference  anchor="RFC7641" target='https://www.rfc-editor.org/info/rfc7641'>
<front>
<title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t></abstract>
</front>
<seriesInfo name='RFC' value='7641'/>
<seriesInfo name='DOI' value='10.17487/RFC7641'/>
</reference>

<reference  anchor="RFC7959" target='https://www.rfc-editor.org/info/rfc7959'>
<front>
<title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby' role='editor'><organization /></author>
<date year='2016' month='August' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates.  In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS).  These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t><t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of &quot;Block&quot; options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t><t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations.  Therefore, this specification updates RFC 7252.</t></abstract>
</front>
<seriesInfo name='RFC' value='7959'/>
<seriesInfo name='DOI' value='10.17487/RFC7959'/>
</reference>

<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference  anchor="RFC8613" target='https://www.rfc-editor.org/info/rfc8613'>
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)</title>
<author initials='G.' surname='Selander' fullname='G. Selander'><organization /></author>
<author initials='J.' surname='Mattsson' fullname='J. Mattsson'><organization /></author>
<author initials='F.' surname='Palombini' fullname='F. Palombini'><organization /></author>
<author initials='L.' surname='Seitz' fullname='L. Seitz'><organization /></author>
<date year='2019' month='July' />
<abstract><t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t><t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t></abstract>
</front>
<seriesInfo name='RFC' value='8613'/>
<seriesInfo name='DOI' value='10.17487/RFC8613'/>
</reference>

<reference  anchor="RFC8724" target='https://www.rfc-editor.org/info/rfc8724'>
<front>
<title>SCHC: Generic Framework for Static Context Header Compression and Fragmentation</title>
<author initials='A.' surname='Minaburo' fullname='A. Minaburo'><organization /></author>
<author initials='L.' surname='Toutain' fullname='L. Toutain'><organization /></author>
<author initials='C.' surname='Gomez' fullname='C. Gomez'><organization /></author>
<author initials='D.' surname='Barthel' fullname='D. Barthel'><organization /></author>
<author initials='JC.' surname='Zúñiga' fullname='JC. Zúñiga'><organization /></author>
<date year='2020' month='April' />
<abstract><t>This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.</t><t>SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.</t><t>This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.</t><t>The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.</t></abstract>
</front>
<seriesInfo name='RFC' value='8724'/>
<seriesInfo name='DOI' value='10.17487/RFC8724'/>
</reference>

    </references>

  </back>

<!-- ##markdown-source:
H4sIAOw+RmAAA+19aXcbx5Xo9/4VdegPIkcADFAktTjOG4qkYj6LIiPS9swk
PjkNoEF2CHTjdTe4TOj5Lf4t/mXvrrX0wkXS5OTMBFlENLqqbt26devu1e/3
o7KKs+lf4nmeJW9MVaySKF0W9FdZbQ6Hr4eb0TSfZPECfp4W8azqp0k168+X
13HWn+Txsg89VOkE/s6q5KbqX0z6o9fRJK7emLKaRsv0TWRMebsokln5xjy7
Tcpn+CAvqtqTqkgnlfs+yRfL2H9Q5RP9ElVpNQeA3p/8tPvBnBIAZo8BMN8l
8TQp4OtiWSRlmeaZWT/d+25vw8xyfLx7EsXjcZFcaXt8RMPJ69H1+RtDEzQ/
5cVlmp2bPxT5ahnFq+oiL95EfZNmAPnuwBylWTxeFTmAxyjazWL/YV5AV7uT
y3ma8xSTBGY0Gr14uWviqyRbJWaalGbvIl4sS/N2HmeTEueeVrdvzIvt7dHQ
7AFQedY/Ta7S8yyBr9PkhtCzyqoC3npXQKMEniSLOJ2/MXEW/2sMIw5gSAH0
/cCc5asqTjML5/t4VSRZ5T0nUA+zElC7qszR4YeDU3N28P5g7/joG3N4dGZ2
KwCvSv/fKnFTgb/6ZtMUNA8zj3Em0B8AWsRpQr/unZrRy53hS39aL3eePC0B
eCAA/2u6qPqxhWgwK3SyHwewCNMiicvETfdjOomLaR78QhP+IUuvkqJMp/EU
Z/B2lWR5aXZTIAVvwXavBuYEmuVAK7BTzKvtoZ3O3mi482J370ezl66wl91V
lWf5Im7pzk5utziHuQCZuPnBdAW0f52lg9U4HsRFlOXFAmj7CmZg4NWP7/Y2
R6PXb/jP7dFoR/58ubm9qX++3nmpf+5sjezTbW32avRyS//cGb3QP19ubr3B
MaIo6vf7Jh7D3GH7RfDInF2kJW9+mNQszYBiL/Jr2JB215jqIsENiI3gd8DC
cjkHnFe4+06KHPZuPjfruNM2zKrELYUtHrtzBwiZwT8NQBKbC37R27NmkUwu
4iwtFyaexssKQODd7kDaB1KbJKXX16pMsDdmYLgRJ0W6JJDzGcEn48BEi2S6
miTew2clPcumQKa3sOmmpkz/Mxlg3z9dpPMEkWoQq9LvOGEk0cA+4Nh0VsTn
C6AIxhd8WyTXwHl62Bv+nlYAp4dRnNrhydXO1z/snwg8ZQ+6x2XKJyvsit+H
QWlA5Xz6MjAEWjD7BEl9Nalgj5lpOpvBKwBGviBc4UgEBo4GazeRloK+2Ty5
Scdzi63rtLqAx1dxkcb4OFstxvAYUJoTcgnSZFEm8ytoD4/tm/MkO68uPNiW
SjkIxgIQFp9DkxntCqIEOFcWCR4cbwi5RQK8oKzcqxfAZB29SEOeIOKIpogN
4fQD7iF9lEsAMrGdDIj+EYJymUzSmS7CeYrwn69SJAHsglB+i7RNOAeqqaGm
JCzK1pknwHigfxpUJ3JLK7XIYRmSGYyUIpQ+tXxczQGiSHbpIp1O50kUfQWM
uypyIFGC7G9f+V9/iSJC5t/+Jpzil194F0G/CwDoaztji24gWeTKvIcW6aTI
6Xgv8vkcZyErXC7i+dx83D2iaX085n9xkRewFbjxx4PTs/4Y2NrUrH9McBpM
5rAsuO1g9sD4SliODVMmhWzQ3Tmcs6vziwZXkS0MuIunynNgZgxuD0DyKBo2
KO5InCqcaQBolQPSY+C8BBgf/evvYTFO8msgjp9SYNi7wILNh6TC3VduDCJa
yBZuk18lwYbCUZD4gNFPcXFhkxAzN8ukIKojCilwy3Az6oBhqIBzZXCsnKe0
skj8tFTIPGCplOMiKL2HeB/ODNHCPWc8EcP4RwJVXifC2sCcJkwy28ry/KGT
m+UcEA8LfgH7pcG1pkmAkslkVegmiovJRQoTQ4bC+7nB98oJMAGk/BL4FW5l
gA5+JCyWKVIGiBJmnAOpJdm0v8zTDLjgZYa75yKpTcSMkxluGqKmRUoj8LjX
8S29ry/CQsGfs/QcIJv2kOSvUnwbvwDykhtE5TmgC14EUYPR4vFVJKtJvgRO
z7sKd1IWMGfdRT0QchuypVJJicJKBfsH2QVuRN3bMJPqOkkYjbB8curhyxlt
jgYiFzBD4jwG8IUtHH9DHjMHmQh+ODyxLFzWKKQR/DHOANtAW9gPLqI3KerJ
HiOE2pLh80ApCZYxstJpsoRVQ4HNvMUlnAHr0JWD0w2QBFskXc4TezxOES6P
+oANlN5UUF6q8DyDvaRcs4HcgLnz5Hvu1GX8Tov0SuUPr+3XITXHQEzxvPSQ
yeQU7kw92IWl4+62x62HcHvo8ucsOKflUHG98Fo2lrnKwxM8ioJXkrK2J7FD
OXXs/hdCk73gaM2KRtKlbJVsMl+herJYzStaKz59zEE8uaC/zSRG+qsmF764
BJOZI3vO7YEJR/x8hYd9gXLuuR77+GxgDmew86k36imRJeMv01qnuC5FAmxp
Aj+NeWtj28N9mj5ThXdcwskwXQkvwXkRO5NjHn6J52aMwpUwPw/fuNwrAMXR
E5MPUvgkL/jMJF7v3rDnpyJedhrosZdJxUDEgmxkrsAfGU0JnpuAm2SSwMkI
S7vLCAlFR+6mfEZ7oajJW8CAC/iWTH/7dZ6WxLcEZZ5cW34DY8EOFKb/Et8K
ttwZMnpAawIr/NuvvkQcII96NoDz9XeH+xs9kk9ZeIMn7+GBCK2//brMgZeT
IP/uBJ8DtgoZHZgEcheY9/r+4YZZXy1R3YoXgPP8OtO/oafffh2ntlk8l+7L
nE+PfJLGKO6f4dFemR+Z0tbPftzgHds2IOy/VSkSSm2PoVRHcxyjIHn2Iz7D
rzBRPAZpQWGbC0Hz2us6+6ePGxd2VY5iMuFMGKRjeiWJgSCdpAs6/nfNERI+
cqhjEB4YP0fHGyzu2tnSouMqBfvDX2uePZERikDJHKBBJgu7DYUh+O3oGGTp
lHn92Y8kV9NvQjeyJ4AL5AsEhwcaKG3C1ofjAifj9007lwVnRzJAnKsMT+5M
wBScBgwsh66jw0y2KnAsluccg94PGPQur+n63v7uRjtieCiW0hkskCqngdYa
ckyvGSiJe8ERm2bAk+ErcELa1qgwAIK2TExwlG+i6F8Mb2S3QYhIzDr900fB
F0jXvoZnLaJ1Hf5o/EjEDVIukCCKtqR0AIPxeRUPsf7+9O0GbH2vbUyUntyY
9QUcJTAE9460NavwdFctpcbxiO0WiZIogUADAsZoleEMjM586kdmPAGKAbS3
MF3UUpzKfp5kROeenk4KagcLlUMguQH8CudlMGjfsnSBc8iFwyrn1UPAsz/A
sRupmDsatsm5IZttEVJV326e6OFZXhEP8jSTFmGdrR+IGEDQV1+Zs6SA7YXy
/y0L/5fJrQGRDHbg2tEPp2drPf7XfDimvz8e/PGHw48H+/j36Xe779/bP/iN
CL4c//Befse/XMu946Ojgw/73Biemtqjo91/XyPuGq0dn5wdHn/Yfb/GzC2w
LKCgnbOcBwQFM8ONF5ehKPd278SMtiLCM1qtfvmFUT56iShHVsp8PMedxV8B
bbcRkEUSE0tFXjSJlymIyUAO0H95gSwEiRRRx+xDFnqcztPq1gpJkWHS88my
ZgMxMFlixaL7A7f66ypjMiEmgos4J9VwHt/iab6uJhfccL6MO7/1dBwyP4nQ
TO16IV4Cjcujwp5uPKJwO1sSit+l533sfO9492SEr4aPNvER4jJ8/AJOdGGp
yC4KYCawnxYgyNU7oD5FCPPkR90Nc1hgZycCKYQNJ7QjBOOwyQ6FTph3Y1uR
dHRPfvjDT6oPM6r2vgYJ4mEb4J49IbwzIC/gfCes+6ZGFHBXGX2DTWaXUQCZ
5jApPLRSnBPRssKBzOq/4EP2Tvisc5MN433WYQLBg+ZnHYDZ0D6e9+Xz/P5G
wcc1kl7uDFMt/vHoj2v0pWFB7vdkWKRROyz2670gtsFCBCiwCET8yHvQgEUa
PQDL86fCQoTkYPG/dsMifzwEiw7bCov9w8HCmr3Cwt++FCxPwgt+1uFDIGzA
J3id3zXIOeAYyUB4l0e8E//2xnwVMClDXr9vn3ULhWK44BmPc7TOF7eDZ7+g
W6PB8YjBMpNDxR24cZe1Lx7nVwlzc7Opwn6TuXmHAL8r+hzynKyfZJPilhwT
osdR04kYj26bVl6yBYioXlMoiQkPzDF/Y6MNHEU9y2btyFbMFh0Ux4Qfyaa6
moioor07xwydBPco1APDsiT+HBhOHAjA5q/jQsy0tOlUDc7xuTQt0Qvm1BWx
DeUTks7Fg5H603TqHGljcStuQUQpaPpCELI4cXZZqu5xeKIQ4pythcQBWySz
9MZNJ8WDnu00tdVvMbg4RPJ7z0o1ndjzuMRFmHYdyHSit7qL0tIKzoIXYvRE
cD33pgwfmKh9gUXFYEYqCypOYzzc73WtPAsa7J2Jb+d5PCV50K0Azz32BP1y
BWoVCDT7Z+9PkWjntyHZ8qlJWwFoKV1eCGGlGTtsiDoOZyZLkimaaUUcGydo
UbQ2t7o3UmZNYumMvAehfdGsF+qP4N+meYV/zdHavkGGeDYTkEBDg5Mmi8bo
Ku8ntPJqKEurNJ6n/8lCiG/BrXGJQC05883SYRe+8Tlhg3PDEm1FFuGznyax
/C8QWcKz+JGwSKMvDQvugSfDIo2+KCwgPK+mS/7j0R/XSHuxn9rX4HG9F/tx
sKRLlMoG+hU//Mh70IBFGn1pWEDpn3iw+F+7YZE/HoLlab0YCUNSWPjbl4Ll
SXjBz6eIcu2y3KbKcqcYfkbRZ7z7Pe7aKeaBPMeWEmCHRecR+gKP0IaIdzz+
K4gPqISvCjQY1INE0F89W83NQXaVFnmGfBYU/+PTveOPBxtyfOyMULOu6bvE
L/iQQK+YleBqETL2OAYJSnRykrVmwNQ9ESTNMji79M0z9les5s4dyU1rgkH9
EMaeGHR3GlNv5AlmAaRN54ejx47eEzdQrb9j9if8T1eb4QEvxRN7kUb/gCfZ
P9iMvswaMcE+sRdp9I+5Rv8wM/qnnNAJyz/lhLDR50oK7aLCCxUV5OTpjNkY
kFwg6jXpbHBYqns1jKLp3WNfx/C4Vlt6z1pGNAoAPUNoCA/cVxxOhMflNEe/
YamqpPWf8FlfGjJtN8KDAp2UjCRxiXEQ4/zG2ULgpas0X6EcgIFMHBH4lXDG
78QKYU918YriXFhw8u1dFIlWtxWsVBQgg4znVe4FJo9m3AwFs2FEdgmK9GVi
gytrETESWeYmGUQhvBNPTTN2xwtIsCD6Dn5rMEDRSyMRG1698S3H86pM4yJU
eRg2NATSWxA32/C1ky+JzQwcsSaBqC600g8AZS+hOlHVpIeIxuF7vvXo0Ky3
xC9sIGiLWNCr1DehwBF247NtpcWU6flXNZrB88A7DwlMZUohogWOzlJiu4Wl
54e4kKNSnMVmlXkUGNoWD/cBXTSbRKIBYIMsV8UyL5OB+Yn80F2xPGm7Y0ps
JQwIBja6OJedepwLOV73Ld5cIBTtASHSr4FevfEl3s9HZhApHfiHA8FcHHAU
AUe2sZIifyjcHt32Zxf1cOcgtPmbwEYbF4kfwIwhGzbsWb4wyVGc+zsKaRT9
CLv54eNh/yQGCuVYbBwJY4CRqm5dBDR1p1E8ZpGeX1RGgj2EPdWjpWm0XReA
TU0kAAStZruTSbKsZNSetYe5YGtqIBFnFPgBLDCr+u84ZDuXkJaI3IyUGlSk
JfYUoL1IqlVBvHeJcyyv4yUNw4EYeBwQz+b4FpmBKlnQ9Xf5NR4XPWt2t3tP
IsntRpUu1pPB+QDjPFeFGPk8i7aJp1PaK/wymhRNSwwhR/d6Kuo9MVIMMq4r
caB94UAY/nF9kaKVFWmMchoACRKwh/vLmtQ1OAf6kH1jiWl+24yrcEFMGN9y
cJVYszvzQCCfNUuoa2Y9HSSAjxl6XhBY4oUOiRs9txqoNxeFmLEp8MbNOqDx
gWCtHvKK2IrNGoUJ9iXSZc0cHVNsPfB9tvxTuCFilcPtkqmOHhkKMQBCKap0
sprHvmuBvSQ246OFC0l0OQNX2GD1rpXrWYz5p4ZQIB865XKeij8GuGBJaQN+
GFGaIZ+8zgniElND9FwNscfHp4o6PQr4MpM5ZRJgfFDJERd7xx90t0qszdnt
kgM6YZcn83TKAZa+bycyduPGWYmREboQCIqQ3Bgxn9Pq3pokrdSav7v3PTKo
j3BAVLfLRJeVp7iXw66/iD2ZY5zAjktzOV6Gg+G/ASjTRHM4FCdNhoUP/n3w
H/8RvN7kVkDOwEk4qN56vPzd6JhsEIH6TAIdKbqbRBN7ZqLYYMM5UyJcGKIt
bqjnIrhsjsosvUk4iahnOFZufMsApbwBTejvu4jR4UcMzZfc/E5riTWlQ5AX
Xcqk6KKQGfDg4KCNgicHcVX4Bf8GlBe3Qjn5JfAEyrZAgoBhb/lMHCI6XsFE
qqT0qYdTINiERPSj9Nd/T5D2KYoT7Vk5cSNeRWKgPyH7meY2yyZIQZh5eUd9
CUglhODgGnjzcrA92GT4fE6c81nu9p+NKBLBDpZI44M0zYLZsAwkNBayZhQc
MHXVJS7I25KwEEQcH/qRfdprqbGTHp1eYz5LCfIW7DVKnNBJK5IJNfKW4NyT
xWiAZ2UN8FY3L+6TXYFIfNUYnRVErQaOSBueDsRP2RZ8GMCWTzFUkC2uCUff
lLxiQE1mXUkLySolB5xx7vQw8cpfNXvgvdOQZI6g7wQS8SdIshoEtz3xQ5V/
+xWzeNjnqwkkLAo7zlpJsHSRLHJMKYA2FxK3Tkcohe+ivRrgW4xBUQN6onPU
J5vAPWmxaCVB4cc2d+m3X4vkXJzWkj5UxJgpZiZqxa5K3cA+qLASKGLb0w6d
sMUK+lNaPmLBoA8o5OXWzcq7m8NiIz9z0nLI3349CiedY7QcBi2j6CERXzUl
LJTQXw62GjJ6PaKMt7uNlyCYc5A1T70A2bd4hK4fYUwsSwLeKe5rhyp7wJ+E
xZICCvdCXtJkq2ScwMc4kV9Er9c5TNMS9Ho/bs7rKzxRmj17SY9+S6u3i/pQ
elxs1IjeJ7WG+qCc5lxWTTQXfQYgB/H0tNCquMnBP10VNke3kbhFGaDIeebX
8W0ZZgbQ2U2H88BGHq4wC4yyq0gWyZJrC4tiObXboEe/s0hEDGycePp4fJWn
U7ubUk9zkx7LgUMCihmKgaaO5adDouQBfKqgJsSVNPnzDYlcKiiZdRCbeubD
8QeQ6FDmsfrLOog3GxrQCmhcLOHs0ED4dRB6NiS1r4FOidElxKtvh0TrWY94
pdvEVowjolM5HbYCwIPYtXKdy1yN3snuRrFLHstOcjK008QR7Sw/soyxom68
rdcldONutXhnwcvh3X2XbLnD3Q+oKp6nJWa8egthVU6RnmUvfRSt8ogj+MlR
lmYuE61ts9UgsfvHEqnLQCOxM66Clo527LEsoRzLORJ97HKbinzu45TkeGEB
08RZeUR6bybl9HwZlhqVLnJ1CGseS6ZCoDBr9pQ76VWOatNBug6zQIwW00kU
hRMmsrIRs6Vm2TIt9poEjUjw2K4/MQ2+QtEFsG23FYHEtI1UJtoqQIKkyMIw
z/cxpIjrpW+hWB7YrBxFYNZSTUQKLXKtKQ2OyuW8NHpeaj5enIUj1t9za7sG
5xRprLq4a+/xwd7+7oOHo8fqveO5jCQd2mkx/KsY364lOp5f7smP7wMp0FmD
NIAKgOMXWShn8iJBTg1aYTvfyS1IkQUNYBLhE8XX7DY4DO2OY+q0+hVn5vJ2
IWVDhKMShnXy09mPBHLzIAtzg4+RwV2nVrAIKaHyQbyPHiyD9VAkPWrShuqD
oaTef7Dz5nl3y7TjL5uk7KEu4Q9rdSp/HoxOp9BYPFrG16IAsIpLCfbEjz3G
Z9WhtepyvsY81KooDozcmWqddhMkqu27RWoEk+J5qOOwea/0aENkD2/1fZIW
mTX6KlA4w02iWqiklMY2rHUclzBHGzspEQ/mA/kKSs625HRK7wCT3Nhjte/w
0c0KtEoDKDtHbBEm28R+Mq/iPllf1vf7ZyBFCPjrmEnJm25dsxmtM8SMV+lc
omtbKpeIeXd8K3s/UE5RS4IvwYyoP6mIAVB8gy3Ofuz5LxIo31huJU8FWNII
7uNYP6m7IWx3QbviOpnP+8zo2QJi6QhPk8skWfq6M8uXDcoPTPPKNNQY09jw
PrWzOlD6Y3TvCbaHTKep+pm69q+IwUxv9qxj2yKf4ugU5IQUMXxb6UTIknJH
g76t+xGmjmmXvEVc/RDMiY7Pz+1+agoDANGHXOsryGzFzqIOjcAdojvE2hWs
WYmYRztbPAs8HqVa0dV7gKnu9fR1MmVZ5uIPzSIJKwpS2IQ4EWoKuSdDeZ5C
Se5aLaco2DrDFzaxmyDw4IkCBMIWlz7h6HuAE1VKX3GNPEoChSbLm7naadkO
Wy1eC1ce2EWaXCmIbO0gK23NokKsH2OCAx3aiQHiMKFeAmdL6QQ6EbE089x6
Ca741EqrzzpRa3hpGVANMta+rUJdU44TrUjT4QKb/j3meINTBbTKHieLcu6O
deGKgdTbtnPX2RgLR3vNhIpanEW59HYU3/R3US75oUj73+Vqh8ZvJ3lRqWjW
KNdQcQmNiyKpu6SIA4Bu7TFN68HiVronU66IknlysSqS+JrYFnT9c89z7nHc
J4jWrVITvr7mkpzxzZ5n6m2iN5C13GyeqVLTQDHhMqYyB4zYP6Lx2WIWmc29
r2jZiCSuaDFzrYZAW3WRxJmogE1LJmelapGVplmRJDJn2QnUsoaV/T6LI+dB
o/cQRL1S3Unarw1dccoaCn8wd88p783Q8xyVDYW/3Wnm6WwqFVrqR8xS+Y4/
snlWol8TyY5Ah0Z3vEXPoszafYXPFMk5FlYkVoP8VhlSgmXyWOBh6YRMHTPX
vqETKLlxXKy1wUoDVDhFGzv2vMcDDjn6L3LEByluz/W/7pH7BN8oTu5OFtTc
vXsP/zu52z+804IUd8ZVdNC4QFDx8J+7yHiRgnf8P/ovS334ty0CUYspvPts
mHXH8Liju9Xy7k9rX8dfj9d6dwGB3Pl1BDphXvt68vV07edazGITZjcuUNed
eYHj2hfg6EWviHxzPOVz5ysLbYPL+qyS3LBHiwPM1uQZxw6I82vtFwop42Cw
oBVaq2oc0/OA3q/WkRVCSkjQQUpuXdhifIDJtqAUZoyEITkBZREUEza5KMM9
A1znK6BFazcd1KUKDpvnWcr+CFRTqZt2n9ZLLNdJyjaqhJgvfGHmKwntfMrY
cKNCSpKIwZdYCZoAPCs/CWNlUjXdYYA8BZP5wypjf7NaDDuxosXgsDTBbUWu
rYZMpktJnOL0rTDG2B0u6Pu0Z4sgb+DFjVQog3lqgXPipYslCANUxCOZxP4g
Io0QZLi0jpkRyIQLMbWjfOqqMQHiX1GLQbAetF9EFR8noAlkwj2bxofW8KrA
9Pr+9K0tpJexIxcxF3qXOAoJozP3jj+8Y8oCbvBvO//n8tu1pLoYrjl9Lqgp
RKfAm1Yu/PA2r70a8GHmH23MmHhxnRHXOHE3OyZuPGi8+gUgtyTmxiaWvDZZ
40egP8IJin9pwZgWnqp8ExjrZjtjDZiq15pJ2rbmsS+//fMaDH8HZLq+ubUB
fwE9fLl5hzx5Lz9KneVUUr2VptBHHKQAaUK33yrI6W5QG1NpwKpix6wGDX3U
iRPoNVVWbdtLEcw1XQ023EYtxkRN9RVe29qRxywkiGp4s2n+zexsiBrtyp1R
4IVKxvbl4bahnSYayldAs436q8rCAvalmgmrPKQj2wb38r2SzVqcKu5Z/rDy
JfNAEJCt7iGdIgeyEqkoedQgsUKilzqFockai+eCMqhO5q7UKqTqLWXNqumd
TDoD7+Dg8mF0HMYd+gktretlWDthYjG72N4x+Qpdft5ZwHaZKQyyZcsosSYn
UHQdUnXjP0arNIJXfe3oFBqNevTPZg+rLd/c9nG/4DT526mUMfL0pXYFxYtj
Vg+jC5lU/wjQIZzNlVoBuEaa3Qc91SfWmOfAd8oYB06LDx37GawZKSWGo1Kx
xXb1RCUHLMkYRL+qFqwhDKQ3vzvcD/RUS5dWB3BF3cTwIfASh62Bq7MarDUV
/4Oz+LxnDmd9OlPorw9Ajvr1fc7xKkQhfKjbR6H+KmggrUe9VmSCCdR4qx67
wm4NA5bICZ5u/bBPy0S2mFLNj8oZmTcg03CDd3slIeHtPJ9cRtFPHAkqod9S
DZp+E5P46+3XGFglVrDGCCLlSX3riRiw7oW0jXLHCeflk8sd1lZ2LywqSZCW
ENeE5bdRYsRgy8JKUFFYlTtW4xNWW6BqqGwxYOMgvDOeJ368ht94EHER1KBD
m5IphdRydbHGGFdnDZaoKqjqDg8WIbVrvYvSCvu0QsdjrKaceNWEsRh8Ld5Y
XrLB1d1sgc4zpEqPx6JzYIw3BbRsdkJU24YPAyadSW8R36SL1YIFTZ5gWtoz
7gULnugCCcwUQb1F9ht4Aafivrae69hyODfuFH0vrmADlbPNgPWuqEK1mk9I
cFgiJ+WCp/lU/ehU51mKMZxSXEwTsTQkcbbMD8PgI4VCo2KqfU1gC5WJ4dRi
SqoGB72rE6Hn++Tc+mlcyQ1WA7XGbEI2A/AsMGs7McRF6BIpfcj7H2Ukn5xe
77z0yCn2X9N5E5r1lHAuj0UMFA1niJt17nIYBjYto7IhwKVM4prq6msiiaOP
MOD7seOAXKLFpb2y0nIiVKqsOnzSHlCOAx3pKQJwSKMm46ETxR0o+tg/VJpG
c6sPkm2LdDeCHqSpXhtMqicHG/GeQ9eeHmTT7D52w3Qfi27lMJSNR8L7aTLp
81eQyiVLz8uUt0Ti5fZjFFbiYmmJqdqopVpYXVBl2XPxiA3RKyNpwWUg+jIK
/Oj6DtLVh2ZkNs0LkNC2zY55aX5nlRMjyq4JVJbfc7vn/fp/Hvpwu7shjDi8
u7i7BMUss1rkCQZlguB7+COI8zO0hWwYSbf8zPFM+HkwnVhSh+9+hxmanGUN
CPj9neCFHzFy/7JMrwQ5v7cpx0Z/nM3j89Iomn/XBzwjOg28q32VPoItYn39
sH1qXZN/rnMuHRbvzGXqyvTUHtuv9EGE331BKB7+dL2ji2DasA6AT6obRTwt
VO1nWrBaLq3sB/G8h/m0/NDW1GCtOmgQqNVBK1OL0/dCmTVOdcePUyV+0JPr
BJx+TaThMhBYzGJpUJRlGdWlDFBWABIZiy3sRVvknfVyUyY3cQTRgcARzlZi
JtY8HGAIsbmQ7Eh42qsZxNiDPbGmW5/AJMYx85xt3N/l4/qLqTeJgXLT6qgD
nIU2zzBuAXfnumUsYXGpH2FpMInUgitmPZLnM/OtGfbQq41dpNZlrz59wDlj
kkL7Q8sEtpDYugZaWKK187NVZSmORuI+ZzpYz0StuPVyFkqmOuel9khpmsAJ
S2Xdbs0z0Jua6PF7tgggZxrIghgBpFHrQnh13SXIGXJystR/qQVbhlvGearY
5evq0g+Q6tFzv8JECfLHY0x5giFPqyV2uyUewkkFuE4mHKrsx7WjCCL4CLYM
X4/Di5dqwhcsV6+ODad4wMOBqekEkqNGzjqKl24Ec5XNset5w4s3ERXL9vkW
beVe/SkCWH/GDLDt8UBNgo9lXhJ/JYJvjoq2nRNwhBXQAFrtpSwP5kW5uBmr
CoZ8WfChIZL2BgXnVAVxBPYyCVHmgH1MZT3ZwCM0krWO6jGZBLIX6S1lD2xd
ICCaLC7S3JMXXRFdWxRRbv74A3AQvCWlxLiByFaOjM3JsaetUGAYxm5r2QaN
/+XEU/JwLJIpFmHHm0gmKFHPk+m54w6sj8HM1XC7e9Ln+fRHjSLcrXpo6VRD
naEtQCRZ5aOoYY8OzNGdxuiaw7DhSRBHAvsROt0I9PVUbPN3UcOjIP/lY7PT
nYBf/4T79Gfq5QvNKEgCQf+AGd2NUxhrOLrHvVBz4HIvFKxIM6Jeptd3RI2f
1wv6n3f3vu8Z8T7jL+rI77f20oFd1GB/Nuq1hgcWDunlrAWW799LL1uKlyF9
f9KMKI2VenklvfxpOBgOe+7llpV+zIxIHfhsvGwPhts/34MXswd8Av7nzegI
9hR9H+1YvMCHXUIvTdMlZAc/6h/uay++y1/ohZyEgt3RQ9j9MjugXmEm4ECu
uLAG091ULRVAbBgeBRqjG8qyXpsu2zB0UkiWhC3L/guT6/x4ZZFoN3f0wgo/
YFTSQ+oVTb00pjEassqLYpVdIvjbLCtqUda2mK4zP3rK3dlhY3HEbaXCZkdY
oDUfIS/0LBxG/ey+QZdteEGd1iChiboH7oCmLYQ1mdLEnXDSfTWGl26x/joI
lZD14WrOeKWkd5zb1Kp5bueIVSu80vKnbERSOF3VDQ5c4l+95p4JEg0tUj7D
y8KtbN2AtBTxyloQcdu5shtlhQ5IwvBLnhLvG1ZYdm1i282thrHrdWj29P96
n+wlRXJdpKIwLBymUJwT+xlbnxDP7l4nSguLIs/uExRGCW1AfZVqnDEoThcc
h5nPpYgGADsGuqKYLmcVkvqF7VYhP9wbuzjP47l4/i5QconxniouNGzjS71p
Rmw95KsAQXYY081rjDSbqUvB2k4EN5o2q0G65PpCGdiaNX0YJYgNZSSslXeC
FY6IjSA2j6k2myBEiJT3Xv1tuwVL9LuQIToobCReB644gGk1sVwbWZ+M80Wm
lSb/qgJkjdB82w4XfXDlI0F5AeRWIA3GeCMXOWiSsLwJA8/T0k0XU1gxMY+L
BPBs4/DYMntOZTYClIkMTuqfCsvo8T32gs792UeSC9oyX6mnTgMOxI5BVQv7
VBcPb72cz1eYI11pkHacxfPbMtUAmjBBNC7krjKnzYvqI5FbLzg3Lym/4RIc
5/A+3YTizPGURpjPfHun6soyDChD5l/MHiX5HbwxB3YNdMRFfqU1khq00nNt
D9+QaH6OVU09w6eDm5BrOdPu7r51JHnbTqjDESN6eHI1UQPbnWFZpypf0dVs
qmn6NOCB9ANer9wE5RGd8HrgcccINnT7I5XEttoXN8hbbidr07elkd2paiM2
Fr5vAp+CnxHi05/bcRQxWxXIF5jPaknZPb1b84xwK1dX+jmaadl4mwMYaB0C
QCVRc36rlmu/yp7/OS7S8xSzuYmIT8gt2Paq2o+ft4pM4dUNTgK7uqvuQES+
48hFimktz83hdKAS2qeMhFUD24cTsejeT8eY938G94ypLGf98OCHoGZh60j3
lMMcfIn3G7Kth7hWGgDB/Obdu3vR0omdDozc/2kdiRudyM0AT2r0xJEeWmqp
etqxXfDzdf3Bn+95u/EyvN75dsvL97ze+rZ9n/mcXIuEn6uuUeEHy7ij5v5r
bkDX1O7RyNvsmMKE+72x2107yxAeNR5tvnA8+v+B3ZaP2vn2Zhu7Yw90vzIc
D3wGXXD0PTgcNwiZQZNY4V3ceDT2fbu8/qCNLz6nPsID7L4+2naOh4N27tHo
o7ld7yLHULqn9Hg4HtNHK7A1ld2T51RhV/WHA2FSKaRmZXE1RVMTlAWWukVc
DGkoJTpzsfQpMqqKS7o6XpF0DrXTjr1bXvzNy2pLrue0tfVOSRwBHWaaaOU5
d78tVueYxVj5fbpaLG419XUXtYMk8xxtpdkajAYvBtvUxdZgs+F1C8UKHtUf
isy9M7qG1ktV3ZPrsPkHja0gb5ZWbkFNxCs4X4sq0sxNig+TH3s+Iu+D6d3B
2d53LUCJdzAASj1Uzg/UkGYDMdGuhCwzWxjqPi0fup7E5pCsrvIsGSV6gfMq
6F070E22RAu7FNdDtUpv0VnExSVVTNjNzO4BiOfx/Bw6qS4WBoNTREgvwxnJ
BZSpSv4qzpatIilqgPEiqaQQbc+A7Jqpt4lSMFiVcIGVaPSv07F/HwEu+h7d
2CO3sGNRZB4cTw+dW+jFtXVoQFN0KtnUlWKerebzfl6C7JtQvOtu0+K1PRrt
MFHD9D0IpDisU2UtqijcKUPzjJTnFKDiFQb7VGrmqWJQHp1hiBWuoDAUGqji
2cxi2VOW2Ori9Cm+RNrZtJg261kYmmruZmHT49BMJr7gJpzkgqWo7dSV08im
csU9unMKuhHLaf2TnG+GdupooFZ0CBztnydKGE8ULJ4oTzxRdHiilPA0geBp
YsDTDvynHe1POsTv79odyI8KbmH5wVG0b9jgLeW95n++885TK5U0X3tudsPt
cAbboflaJ2wPR1CxThRKHx5fqgXRaEjlL15wvc805B5h2pYlG6r9q9ooEPEB
XuKXgBLOWztAuXaJa9GT6iSeT9yDiTjrWfMYpqDaOdnINCk3oajlZGrLCHMA
z/130/mXzQF/2kQrNhUTI1sZGbM57LvgE5yTDbgwFAX49ZxPgUnGi/2zNUiI
V7kf5Dy8jm97XZDJrYrhJed5YD1ZqHnWBE4CZ54PgXY2HuTbxOx9Uw4D32J8
ldOrZiKiiEyuNp17F9V6KOi8GGngXwgXWmbv+wgB/FN3/Kfu+I+oO94LgHza
dUfq2xOrpG8X5fvnDog6DpK71j/9z1UHDT3vatl82bfFdYzSTFT1uIMJ7WUd
1qJmF/5xpV20QPfUieBbHpc2j8DinW1Yg+mhhlefCvTTcS7hRk/GdNfG7byu
qY3871qSowRpDNezxvoeODmCAouDjp93QRIM3QpJ24SjLhifdax3BxMJJ9+B
n3Y0B5C08ICOVe5iIx3vW2Wi4+BQsmoNxvbxEwqT/i/7aXwOOjsKll/ZgME2
J3yYNHHOIXyZDXqQ3JQ/HJzZaqqxS7wr8RHVJSa7SmQzeTjqT+IY+nxLslf9
k2MfJvN8NfV/5GCIAUmXNuoCxRovYc856X2ZzxrZmKE5xzndXeTNF8MepqvF
UkUqFopLSfFDO0+BESKa2UW857kmrUhwL5Xmcxl7zw1e9GT8H1FsRLjnILSz
Hu7ifByOQbIs8pt04ZsVIlW1S7XB2IGEAEBYO6ZoUzQJhGEEbFfAtdIYE2sa
gYf9KlksSXonsjquGZreRN/WP9HwZms0HA2Hw9GrzfH45dbO9s705XBn++Xm
zujl1kv8dzuKWPd6I29HGBZofkwKIOIhxsLtHX8gesZu4B+Q8izzG/IHHyt1
USjcyKwBwGsRdEk/f2sW6RS+vNqEP6nGJiCBhSUcthM0kWZGozeYNv+Xk92z
7yKOoYRuABsYAbAqkshDBgidbBJ5A0CNXmqId7ATFZlB7Je3RXDXHTZ0FBuL
JesEeDk7+ICN9LkulvzySQu2M9ra5gWbzV5svnixOdx64S8R/u4v0QiXaHfv
+84louWHx6erCepweMmphZgWa+e1WdscDLeVC9y/bCTfWcbNxstIviJ8Duau
NRnWovE8ZIXBeDX8Bkp2G9fw+ae9UcipfPG8ACze+jcZxa3BKWx34yi80vIu
sUHaKvC/aD16itBwRdfQRu8YsK+LE5R9gtxRhV6LNawFOzaiHWsns/eXCsy1
4GUvetloHRQ5u46O9S+KYL6749jlegipH0OqtVD8I9H7647jlushm580iyCk
VmNqsajJyB9ZAnRdAKkGj9aDcrWH6fXdn3Ze95qwe7OwPXThYfRi82d96Ifl
cqGsx/TgP2wJyYUeJv4sbIQmtSU8eJzvfjx8/loEO9WjX92odQON863xy96W
RK4beNmczSsfSzFfG5kkR613FPKmtJ45V9RdbVNw5jbZAIoFngjM8W3s4iOO
xb3mLTF6XMLDiRgqcIhVRyqVGxcGzGWsWl1AGJ+LiVU8Zs9KYM6i57uq3NV5
lPtDdiVJo1z3yzYz45D6wDXP0VJy3STezdWcxmFZ9IBJL1csDd4Kg2SvQp8G
IX9IZzn1CitgWGNcaEhcrEpX2DatWguY+rdRNpxYJBnXrZEZZUOj85Qix/LK
w6/ezBQknseLfMWJhME9lV7co43uFPfwrZbr9zwmWO+XC9myNCc/JzdcgNCz
vP3lEz+PM163f9hgUbfjPanxZ40McsKoS3gzZn2kBRz+e0YOZU7kFY9s/Fkj
06dz0i0S6+NHbhFtvcafSmB3UXT/sK1hVk/5vcNI/ZndXjV+f8xeqkH20KcB
xJ2dge9EfqDJJ4yCIvYTm3zCKCJcfsvDrfMxsnFvk/UPtcrjbMPZ6G7yd6BA
Pt/cSf7g+2Ydk5Jp3lsbjye0J28u2/TpXOXOb2sDF/5i45QI+nizZdVqbTEk
AN+dbG/NktF468XW5uuX4x1o+aqN/959KZgnzrrGoDYBeO0B4LV9MprrhQ1a
pUsVSpvClIqCtUSTmsrfKbmKJhrGiInYWRdZ61qrXvDVep/xiGrGzvPsfNDw
NxI3JSF0KUKIu6PCSpJcxzot43l6ni34Hh1bbPoCYJomk3QBohLff6NhPRqf
Q6WnseyO+0mFVw4SwvCm+4RAkZ9VMlNkVFIsoGSRzKX2PisDOxtmGYyxyHPZ
kLCCGvP/26WsrW1nDALWttMuVv33jPwEw9EXHBk/s1nNzvSUxp81sjEW290h
7S2NP5U6/weIaE/djQrXUz7+6fOQlNbV7lPHQwFq9Hr0+vVwc/RqeP8efGiU
LwAO2eZFuntau08cbzhm+TGVKvuYS9whJzbHc2Zh8/vfw6m3Xl6kMwos4t21
8Vg4AQr+wL7kQzFs93fedX8PsfRJU2pssk9mhs6J2iWajoYTUIAnmzuTyahl
P9j2Kp4mr+Nk9mK2ubUzSoaTzdcd4mmj/efCXxNTfbCbII22FCZp/8nof1hk
VVHxqWJrl2OkHhRn1iUGEJ+r32GD7XMqvjbyJkvrx+DGJ5on2XccV0y5CNo9
L9Wl5jhw3IbW1tKcJ1nC4eBWFFWROkgFt8V1Whw/6If2QsKzhqW35EJgXiye
3P+icXdhpr6kAnh49T3RWlbipF5tsMWxJ67YTfbsTV8NXw1fD7d2XuxMdl7v
bO8kL7dms6b+FK1vbgs51ry0m0/30pKjMLCYbZo1zP14tJu2DWzYMUMFUWxf
m6M35vjt/z3YO/vL6cHeDx8Pz/7dOm1hoFoHHhMcvsY3hkMqz4jwvNOiY22c
8sJcGhNy3OEW1raqvRxAewnze9iHeZ8mG27qrt1h97SlDdwsLTIY/FLXQp9E
VDujrS0hquHw1Wx2H3cDctpsISfs4hM8yvhWt2rwilSDLU0jejyNwSzM+uYT
SGr87NnDK/pIpv+Ixa0z7UcscBu/1utDvdJsVHC9eauuuKGRb4FmD6juGQ6x
5qopnNXv6pWI85oqIuK18OcXFZwZ13GBJQ+xhFfMlSWwgEYEp8AV1dCQfBIu
AjLzYCspnnqc0l0iR8eN0rZ+xRcORZKLQ2dpxndclTG6oQggKmEyJlcQ3lQD
c7yibK55csMV/m+bN43xq/fdXzW5yHMNWdK7BCZ5NkvPV1wgwjfSiNvG6HVx
tlKKX87P3piVubt6YaBFXF7C8SVX91CJxgvAa5/LEbYWoQzuXAQccwUZXXQO
/OYaxlxUTo5gmFI6CYt06OXX/jRcZHpaaMF3qpSvIfhIH7YmhbsWkDypWrMR
vWdUj7BM5jOqqhJf2fr/tGI4b6zjADOnYKbg/mLv7mJ/+b3LXvRWIqZeCrtw
5Fp6RUFdyTkKS5vcIpVi8epS6ru8P/lp94OB/XaR5fP8nO4j8/DrZ1Zgfxzd
NtE7KMr6DdVafNzde9Fo0bYCFNyhdBQda25ArS2+w1UhvZFclWmVfy6TWy7h
LtJHkfThHMAqNeVFMpW1Iodss5ZHswSp3H7ZWDB/jcihbd3Z3I7XiIQgveAU
NlF98WETsZwE7a4vcnvbHPMOGukBDkGTwfL10HrqtqWrfmpLOfoiq5Uf66GD
LJh594Z4xskwczEsFtiItemMjvDCIlwcale8DekLXsyNF3VDegxG3VB0870x
N/K2Fy1iI2+sNmSbdMbdfNqMTK1aoAzmSgby+S/P65En9QAcrfPn92LvJlLn
1yf1goXk6LP56F6kzp/0shXMaPTYXmxIEffyKpjRo2Fp68XOCCSnx/Vy5Ft+
vDJ9hNyhOBepXN9oc8MW67u7O4KPhxc/deauupz7vdy88nrZ3jBeL2dnZx4s
QfXvGl5Q5H/cjLwC48ZIyUCvFw+WrQCWE/hwL8dhRWy/F5BznSIw5BkFePke
Pm29TKob6UXxAhLnI9eoDS+60k/uJcDLJ/cS4OUpvXwZlhlGxDsub0PhazYM
0oiccYPK5VGBg+YpEeb61cPI/Oj3po/O1qbtNHF0GjZquZn1Gwc8PeB+TQ6U
o61Xr7e2X8WvZ5MXO692Xm1vznYmqGFbdYh2AR9ipI5hizYjrNXVWrpDw6mz
vEZRS3PQmMas+aHVgHQ9+r/1kZSV7P/eCEx87IuHki2aoN+Z6jIjCZMVblHE
HtKsW3Bl44YVB/VKnm1Ktxdsf4+e/fTV2Ry9msazV1vT169eTF9sT5OXydar
yYvJCFALuNnpXqV71ujeTmtr1bFUdqXWX9rlkYDB+urg2uDi+GvyWN04QJYX
0q0T71yamsrcsTxtWvJhZlM6enp/Lwv3pUv9oDleo6BuL0C1AaXjW84gqasG
rXm/pQ1V1EBEfnvBQwjIeINpniURdF3vNewsnkzygrR0YUeeZdamCnzIj8tJ
PSa8o6b1EyJ4vSK4TTG1My6cwsJFuOTS1sj+O8TUR8eGUy9dYuonzagppoYy
qkio7TWcbY3hpoAZyqhD81m9yNm6+bRerJgayqijJ/XiBMxQFnsaLI1ecEYY
Qc8x8G3h72EvIb08PgQee9kLYXHCbiDpqpyrYq4JqlKrrNsi7IaSrgi6KubW
e2FZtxmR3xGS/xB2v8ymDpitx0UCLkvwii/oQy4cbMMF6Qfch4UriQW3/Mq3
RSrHbWSl9bPc1u3xqzZRjHjUTIpqvC8yFEtjelfT4w/n0WiL/jHf6rl731kp
sgxH1XUea5tRe9KYg72RPub1pCcJo9zKG0+a1DC2yVSPnhzNzpucO+ZdYlbH
hHcaddJbV6w1R+veme/aO7uwdhmbv/QyTwwCk1xNSqdCVhAkbaLdj09+lusj
zdjyczdR9B/joOqMwstSzeHuBywSxxWR2Noo6bLTfLKiaDnJzPBKemMjam2L
aE2CHszfsOZ12Kv4XyWfgQBr3ujhSlvLb1qJxKsrFfE+kAy1oFyVNPJq0g5+
+7VrrEisufYeQbqvMEb4CqpRQn9XErqHOXJ8s6Wft5rPIk6EWCxWmToXYMif
9Io8wEumd7XpOGynt31oseNoXU24vKg9s3/2/rRnkmoy2NAy1UGJXe5oHt+C
gldd55Ht0t6eiW+JnOa4lad9Hc7EXizpmrYvZ0C+9ez/ZftyR4CSP8kdvD+T
MJpmK3IVE7lahEihfbmc2I2lGOhFQh2xIV9+fl7Ey4t04rJf+l72i3dFaDjL
yFtwqlD+8eCPPxx+PNgnYkAcd/Tu59akZeRwDbycrmJiA6qbnrqGJNYVTrcq
VW+5RQhsxjk+XS3JH06YIAjTks3lnuDcEyt5+65SNO+MXvwcNdHc2bdnSs+9
woxy01F4AVbEF2CZ9cMfN+zV9lVHdC5FSWA4ADAerP+Edx/PydNHyUsFJ4lj
mOo0QeO4crHg/ofZLJ2k5MlY17ul8+wcoCQXSgTyNrw7S2823O1Q1vcRV3LF
Dj7WCwUQKOCayTUlcl0mtxHwgqTAy77W/ZVU1xoh4Uf2jSU3yzhTfSTGZDiF
FYvSReSb2EA6Ql4GXfNA0LOrtC5sRW4lLa27TWvtq1+klHqW8hqGdpzf9pEY
YdGvOMZixfyNL5MlVrSsMFQ5siiVmzfRl6WOTnVm2QJOU0YMRcncLNkTuyJY
ljFe6JUJK8B0/arC7MGCDiOApcjJExRTmveKSpSR0OQFgEi6YU4ZaNE8zS6B
c+Wn0hU726xTAhXCmPkA+n5Kmil0lK+KCZcAWy04SizWS2h1qLxAvNuy/T6w
dGU4XRn7V+QBDFEpdzkRSMxtbM2CSbykNoAgYkY9gBCjc1O62WCBJ/g0XsR4
wWhPJzKQuzoC4qXA7XrNwpatwn4cdBdGdLxJ/BBM6FAPCotQOarCI4736ty7
CyXSyw44UZvPFu+levUu/0QlegJ6halHzSZtW10HGye0OTjwvMKdjnMA2okc
hei9y0XBVSCaK2nCnY6oucgLIMVIIIHhshB8D0G1wx+Ji35wJ1U09Ut/cSDX
dFWQ9YL2C50V6KQsipxLaUyBf0ssFEKvq90ioxSkK9AF3UWyiJE/YgTBHPn1
ajmnG0aIz0XehGmIGi0fzoKld32jtQElNRQ1brNJL4rb2S9dgjL2UZtM3RXw
81tFvdxbhmstaE2Z6VsTYrka83L6PsIQdYNoV401WhIVr91VMYc8rFKADsMw
llMKVKPoPK0tAkyKirn1mJz0K+OygpU+dynGzFydo5cvkj5NFykKtt6KosOa
r7qFFSxSuvIxpyADmB+pa6vpkpJkqTAv7fdI5t0hT+AEUpRX5GYXs+uubEM4
SpZlseoo3sDMJrV5epmwFSsGfoMnTTxfXsRACxhXgIfOxhuzd1HgJYV4fc6i
XJUlssoFLAacZ+ZtXABs857Zi4sSuJF5SykgsPXpLC1jc5CdYzBFhU/yBUiK
74D0YRP0zPdz4KrmO+jhMumZt0n21xi6Nd/H0xWw43cFZpKUk9icxHOOVOmZ
3XlyA1SJV2Yk8/yqZ/6Qw2sg0s/5KaWFFwD7j0CCl2j/pw8o1mYc4xX3UfT/
AUBN+YYk3wAA

-->
</rfc>