rfc8824xml2.original.xml   rfc8824.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!-- [CS] updated by Chris 03/10/21 -->
]>
<?rfc symrefs="yes"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<?rfc sortrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-lpwan-coap-static-context-hc-19" cate <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
gory="std"> -ietf-lpwan-coap-static-context-hc-19" number="8824" obsoletes="" updates="" sub
missionType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true"
sortRefs="true"
tocInclude="true" version="3">
<!-- xml2rfc v2v3 conversion 3.5.0 -->
<front> <front>
<title abbrev="LPWAN CoAP compression">LPWAN Static Context Header Compressi on (SCHC) for CoAP</title> <title abbrev="SCHC for CoAP">Static Context Header Compression (SCHC) for t he Constrained&nbsp;Application&nbsp;Protocol&nbsp;(CoAP)</title>
<seriesInfo name="RFC" value="8824"/>
<author initials="A." surname="Minaburo" fullname="Ana Minaburo"> <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
<organization>Acklio</organization> <organization>Acklio</organization>
<address> <address>
<postal> <postal>
<street>1137A avenue des Champs Blancs</street> <street>1137A avenue des Champs Blancs</street>
<city>35510 Cesson-Sevigne Cedex</city> <city>Cesson-Sevigne Cedex</city>
<code>35510</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>ana@ackl.io</email> <email>ana@ackl.io</email>
</address> </address>
</author> </author>
<author initials="L." surname="Toutain" fullname="Laurent Toutain"> <author initials="L." surname="Toutain" fullname="Laurent Toutain">
<organization>Institut MINES TELECOM; IMT Atlantique</organization> <organization abbrev="IMT Atlantique">Institut MINES TELECOM; IMT Atlantiq ue</organization>
<address> <address>
<postal> <postal>
<street>2 rue de la Chataigneraie</street> <street>CS 17607</street> <street>2 rue de la Chataigneraie</street>
<city>35576 Cesson-Sevigne Cedex</city> <extaddr>CS 17607</extaddr>
<city>Cesson-Sevigne Cedex</city>
<code>35576</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>Laurent.Toutain@imt-atlantique.fr</email> <email>Laurent.Toutain@imt-atlantique.fr</email>
</address> </address>
</author> </author>
<author initials="R." surname="Andreasen" fullname="Ricardo Andreasen"> <author initials="R." surname="Andreasen" fullname="Ricardo Andreasen">
<organization>Universidad de Buenos Aires</organization> <organization>Universidad de Buenos Aires</organization>
<address> <address>
<postal> <postal>
<street>Av. Paseo Colon 850</street> <street>Av. Paseo Colon 850</street>
<city>C1063ACV Ciudad Autonoma de Buenos Aires</city> <city>Ciudad Autonoma de Buenos Aires</city>
<code>C1063ACV</code>
<country>Argentina</country> <country>Argentina</country>
</postal> </postal>
<email>randreasen@fi.uba.ar</email> <email>randreasen@fi.uba.ar</email>
</address> </address>
</author> </author>
<date year="2021" month="June"/>
<date year="2021" month="March" day="08"/> <keyword>header compression</keyword>
<keyword>fragmentation</keyword>
<workgroup>lpwan Working Group</workgroup> <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> <abstract>
<t>This document defines how to compress Constrained Application Protocol
<t>This draft defines how to compress the Constrained Application Protocol (CoAP (CoAP) headers using the Static Context Header Compression and fragmentation (SC
) using the Static Context Header Compression (SCHC). HC) framework.
SCHC is a header compression mechanism adapted for Constrained Devices. SCHC defines a header compression mechanism adapted for Constrained Devices.
SCHC uses a static description of the header to reduce the header’s redundanc SCHC uses a static description of the header to reduce the header's redundanc
y and size. y and size.
While RFC 8724 describes the SCHC compression and fragmentation framework, While RFC 8724 describes the SCHC compression and fragmentation framework,
and its application for IPv6/UDP headers, this document applies SCHC for CoAP and its application for IPv6/UDP headers, this document applies SCHC to CoAP
headers. The CoAP header structure differs from headers. The CoAP header structure differs from
IPv6 and UDP since CoAP uses a flexible header with a variable number of opti IPv6 and UDP, since CoAP uses a flexible header with a variable number of opt
ons, themselves of variable length. The CoAP protocol ions, themselves of variable length. The CoAP message format is asymmetric: the
messages format is asymmetric: the request messages have a header format diff request messages have a header format different from the format in the response
erent from the one in the response messages. This messages.
This
specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t> specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t>The Constrained Application Protocol (CoAP) <xref target="RFC7252" form
<t>CoAP <xref target="RFC7252"/> is a command/response protocol designed for mic at="default"/> is a command/response protocol designed for microcontrollers with
ro-controllers with a small RAM and ROM and optimized for REST-based (Representa small RAM and ROM and optimized for services based on REST (Representational St
tive state transfer) services. Although the Constrained Devices leads the CoAP d ate Transfer). Although the Constrained Devices are a leading factor in the desi
esign, a CoAP header’s size is still too large for LPWAN (Low Power Wide Area Ne gn of CoAP, a CoAP header's size is still too large for LPWANs (Low-Power Wide-A
tworks). rea Networks). Static Context Header Compression and fragmentation (SCHC) over C
SCHC header compression over CoAP header is required to increase performance or oAP headers is required to increase performance or to use CoAP over LPWAN techno
use CoAP over LPWAN technologies.</t> logies.
</t>
<t>The <xref target="RFC8724"/> defines SCHC, a header compression mechanism for <t><xref target="RFC8724" format="default"/> defines the SCHC framework, w
the LPWAN network based on a static context. Section 5 of the <xref target="RFC hich includes a header compression mechanism for LPWANs that is based on a stati
8724"/> explains where compression and decompression occur in the architecture. c context.
The SCHC compression scheme assumes as a prerequisite that both end-points know <xref target="RFC8724" sectionFormat="of" section="5"/> explains where compressi
the static context before transmission. The way the context is configured, provi on and decompression occur in the architecture. The SCHC compression scheme assu
sioned, or exchanged is out of this document’s scope.</t> mes as a prerequisite that both endpoints know the static context before transmi
ssion. The way the context is configured, provisioned, or exchanged is out of th
<t>CoAP is an application protocol, so CoAP compression requires installing comm is document's scope.</t>
on Rules between the two SCHC instances. SCHC compression may apply at two diffe <t>CoAP is an application protocol, so CoAP compression requires installin
rent levels: at IP and UDP in the LPWAN network and another at the application l g common Rules between the two SCHC instances. SCHC compression may apply at two
evel for CoAP. These two compressions may be independent. Both follow the same p different levels: at IP and UDP in the LPWAN and another at the application lev
rinciple described in <xref target="RFC8724"/>. As different entities manage the el for CoAP. These two compression techniques may be independent. Both follow th
CoAP compression at different levels, the SCHC Rules driving the compression/de e same principle as that described in <xref target="RFC8724" format="default"/>.
compression are also different. The <xref target="RFC8724"/> describes how to us As different entities manage the CoAP compression process at different levels,
e SCHC for IP and UDP headers. This document specifies how to apply SCHC c the SCHC Rules driving the compression/decompression are also different. <xref t
ompression to CoAP headers.</t> arget="RFC8724" format="default"/> describes how to use SCHC for IP and UDP head
ers. This document specifies how to apply SCHC compression to CoAP headers
<t>SCHC compresses and decompresses headers based on common contexts between Dev .</t>
ices. SCHC context includes multiple Rules. Each Rule can match the header field <t>SCHC compresses and decompresses headers based on common contexts betwe
s to specific values or ranges of values. If a Rule matches, the matched header en Devices. The SCHC context includes multiple Rules. Each Rule can match the he
fields are replaced by the RuleID and the Compression Residue that contains the ader fields to specific values or ranges of values. If a Rule matches, the match
residual bits of the compression. Thus, different Rules may correspond to differ ed header fields are replaced by the RuleID and the Compression Residue that con
ent protocol headers in the packet that a Device expects to send or receive.</t> tains 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 re
<t>A Rule describes the packets’ entire header with an ordered list of fields de ceive.</t>
scriptions; see section 7 of <xref target="RFC8724"/>. Thereby each description <t>A Rule describes the packets' entire header with an ordered list of Fie
contains the field ID (FID), its length (FL), and its position (FP), a direction ld Descriptors; see <xref target="RFC8724" sectionFormat="of" section="7"/>. The
indicator (DI) (upstream, downstream, and bidirectional), and some associated T reby, each description contains the Field ID (FID), Field Length (FL), and Field
arget Values (TV). The direction indicator is used for compression to give the b Position (FP), as well as a Direction Indicator (DI) (upstream, downstream, and
est TV to the FID when these values differ in the transmission direction. So a f bidirectional) and some associated Target Values (TVs). The DI is used for comp
ield may be described several times.</t> ression to give the best TV to the FID when these values differ in their transmi
ssion direction. So, a field may be described several times.</t>
<t>A Matching Operator (MO) is associated with each header field description. Th <t>A Matching Operator (MO) is associated with each header Field Descripto
e Rule is selected if all the MOs fit the TVs for all fields of the incoming hea r. The Rule is selected if all the MOs fit the TVs for all fields of the incomin
der. g header.
A Rule cannot be selected if the message contains an unknown field to the SCHC c A Rule cannot be selected if the message contains a field that is unknown to the
ompressor.</t> SCHC compressor.</t>
<t>In that case, a Compression/Decompression Action (CDA) associated with
<t>In that case, a Compression/Decompression Action (CDA) associated with each f each field gives the method to compress and decompress each field.
ield gives the method to compress and decompress each field. Compression mainly results in one of four actions:</t>
Compression mainly results in one of 4 actions:</t> <ul spacing="normal">
<li>send the field value (value-sent),</li>
<t><list style="symbols"> <li>send nothing (not-sent),</li>
<t>send the field value (value-sent),</t> <li>send some Least Significant Bits (LSBs) of the field, or</li>
<t>send nothing (not-sent),</t> <li>send an index (mapping-sent).</li>
<t>send some least significant bits of the field (LSB) or,</t> </ul>
<t>send an index (mapping-sent).</t> <t>After applying the compression, there may be some bits to be sent.
</list></t> These values are called "Compression Residue".</t>
<t>SCHC is a general mechanism applied to different protocols, with the ex
<t>After applying the compression, there may be some bits to be sent. act Rules to be used depending on the protocol and the application. <xref target
These values are called Compression Residue.</t> ="RFC8724" sectionFormat="of" section="10"/> describes the compression scheme fo
r IPv6 and UDP headers. This document targets CoAP header compression using SCHC
<t>SCHC is a general mechanism applied to different protocols, the exact Rules t .</t>
o be used depending on the protocol and the Application.<vspace /> <section anchor="terminology" numbered="true" toc="default">
Section 10 of the <xref target="RFC8724"/> describes the compression scheme for <name>Terminology</name>
IPv6 and UDP headers. This document targets the CoAP header compression using SC <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
HC.</t> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<section anchor="terminology" title="Terminology"> "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and are to be interpreted as described in BCP&nbsp;14
“OPTIONAL” in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
<xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they when, they appear in all capitals, as shown here.</t>
appear in all capitals, as shown here.</t> </section>
</section>
</section> <section anchor="schc-applicability-to-coap" numbered="true" toc="default">
</section> <name>SCHC Applicability to CoAP</name>
<section anchor="schc-applicability-to-coap" title="SCHC Applicability to CoAP"> <t>SCHC compression for CoAP headers <bcp14>MAY</bcp14> be done in conjunc
tion with the lower layers (IPv6/UDP) or independently. The SCHC adaptation laye
<t>SCHC Compression for CoAP header MAY be done in conjunction with the lower la rs, described in <xref target="RFC8724" sectionFormat="of" section="5"/>, may be
yers (IPv6/UDP) or independently. The SCHC adaptation layers, described in Secti used as shown in Figures&nbsp;<xref target="Fig-SCHCCOAP1" format="counter"/>,
on 5 of <xref target="RFC8724"/>, may be used as shown in <xref target="Fig-SCHC <xref target="Fig-SCHCCOAP2" format="counter"/>, and <xref target="Fig-SCHCCOAP3
COAP1"/>, <xref target="Fig-SCHCCOAP2"/>, and <xref target="Fig-SCHCCOAP3"/>.</t " format="counter"/>.</t>
> <t>In the first example, <xref target="Fig-SCHCCOAP1" format="default"/>,
a Rule compresses the complete header stack from IPv6 to CoAP. In this case, th
<t>In the first example, <xref target="Fig-SCHCCOAP1"/>, a Rule compresses the c e Device and the Network Gateway (NGW) perform SCHC C/D (SCHC Compression/Decomp
omplete header stack from IPv6 to CoAP. In this case, the Device and the NGW pe ression; see <xref target="RFC8724"/>). The application communicating with the D
rform SCHC C/D (Static Context Header Compression Compressor/Decompressor). The evice does not implement SCHC C/D.</t>
Application communicating with the Device does not implement SCHC C/D.</t> <figure anchor="Fig-SCHCCOAP1">
<name>Compression/Decompression at the LPWAN Boundary</name>
<figure title="Compression/Decompression at the LPWAN boundary." anchor="Fig-SCH <artwork name="" type="" align="left" alt=""><![CDATA[
CCOAP1"><artwork><![CDATA[
(Device) (NGW) (App) (Device) (NGW) (App)
+--------+ +--------+ +--------+ +--------+
| CoAP | | CoAP | | CoAP | | CoAP |
+--------+ +--------+ +--------+ +--------+
| UDP | | UDP | | UDP | | UDP |
+--------+ +----------------+ +--------+ +--------+ +----------------+ +--------+
| IPv6 | | IPv6 | | IPv6 | | IPv6 | | IPv6 | | IPv6 |
+--------+ +--------+-------+ +--------+ +--------+ +--------+-------+ +--------+
| SCHC | | SCHC | | | | | SCHC | | SCHC | | | |
+--------+ +--------+ + + + +--------+ +--------+ + + +
| LPWAN | | LPWAN | | | | | LPWAN | | LPWAN | | | |
+--------+ +--------+-------+ +--------+ +--------+ +--------+-------+ +--------+
((((LPWAN)))) ------ Internet ------ ((((LPWAN)))) ------ Internet ------
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="Fig-SCHCCOAP1"/> shows the use of SCHC header compression above <t><xref target="Fig-SCHCCOAP1" format="default"/> shows the use of SCHC h
layer 2 in the Device and the NGW. The SCHC layer receives non-encrypted packet eader compression above Layer 2 in the Device and the NGW. The SCHC layer receiv
s and can apply compression Rules to all the headers in the stack. On the other es non-encrypted packets and can apply compression Rules to all the headers in t
end, the NGW receives the SCHC packet and reconstructs the headers using the Rul he stack. On the other end, the NGW receives the SCHC packet and reconstructs th
e and the Compression Residue. After the decompression, the NGW forwards the IPv e headers using the Rule and the Compression Residue. After the decompression, t
6 packet toward the destination. The same process applies in the other direction he NGW forwards the IPv6 packet toward the destination. The same process applies
when a non-encrypted packet arrives at the NGW. Thanks to the IP forwarding bas in the other direction when a non-encrypted packet arrives at the NGW. Thanks t
ed on the IPv6 prefix, the NGW identifies the Device and compresses headers usin o the IP forwarding based on the IPv6 prefix, the NGW identifies the Device and
g the Device’s Rules.</t> compresses headers using the Device's Rules.</t>
<t>In the second example, <xref target="Fig-SCHCCOAP2" format="default"/>,
<t>In the second example, <xref target="Fig-SCHCCOAP2"/>, the SCHC compression i SCHC compression is applied in the CoAP layer, compressing the CoAP header inde
s applied in the CoAP layer, compressing the CoAP header independently of the ot pendently of the other layers. The RuleID, Compression Residue, and CoAP payload
her layers. The RuleID, the Compression Residue, and CoAP payload are encrypted are encrypted using a mechanism such as DTLS. Only the other end (App) can deci
using a mechanism such as DTLS. Only the other end (App) can decipher the inform pher the information. If needed, layers below use SCHC to compress the header as
ation. If needed, layers below use SCHC to compress the header as defined in <xr defined in <xref target="RFC8724" format="default"/> (represented by dotted lin
ef target="RFC8724"/> (represented in dotted lines).</t> es in the figure).</t>
<t>This use case needs an end-to-end context initialization between the De
<t>This use case needs an end-to-end context initialization between the Device a vice and the application. The context initialization is out of scope for this do
nd the Application. The context initialization is out of the scope of this docum cument.</t>
ent.</t> <figure anchor="Fig-SCHCCOAP2">
<name>Standalone CoAP End-to-End Compression/Decompression</name>
<figure title="Standalone CoAP end-to-end Compression/Decompression" anchor="Fig <artwork name="" type="" align="left" alt=""><![CDATA[
-SCHCCOAP2"><artwork><![CDATA[
(Device) (NGW) (App) (Device) (NGW) (App)
+--------+ +--------+ +--------+ +--------+
| CoAP | | CoAP | | CoAP | | CoAP |
+--------+ +--------+ +--------+ +--------+
| SCHC | | SCHC | | SCHC | | SCHC |
+--------+ +--------+ +--------+ +--------+
| DTLS | | DTLS | | DTLS | | DTLS |
+--------+ +--------+ +--------+ +--------+
. udp . . udp . . udp . . udp .
.......... .................. .......... .......... .................. ..........
. ipv6 . . ipv6 . . ipv6 . . ipv6 . . ipv6 . . ipv6 .
.......... .................. .......... .......... .................. ..........
. schc . . schc . . . . . schc . . schc . . . .
.......... .......... . . . .......... .......... . . .
. lpwan . . lpwan . . . . . lpwan . . lpwan . . . .
.......... .................. .......... .......... .................. ..........
((((LPWAN)))) ------ Internet ------ ((((LPWAN)))) ------ Internet ------
]]></artwork>
]]></artwork></figure> </figure>
<t>The third example, <xref target="Fig-SCHCCOAP3" format="default"/>, sho
<t>The third example, <xref target="Fig-SCHCCOAP3"/>, shows the use of Object Se ws the use of Object Security for Constrained RESTful Environments (OSCORE) <xre
curity for Constrained RESTful Environments (OSCORE) <xref target="RFC8613"/>. I f target="RFC8613" format="default"/>. In this case, SCHC needs two Rules to com
n this case, SCHC needs two Rules to compress the CoAP header. A first Rule focu press the CoAP header. A first Rule focuses on the Inner header. The result of t
sed on the inner header. The result of this first compression is encrypted using his first compression is encrypted using the OSCORE mechanism. Then, a second Ru
the OSCORE mechanism. Then a second Rule compresses the outer header, including le compresses the Outer header, including the OSCORE options.</t>
the OSCORE Options.</t> <figure anchor="Fig-SCHCCOAP3">
<name>OSCORE Compression/Decompression</name>
<figure title="OSCORE compression/decompression." anchor="Fig-SCHCCOAP3"><artwor <artwork name="" type="" align="left" alt=""><![CDATA[
k><![CDATA[
(Device) (NGW) (App) (Device) (NGW) (App)
+--------+ +--------+ +--------+ +--------+
| CoAP | | CoAP | | CoAP | | CoAP |
| inner | | inner | | Inner | | Inner |
+--------+ +--------+ +--------+ +--------+
| SCHC | | SCHC | | SCHC | | SCHC |
| inner | | inner | | Inner | | Inner |
+--------+ +--------+ +--------+ +--------+
| CoAP | | CoAP | | CoAP | | CoAP |
| outer | | outer | | Outer | | Outer |
+--------+ +--------+ +--------+ +--------+
| SCHC | | SCHC | | SCHC | | SCHC |
| outer | | outer | | Outer | | Outer |
+--------+ +--------+ +--------+ +--------+
. udp . . udp . . udp . . udp .
.......... .................. .......... .......... .................. ..........
. ipv6 . . ipv6 . . ipv6 . . ipv6 . . ipv6 . . ipv6 .
.......... .................. .......... .......... .................. ..........
. schc . . schc . . . . . schc . . schc . . . .
.......... .......... . . . .......... .......... . . .
. lpwan . . lpwan . . . . . lpwan . . lpwan . . . .
.......... .................. .......... .......... .................. ..........
((((LPWAN)))) ------ Internet ------ ((((LPWAN)))) ------ Internet ------
]]></artwork>
]]></artwork></figure> </figure>
<t>In the case of several SCHC instances, as shown in Figures&nbsp;<xref t
<t>In the case of several SCHC instances, as shown in <xref target="Fig-SCHCCOAP arget="Fig-SCHCCOAP2" format="counter"/> and <xref target="Fig-SCHCCOAP3" format
2"/> and <xref target="Fig-SCHCCOAP3"/>, the Rules may come from different provi ="counter"/>, the Rules may come from different provisioning domains.</t>
sioning domains.</t> <t>This document focuses on CoAP compression, as represented by the dashed
boxes in the previous figures.</t>
<t>This document focuses on CoAP compression represented in the dashed boxes in </section>
the previous figures.</t> <section anchor="coap-headers-compressed-with-schc" numbered="true" toc="def
ault">
</section> <name>CoAP Headers Compressed with SCHC</name>
<section anchor="coap-headers-compressed-with-schc" title="CoAP Headers compress <t>The use of SCHC over the CoAP header applies the same description and c
ed with SCHC"> ompression/decompression techniques as the technique used for IP and UDP, as exp
lained in <xref target="RFC8724" format="default"/>. For CoAP, the SCHC Rules de
<t>The use of SCHC over the CoAP header uses the same description, and compressi scription uses the direction information to optimize the compression by reducing
on/decompression techniques like the one for IP and UDP explained in the <xref t the number of Rules needed to compress headers. The Field Descriptor <bcp14>MAY
arget="RFC8724"/>. For CoAP, the SCHC Rules description uses the direction infor </bcp14> define both request/response headers and TVs in the same Rule, using th
mation to optimize the compression by reducing the number of Rules needed to com e DI to indicate the header type.
press headers. The field description MAY define both request/response headers an </t>
d target values in the same Rule, using the DI (direction indicator) to make the <t>As for other header compression protocols, when the compressor does not
difference.</t> find a correct Rule to compress the header, the packet <bcp14>MUST</bcp14> be s
ent uncompressed using the RuleID dedicated to this purpose, and where the Compr
<t>As for other header compression protocols, when the compressor does not find ession Residue is the complete header of the packet. See <xref target="RFC8724"
a correct Rule to compress the header, the packet MUST be sent uncompressed usin sectionFormat="of" section="6"/>.
g the RuleID dedicated to this purpose. Where the Compression Residue is the com </t>
plete header of the packet. See section 6 of <xref target="RFC8724"/>.</t> <section anchor="differences-between-coap-and-udpip-compression" numbered=
"true" toc="default">
<section anchor="differences-between-coap-and-udpip-compression" title="Differen <name>Differences between CoAP and UDP/IP Compression</name>
ces between CoAP and UDP/IP Compression"> <t>CoAP compression differs from IPv6 and UDP compression in the followi
ng aspects:</t>
<t>CoAP compression differs from IPv6 and UDP compression in the following aspec <ul spacing="normal">
ts:</t> <li>
<t>The CoAP message format is asymmetric; the headers are different
<t><list style="symbols"> for a request or a response.
<t>The CoAP protocol is asymmetric; the headers are different for a request or For example, the Uri-Path option is mandatory in the request, and it might not b
a response. e present in the response.
For example, the URI-Path option is mandatory in the request, and it might not b
e present in the response.
A request might contain an Accept option, and the response might include a Conte nt-Format option. A request might contain an Accept option, and the response might include a Conte nt-Format option.
In comparison, IPv6 and UDP returning path swap the value of some fields in the In comparison, the IPv6 and UDP returning path swaps the value of some fields in
header. the header. However, all the directions have the same fields (e.g., source and
However, all the directions have the same fields (e.g., source and destination a destination address fields). </t>
ddress fields). <vspace blankLines='1'/> <t>
The <xref target="RFC8724"/> defines the use of a direction indicator (DI) in th <xref target="RFC8724" format="default"/> defines the use of a DI in the
e
Field Descriptor, which allows a single Rule to process a message Field Descriptor, which allows a single Rule to process a message
header differently depending on the direction.</t> header differently, depending on the direction.</t>
<t>Even when a field is “symmetric” (i.e., found in both directions), the valu </li>
es carried in each direction are different. <li>Even when a field is "symmetric" (i.e., found in both directions),
The compression may use a “match-mapping” MO to limit the range of expected valu the values carried in each direction are different.
es The compression may use a "match-mapping" MO to limit the range of expected valu
in a particular direction and reduce the Compression Residue’s size. es
Through the direction indicator (DI), a field description in the Rules splits th in a particular direction and reduce the Compression Residue's size.
e possible field value into two parts, Through the DI, a Field Descriptor in the Rules splits the possible field value
one for each direction. For instance, if a client sends only CON requests, the T into two parts,
ype can be elided by compression, one for each direction. For instance, if a client sends only Confirmable (CON) r
and the answer may use one single bit to carry either the ACK or RST type. equests <xref target="RFC7252"/>, the Type can be elided by compression,
The field Code has the same behavior, the 0.0X code format value in the request, and the answer may use one single bit to carry either the ACK or Reset (RST) typ
and the Y.ZZ code format in the response.</t> e.
<t>In SCHC, the Rule defines the different header fields’ length, so SCHC does The field Code has the same behavior: the 0.0X code format value in the request
not need to send it. and the Y.ZZ code format in the response.
</li>
<li>
<t>In SCHC, the Rule defines the different header fields' length, so
SCHC does not need to send it.
In IPv6 and UDP headers, the fields have a fixed size, known by definition. 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 d escription specifies it. On the other hand, some CoAP header fields have variable lengths, and the Rule d escription specifies it.
For example, in a URI-path or URI-query, the Token size may vary from 0 to 8 byt For example, in a Uri-Path or Uri-Query, the Token size may vary from 0 to 8 byt
es, es,
and the CoAP options use the Type-Length-Value encoding format. <vspace blankLi and the CoAP options use the Type-Length-Value encoding format. </t>
nes='1'/> <t>
When doing SCHC compression of a variable-length field, When doing SCHC compression of a variable-length field,
Section 7.5.2 from <xref target="RFC8724"/> offers the possibility to define a f <xref target="RFC8724" sectionFormat="of" section="7.4.2"/> offers the option of
unction for the Field length in the Field Description defining a function for the Field Length in the Field Descriptor to know the le
to know the length before compression. If the field length is unknown, the Rule ngth before compression. If the Field Length is unknown, the Rule will set it as
will set it as a variable, a variable, and SCHC will send the compressed field's length in the Compression
and SCHC will send the compressed field’s length in the Compression Residue.</t> Residue.</t>
<t>A field can appear several times in the CoAP headers. </li>
<li>A field can appear several times in the CoAP headers.
It is found typically for elements of a URI (path or queries). It is found typically for elements of a URI (path or queries).
The SCHC specification <xref target="RFC8724"/> allows a Field ID to appear seve The SCHC specification <xref target="RFC8724" format="default"/> allows a FID to
ral times in the Rule appear several times in the Rule
and uses the Field Position (FP) to identify the correct instance, thereby remov and uses the Field Position (FP) to identify the correct instance, thereby remov
ing the matching operation’s ambiguity.</t> ing the MO's ambiguity.</li>
<t>Field lengths defined in the CoAP protocol can be too large regarding LPWAN <li>Field Lengths defined in CoAP can be too large when it comes to LP
traffic constraints. WAN traffic constraints.
For instance, this is particularly true for the Message-ID field and the Token f For instance, this is particularly true for the Message ID field and the Token f
ield. ield.
SCHC uses different Matching operators (MO) to perform the compression. See sect SCHC uses different MOs to perform the compression. See
ion 7.4 of <xref target="RFC8724"/>. <xref target="RFC8724" sectionFormat="of" section="7.4"/>.
In this case, SCHC can apply the Most Significant Bits (MSB) MO to reduce the in In this case, SCHC can apply the Most Significant Bits (MSBs) MO to reduce the i
formation carried on LPWANs.</t> nformation carried on LPWANs.</li>
</list></t> </ul>
</section>
</section> </section>
</section> <section anchor="CoAPcomp" numbered="true" toc="default">
<section anchor="CoAPcomp" title="Compression of CoAP header fields"> <name>Compression of CoAP Header Fields</name>
<t>This section discusses the compression of the different CoAP header fie
<t>This section discusses the compression of the different CoAP header fields. T lds. CoAP compression with SCHC follows the information provided in <xref targe
he CoAP compression with SCHC follows Section 7.1 of <xref target="RFC8724"/>.</ t="RFC8724" sectionFormat="of" section="7.1"/>.</t>
t> <section anchor="coap-version-field" numbered="true" toc="default">
<name>CoAP Version Field</name>
<section anchor="coap-version-field" title="CoAP version field"> <t>The CoAP version is bidirectional and <bcp14>MUST</bcp14> be elided d
uring SCHC compression, since it always contains the same value.
<t>CoAP version is bidirectional and MUST be elided during the SCHC 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> 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" numbered="true" toc="default">
<name>CoAP Type Field</name>
<t>CoAP <xref target="RFC7252" format="default"/> has four types of mess
ages: two requests (CON, NON), one response (ACK), and one empty message (RST).<
/t>
<t>The SCHC compression scheme <bcp14>SHOULD</bcp14> elide this field if
, for instance, a client is sending only Non-confirmable (NON) messages or only
CON messages.
For the RST message, SCHC may use a dedicated Rule. For other usages, SCHC can u
se a "match-mapping" MO.</t>
</section>
<section anchor="coap-code-field" numbered="true" toc="default">
<name>CoAP Code Field</name>
<t>The Code field, defined in an IANA registry <xref target="RFC7252" fo
rmat="default"/>, indicates the Request Method used in CoAP.
The compression of the CoAP Code field follows the same principle as that of th
e CoAP Type field. If the Device plays a specific role, SCHC may split the code
values into two Field Descriptors: (1) the request codes with the 0 class and (2
) the response values. SCHC will use the DI to identify the correct value in the
packet.</t>
<t>If the Device only implements a CoAP client, SCHC compression may red
uce the request code to the set of requests the client can process.</t>
<t>For known values, SCHC can use a "match-mapping" MO. If SCHC cannot c
ompress the Code field, it will send the values in the Compression Residue.</t>
</section>
<section anchor="coap-message-id-field" numbered="true" toc="default">
<name>CoAP Message ID Field</name>
<t>SCHC can compress the Message ID field with the "MSB" MO and the "LSB
" CDA.
See <xref target="RFC8724" sectionFormat="of" section="7.4"/>.</t>
</section>
<section anchor="coap-token-fields" numbered="true" toc="default">
<name>CoAP Token Fields</name>
<t>CoAP defines the Token using two CoAP fields: Token Length in the
mandatory header and Token Value directly following the mandatory
CoAP header.
</t>
<t>SCHC processes the Token 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 tr
ansmission. Otherwise, SCHC will send the Token Length in the Compression Residu
e.</t>
<t>For the Token Value, SCHC <bcp14>MUST NOT</bcp14> send it as
variable-length data in the Compression Residue, to avoid ambiguity with the Tok
en Length. Therefore, SCHC <bcp14>MUST</bcp14> use the Token Length value to def
ine the size of the Compression Residue. SCHC designates a specific function, "t
kl", that the Rule <bcp14>MUST</bcp14> use to complete the Field Descriptor. Dur
ing the decompression, this function returns the value contained in the Token Le
ngth field.</t>
</section>
</section>
<section anchor="coap-options" numbered="true" toc="default">
<name>CoAP Options</name>
<t>CoAP defines options placed after the basic header, ordered by option n
umber; see <xref 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 des
cription of the option by using the following:</t>
</section> <ul spacing="normal">
<section anchor="coap-type-field" title="CoAP type field"> <li>in the FID: the option number built from the D-T;</li>
<li>in the TV: the option value; and</li>
<t>The CoAP protocol <xref target="RFC7252"/> has four types of messages: two re <li>for the Option Length: the information provided in Sections&nbsp;<xref targe
quests (CON, NON), one response (ACK), and one empty message (RST).</t> t="RFC8724" section="7.4.1" sectionFormat="bare"/> and <xref target="RFC8724" se
ction="7.4.2" sectionFormat="bare"/> of <xref target="RFC8724"/>.</li>
<t>The SCHC compression SHOULD elide this field if, for instance, a client is se </ul>
nding only NON or only CON messages.
For the RST message, SCHC may use a dedicated Rule. For other usages, SCHC can u
se a “match-mapping” MO.</t>
</section>
<section anchor="coap-code-field" title="CoAP code field">
<t>The code field is an IANA registry <xref target="RFC7252"/>, and it indicates
the Request Method used in CoAP. The compression of the CoAP code field follows
the same principle as that of the CoAP type field. If the Device plays a specif
ic role, SCHC may split the code values into two fields description, the request
codes with the 0 class and the response values. SCHC will use the direction ind
icator 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” MO. If SCHC cannot compress
the code field, it will send the values in the Compression Residue.</t>
</section>
<section anchor="coap-message-id-field" title="CoAP Message ID field">
<t>SCHC can compress the Message ID field with the “MSB” MO and the “LSB” CDA. S
ee section 7.4 of <xref target="RFC8724"/>.</t>
</section>
<section anchor="coap-token-fields" title="CoAP Token fields">
<t>CoAP defines the Token using two CoAP fields, Token Length in the mandatory h
eader and Token Value directly following the mandatory CoAP header.</t>
<t>SCHC processes the Token length as any header field. If the value does not ch
ange, the size can be stored in the TV and elided during the transmission. Other
wise, SCHC will send the token length in the Compression Residue.</t>
<t>For the Token Value, SCHC MUST NOT send it as a variable-length in the Compre
ssion Residue to avoid ambiguity with Token Length. Therefore, SCHC MUST use the
Token length value to define the size of the Compression Residue. SCHC designat
es a specific function “tkl” that the Rule MUST use to complete the field descri
ption. During the decompression, this function returns the value contained in th
e Token Length field.</t>
</section>
</section>
<section anchor="coap-options" title="CoAP options">
<t>CoAP defines options placed after the basic header in Option Numbers order; s
ee <xref target="RFC7252"/>. Each Option instance in a message uses
the format Delta-Type (D-T), Length (L), Value (V). The SCHC Rule builds the des
cription of the option by using in the Field ID the Option Number built from D-T
; in TV, the Option Value; and the Option Length uses section 7.4 of <xref targe
t="RFC8724"/>. When the Option Length has a well-known size, the Rule may keep t
he length value. Therefore, SCHC compression does not send it. Otherwise, SCHC C
ompression carries the length of the Compression Residue, in addition to the Com
pression Residue value.</t>
<t>CoAP requests and responses do not include the same options. So Compression R
ules may reflect this asymmetry by tagging the direction indicator.</t>
<t>Note that length coding differs between CoAP options and SCHC variable size C
ompression 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 be updated, and the new F
ield ID description MUST be assigned to allow its compression.
Otherwise, if no Rule describes this new option, the SCHC compression is not ach
ieved, and SCHC sends the CoAP header without compression.</t>
<section anchor="coap-content-and-accept-options" title="CoAP Content and Accept
options.">
<t>If the client expects a single value, it can be stored in the TV and elided d
uring the transmission.
Otherwise, if the client expects several possible values, a “match-mapping” SHOU
LD be used to limit the Compression Residue’s size.
If not, SCHC has to send the option value in the Compression Residue (fixed or v
ariable length).</t>
</section>
<section anchor="coap-option-max-age-uri-host-and-uri-port-fields" title="CoAP o
ption Max-Age, Uri-Host, and Uri-Port fields">
<t>SCHC compresses these three fields in the same way. When the value of these o
ptions is known, SCHC can elide these fields.
If the option uses well-known values, SCHC can use a “match-mapping” MO. Otherwi
se, SCHC will use “value-sent” MO, and the Compression Residue will send these o
ptions’ values.</t>
</section>
<section anchor="coap-option-uri-path-and-uri-query-fields" title="CoAP option U
ri-Path and Uri-Query fields">
<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. SCHC Rule
description uses the Field Position (FP) to distinguish the different instances
in the path.</t>
<t>To compress repeatable field values, SCHC may use a “match-mapping” MO to red
uce the size of variable Paths or Queries. In these cases, to optimize the compr
ession, several elements can be regrouped into a single entry. The 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><![CDAT
A[
+--------+---+--+--+--------+-------------+------------+
| 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>When the Option Length has a well-known size, the Rule may keep the length va
lue. Therefore, SCHC compression does not send it. Otherwise, SCHC compression c
arries the length of the Compression Residue, in addition to the Compression Res
idue value.</t>
<t>CoAP requests and responses do not include the same options. So, compre
ssion Rules may reflect this asymmetry by tagging the 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 o
ptions.</t>
<t>If CoAP introduces a new option, the SCHC Rules <bcp14>MAY</bcp14> be u
pdated, and the new FID description <bcp14>MUST</bcp14> be assigned to allow its
compression.
Otherwise, if no Rule describes this new option, SCHC compression is not achieve
d, and SCHC sends the CoAP header without compression.</t>
<section anchor="coap-content-and-accept-options" numbered="true" toc="def
ault">
<name>CoAP Content and Accept 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" MO
<bcp14>SHOULD</bcp14> be used to limit the Compression Residue's size. If not, S
CHC has to send the option value in the Compression Residue (fixed or variable l
ength).</t>
</section>
<section anchor="coap-option-max-age-uri-host-and-uri-port-fields" numbere
d="true" toc="default">
<name>CoAP Option Max-Age, Uri-Host, and Uri-Port Fields</name>
<t>SCHC compresses these three fields in the same way. When the values o
f these options are known, SCHC can elide these fields.
If the option uses well-known values, SCHC can use a "match-mapping" MO. Otherwi
se, SCHC will use the "value-sent" MO, and the Compression Residue will send the
se options' values.</t>
</section>
<section anchor="coap-option-uri-path-and-uri-query-fields" numbered="true
" toc="default">
<name>CoAP Option Uri-Path and Uri-Query 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. Th
e SCHC Rule description uses the FP to distinguish the different instances in th
e path.</t>
<t>To compress repeatable field values, SCHC may use a "match-mapping" M
O to reduce the size of variable paths or queries. In these cases, to optimize t
he compression, several elements can be regrouped into a single entry. The numbe
ring of elements does not change, and the first matching element sets the MO com
parison.</t>
<t>In <xref target="Fig--complex-path"/>, SCHC can use a single bit in the Compr ession Residue to code one of the two paths. <t>In <xref 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 neede d. SCHC sends the third path element as a variable size in the Compression Resid ue.</t> If regrouping were not allowed, 2 bits in the Compression Residue would be neede d. SCHC sends the third path element as a variable size in the Compression Resid ue.</t>
<t>The length of URI-Path and URI-Query may be known when the rule is defined. I <table anchor="Table-complex-path">
n any case, SCHC MUST set the field length to variable. The unit to indicate the <name>Complex Path Example</name>
Compression Residue size is in Byte.</t> <thead>
<tr>
<t>SCHC compression can use the MSB MO to a Uri-Path or Uri-Query element. Howev <th align="center">Field</th>
er, attention to the length is important because the MSB value is in bits, and t <th align="center">FL</th>
he size MUST always be a multiple of 8 bits.</t> <th align="center">FP</th>
<th align="center">DI</th>
<t>The length sent at the beginning of a variable-length Compression Residue ind <th align="center">TV</th>
icates the LSB’s size in bytes.</t> <th align="center">MO</th>
<th align="center">CDA</th>
<t>For instance, for a CORECONF path /c/X6?k=”eth0” the Rule description can be: </tr>
</t> </thead>
<tbody>
<figure title="CORECONF URI compression" anchor="Fig-CoMicompress"><artwork><![C <tr>
DATA[ <td>Uri-Path</td>
+-------------+---+--+--+--------+---------+-------------+ <td></td>
| Field |FL |FP|DI| Target | Match | CDA | <td>1</td>
| | | | | Value | Opera. | | <td>Up</td>
+-------------+---+--+--+--------+---------+-------------+ <td>["/a/b",&br;"/c/d"]</td>
|Uri-Path | | 1|up|"c" |equal |not-sent | <td>match-&br;mapping</td>
|Uri-Path |var| 2|up| |ignore |value-sent | <td>mapping-sent</td>
|Uri-Query |var| 1|up|"k=\"" |MSB(24) |LSB | </tr>
+-------------+---+--+--+--------+---------+-------------+ <tr>
]]></artwork></figure> <td>Uri-Path</td>
<td>var</td>
<t><xref target="Fig-CoMicompress"/> shows the Rule description for a URI-Path a <td>3</td>
nd a URI-Query. SCHC compresses the first part of the URI-Path with a “not-sent” <td>Up</td>
CDA. <td></td>
SCHC will send the second element of the URI-Path with the length (i.e., 0x2 X 6 <td>ignore</td>
) followed by the query option (i.e., 0x05 eth0”).</t> <td>value-sent</td>
</tr>
<section anchor="variable-number-of-path-or-query-elements" title="Variable numb </tbody>
er of Path or Query elements"> </table>
<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 several Rules to cover all the possibil
ities.
Another one is to define the length of Uri-Path to variable and sends a Compress
ion Residue with a length of 0 to indicate that this Uri-Path is empty. However,
this adds 4 bits to the variable Compression Residue size. See section 7.5.2 <x
ref target="RFC8724"/>.</t>
</section>
</section>
<section anchor="coap-option-size1-size2-proxy-uri-and-proxy-scheme-fields" titl
e="CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme fields">
<t>The SCHC Rule description MAY define sending some field values by setting the
TV to “not-sent,” MO to “ignore,” and CDA to “value-sent.” A Rule MAY also use
a “match-mapping” when there are different options for the same FID. Otherwise,
the Rule sets the TV to the value, MO to “equal,” and CDA to “not-sent.”</t>
</section> <t>The length of Uri-Path and Uri-Query may be known when the Rule is de
<section anchor="coap-option-etag-if-match-if-none-match-location-path-and-locat fined. In any case, SCHC <bcp14>MUST</bcp14> set the Field Length to a variable
ion-query-fields" title="CoAP option ETag, If-Match, If-None-Match, Location-Pat value. The Compression Residue size is expressed in bytes.</t>
h, and Location-Query fields"> <t>SCHC compression can use the MSB MO to a Uri-Path or Uri-Query elemen
t. However, attention to the length is important because the MSB value is in bit
s, and the size <bcp14>MUST</bcp14> always be a multiple of 8 bits.</t>
<t>The length sent at the beginning of a variable-length Compression Res
idue indicates the LSB's size in bytes.</t>
<t>For instance, for a CORECONF path /c/X6?k=eth0, the Rule description
can be as follows (<xref target="Table-CoMicompress"/>):</t>
<t>A Rule entry cannot store these fields’ values. The Rule description MUST alw <table anchor="Table-CoMicompress">
ays send these values in the Compression Residue.</t> <name>CORECONF URI 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>
</section> <t><xref target="Table-CoMicompress" format="default"/> shows the Rule d
</section> escription for a Uri-Path and a Uri-Query. SCHC compresses the first part of the
<section anchor="schc-compression-of-coap-extension-rfcs" title="SCHC compressio Uri-Path with a "not-sent" CDA.
n of CoAP extension RFCs"> SCHC will send the second element of the Uri-Path with the length (i.e., 0x2 "X6
") followed by the query option (i.e., 0x4 "eth0").
</t>
<section anchor="variable-number-of-path-or-query-elements" numbered="tr
ue" toc="default">
<name>Variable Number of Path or Query Elements</name>
<t>SCHC fixed the number of Uri-Path or Uri-Query elements in a Rule a
t
the Rule creation time. If the number varies, SCHC <bcp14>SHOULD</bcp14> either<
/t>
<ul spacing="normal">
<li>create several Rules to cover all possibilities or</li>
<li>create a Rule that defines several entries for Uri-Path to cover the longest
path and send a Compression Residue with a length of 0 to indicate that a Uri-P
ath entry is empty.</li>
</ul>
<t>However, this adds 4 bits to the variable Compression Residue size. See
<xref target="RFC8724" sectionFormat="of" section="7.4.2"/>.</t>
</section>
</section>
<section anchor="coap-option-size1-size2-proxy-uri-and-proxy-scheme-fields
" numbered="true" toc="default">
<name>CoAP Option Size1, Size2, Proxy-URI, and Proxy-Scheme Fields</name
>
<section anchor="block" title="Block"> <t>The SCHC Rule description <bcp14>MAY</bcp14> define sending some fiel
d values by setting the TV to "not-sent", the MO to "ignore", and the CDA to "va
lue-sent". A Rule <bcp14>MAY</bcp14> also use a "match-mapping" MO when there ar
e different options for the same FID. Otherwise, the Rule sets the TV to the val
ue, the MO to "equal", and the CDA to "not-sent".</t>
</section>
<section anchor="coap-option-etag-if-match-if-none-match-location-path-and
-location-query-fields" numbered="true" toc="default">
<name>CoAP Option ETag, If-Match, If-None-Match, Location-Path, and Loca
tion-Query Fields</name>
<t>A Rule entry cannot store these fields' values. The Rule description
<bcp14>MUST</bcp14> always send these values in the Compression Residue.</t>
</section>
</section>
<section anchor="schc-compression-of-coap-extension-rfcs" numbered="true" to
c="default">
<name>SCHC Compression of CoAP Extensions</name>
<t>When a packet uses a Block <xref target="RFC7959"/> option, SCHC compression <section anchor="block" numbered="true" toc="default">
MUST send its content in the Compression Residue. <name>Block</name>
The SCHC Rule describes an empty TV with a MO set to “ignore” and a CDA to “valu <t>When a packet uses a Block option <xref target="RFC7959" format="defa
e-sent.” ult"/>, SCHC compression <bcp14>MUST</bcp14> send its content in the Compression
Block option allows fragmentation at the CoAP level that is compatible with SCHC Residue.
fragmentation. The SCHC Rule describes an empty TV with the MO set to "ignore" and the CDA set
to "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 t he same packet as needed.</t> Both fragmentation mechanisms are complementary, and the node may use them for t he same packet as needed.</t>
</section>
</section> <section anchor="observe" numbered="true" toc="default">
<section anchor="observe" title="Observe"> <name>Observe</name>
<t><xref target="RFC7641" format="default"/> defines the Observe Option.
<t>The <xref target="RFC7641"/> defines the Observe option. The SCHC Rule descri The SCHC Rule description will not define the TV but will set the MO to "ignore
ption will not define the TV, but MO to “ignore,” and the CDA to “value-sent.” S " and the CDA to "value-sent". SCHC does not limit the maximum size for this opt
CHC does not limit the maximum size for this option (3 bytes). To reduce the tra ion (3 bytes). To reduce the transmission size, either the Device implementation
nsmission size, either the Device implementation MAY limit the delta between two <bcp14>MAY</bcp14> limit the delta between two consecutive values or a proxy ca
consecutive values, or a proxy can modify the increment.</t> n modify the increment.</t>
<t>Since the Observe Option <bcp14>MAY</bcp14> use a RST message to info
<t>Since the Observe option MAY use an RST message to inform a server that the c rm a server that the client does not require the Observe response, a specific SC
lient does not require the Observe response, a specific SCHC Rule SHOULD exist t HC Rule <bcp14>SHOULD</bcp14> exist to allow the message's compression with the
o allow the message’s compression with the RST type.</t> RST type.</t>
</section>
</section> <section anchor="no-response" numbered="true" toc="default">
<section anchor="no-response" title="No-Response"> <name>No-Response</name>
<t><xref target="RFC7967" format="default"/> defines a No-Response optio
<t>The <xref target="RFC7967"/> defines a No-Response option limiting the respon n limiting the responses made by a server to a request. Different behaviors exis
ses made by a server to a request. Different behaviors exist while using this op t while using this option to limit the responses made by a server to a request.
tion to limit the responses made by a server to a request. If both ends know the If both ends know the value, then the SCHC Rule will describe a TV to this value
value, then the SCHC Rule will describe a TV to this value, with a MO set to “e , with the MO set to "equal" and the CDA set to "not-sent".</t>
qual” and CDA set to “not-sent.”</t> <t>Otherwise, if the value is changing over time, the SCHC Rule will set
the MO to "ignore" and the CDA to "value-sent". The Rule may also use a "match-
<t>Otherwise, if the value is changing over time, the SCHC Rule will set the MO mapping" MO to compress this option.</t>
to “ignore” and CDA to “value-sent.” The Rule may also use a “match-mapping” to </section>
compress this option.</t> <section anchor="Sec-OSCORE" numbered="true" toc="default">
<name>OSCORE</name>
</section> <t>OSCORE <xref target="RFC8613" format="default"/> defines end-to-end p
<section anchor="Sec-OSCORE" title="OSCORE"> rotection for CoAP messages.
<t>OSCORE <xref target="RFC8613"/> defines end-to-end protection for CoAP messag
es.
This section describes how SCHC Rules can be applied to compress OSCORE-protecte d messages.</t> This section describes how SCHC Rules can be applied to compress OSCORE-protecte d messages.</t>
<figure title="OSCORE Option" anchor="Fig-OSCORE-Option"><artwork><![CDATA[ <t><xref target="Fig-OSCORE-Option" format="default"/> shows the OSCORE
option value encoding defined in
<xref target="RFC8613" sectionFormat="of" section="6.1"/>, where the first byte
specifies the content of the OSCORE options using flags. The three most signific
ant bits of this byte are reserved and always set to 0. Bit h, when set, indicat
es the presence of the kid context field in the option. Bit k, when set, indicat
es the presence of a kid field. The three least significant bits, n, indicate th
e 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 1 2 3 4 5 6 7 <--------- n bytes ------------->
+-+-+-+-+-+-+-+-+--------------------------------- +-+-+-+-+-+-+-+-+---------------------------------
|0 0 0|h|k| n | Partial IV (if any) ... |0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+--------------------------------- +-+-+-+-+-+-+-+-+---------------------------------
| | | | | |
|<-- CoAP -->|<------ CoAP OSCORE_piv ------> | |<-- CoAP -->|<------ CoAP OSCORE_piv ------> |
OSCORE_flags OSCORE_flags
<- 1 byte -> <------ s bytes -----> <- 1 byte -> <------ s bytes ----->
+------------+----------------------+-----------------------+ +------------+----------------------+-----------------------+
| s (if any) | kid context (if any) | kid (if any) ... | | s (if any) | kid context (if any) | kid (if any) ... |
+------------+----------------------+-----------------------+ +------------+----------------------+-----------------------+
| | | | | |
| <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->| | <------ CoAP OSCORE_kidctx ------>|<-- CoAP OSCORE_kid -->|
]]></artwork>
]]></artwork></figure> </figure>
<t>The flag byte is followed by the piv field, the kid context field, an
<t>The <xref target="Fig-OSCORE-Option"/> shows the OSCORE Option Value encoding d the kid field, in that order, and, if present,
defined in Section 6.1 of <xref target="RFC8613"/>, where the first byte specif the kid context field's length (in bytes) is encoded in the first byte, denoted
ies the Content of the OSCORE options using flags. The three most significant bi by "s".
ts of this byte are reserved and always set to 0. Bit h, when set, indicates the </t>
presence of the kid context field in the option. Bit k, when set, indicates the <t>To better perform OSCORE SCHC compression, the Rule description needs
presence of a kid field. The three least significant bits n indicate the length to identify the OSCORE option and the fields it contains. Conceptually, it disc
of the piv (Partial Initialization Vector) field in bytes. When n = 0, no piv i erns up to four distinct pieces of information within the OSCORE option: the fla
s present.</t> g bits, the piv, the kid context, and the kid. The SCHC Rule splits the OSCORE o
ption into four Field Descriptors in order to compress them:
<t>The flag byte is followed by the piv field, kid context field, and kid field </t>
in this order, and if present, <ul spacing="normal">
the kid context field’s length is encoded in the first byte denoting by ‘s’ the <li>CoAP OSCORE_flags</li>
length of the kid context in bytes.</t> <li>CoAP OSCORE_piv</li>
<li>CoAP OSCORE_kidctx</li>
<t>To better perform OSCORE SCHC compression, the Rule description needs to iden <li>CoAP OSCORE_kid</li>
tify the OSCORE Option and the fields it contains. Conceptually, it discerns up </ul>
to 4 distinct pieces of information within the OSCORE option: the flag bits, the <t><xref target="Fig-OSCORE-Option" format="default"/> shows the OSCORE
piv, the kid context, and the kid. The SCHC Rule splits into four field descri option format with those four fields superimposed on it.
ptions the OSCORE option to compress them:</t> Note that the CoAP OSCORE_kidctx field directly includes the size octet, s.
</t>
<t><list style="symbols"> </section>
<t>CoAP OSCORE_flags,</t> </section>
<t>CoAP OSCORE_piv,</t> <section anchor="examples-of-coap-header-compression" numbered="true" toc="d
<t>CoAP OSCORE_kidctx,</t> efault">
<t>CoAP OSCORE_kid.</t> <name>Examples of CoAP Header Compression</name>
</list></t> <section anchor="mandatory-header-with-con-message" numbered="true" toc="d
efault">
<t><xref target="Fig-OSCORE-Option"/> shows the OSCORE Option format with those <name>Mandatory Header with CON Message</name>
four fields superimposed on it. <t>In this first scenario, the SCHC compressor on the NGW side
Note that the CoAP OSCORE_kidctx field directly includes the size octet s.</t>
</section>
</section>
<section anchor="examples-of-coap-header-compression" title="Examples of CoAP he
ader compression">
<section anchor="mandatory-header-with-con-message" title="Mandatory header with
CON message">
<t>In this first scenario, the SCHC Compressor at the Network Gateway side
receives a POST message from an Internet client, which is immediately acknowledg ed by the Device. receives a POST message from an Internet client, which is immediately acknowledg ed by the Device.
<xref target="Fig-CoAP-header-1"/> describes the SCHC Rule descriptions for this <xref target="Table-CoAP-header-1" format="default"/> describes the SCHC Rule de
scenario.</t> scriptions for this scenario.</t>
<table anchor="Table-CoAP-header-1">
<figure title="CoAP Context to compress header without Token" anchor="Fig-CoAP-h <name>CoAP Context to Compress Header without Token</name>
eader-1"><artwork><![CDATA[ <thead>
RuleID 1 <tr>
+-------------+--+--+--+------+---------+-------------++------------+ <th align="left" colspan="8">RuleID 1</th>
| Field |FL|FP|DI|Target| Match | CDA || Sent | </tr>
| | | | |Value | Opera. | || [bits] | <tr>
+-------------+--+--+--+------+---------+-------------++------------+ <th align="center">Field</th>
|CoAP version | 2| 1|bi| 01 |equal |not-sent || | <th align="center">FL</th>
|CoAP Type | 2| 1|dw| CON |equal |not-sent || | <th align="center">FP</th>
|CoAP Type | 2| 1|up|[ACK, |match- |matching- || | <th align="center">DI</th>
| | | | | RST] |mapping |sent || T | <th align="center">TV</th>
|CoAP TKL | 4| 1|bi| 0 |equal |not-sent || | <th align="center">MO</th>
|CoAP Code | 8| 1|bi|[0.00,| | || | <th align="center">CDA</th>
| | | | | ... |match- |matching- || | <th align="center">Sent [bits]</th>
| | | | | 5.05]|mapping |sent || CC CCC | </tr>
|CoAP MID |16| 1|bi| 0000 |MSB(7 ) |LSB || M-ID| </thead>
|CoAP Uri-Path|var 1|dw| path |equal 1 |not-sent || | <tbody>
+-------------+--+--+--+------+---------+-------------++------------+ <tr>
<td>CoAP version</td>
]]></artwork></figure> <td>2</td>
<td>1</td>
<t>In this example, SCHC compression elides the version and the Token Length fie <td>Bi</td>
lds. The 26 method and response codes defined in <xref target="RFC7252"/> has be <td>01</td>
en shrunk to 5 bits using a “match-mapping” MO. The Uri-Path contains a single e <td>equal</td>
lement indicated in the TV and elided with the CDA “not-sent.”</t> <td>not-sent</td>
<th></th>
<t>SCHC Compression reduces the header sending only the Type, a mapped code, and </tr>
the least significant bits of Message ID (9 bits in the example above).</t> <tr>
<td>CoAP Type</td>
<t>Note that a client located in an Application Server sending a request to a se <td>2</td>
rver located in the Device may not be compressed through this Rule since the MID <td>1</td>
might not start with 7 bits equal to 0. A CoAP proxy placed before the SCHC C/D <td>Dw</td>
can rewrite the message ID to fit the value and match the Rule.</t> <td>CON</td>
<td>equal</td>
</section> <td>not-sent</td>
<section anchor="Sec-OSCORE-Examples" title="OSCORE Compression"> <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>OSCORE aims to solve the problem of end-to-end encryption for CoAP messages. <t>In this example, SCHC compression elides the version and Token Length
Therefore, the goal is to hide as much as possible the message fields. The 25 Method and Response Codes defined in <xref target="RFC7252" form
at="default"/> have been shrunk to 5 bits using a "match-mapping" MO. The Uri-Pa
th contains a single element indicated in the TV and elided with the CDA "not-se
nt".</t>
<t>SCHC compression reduces the header, sending only the Type, a mapped
code, and the least significant bits of the Message ID (9 bits in the example ab
ove).</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, sinc
e the MID might not start with 7 bits equal to 0. A CoAP proxy placed before SCH
C C/D can rewrite the Message ID to fit the value and match the Rule.</t>
</section>
<section anchor="Sec-OSCORE-Examples" numbered="true" toc="default">
<name>OSCORE Compression</name>
<t>OSCORE aims to solve the problem of end-to-end encryption for CoAP me
ssages. Therefore, the goal is to hide the message as much as possible
while still enabling proxy operation.</t> while still enabling proxy operation.</t>
<t>Conceptually, this is achieved by splitting the CoAP message into an
<t>Conceptually this is achieved by splitting the CoAP message into an Inner Pla Inner Plaintext and Outer OSCORE message. The Inner Plaintext contains sensitive
intext and Outer OSCORE Message. The Inner Plaintext contains sensitive informat information that is not necessary for proxy operation. However, it is part of t
ion that is not necessary for proxy operation. However, it is part of the messag he message that can be encrypted until it
e that can be encrypted until it reaches its end destination. The Outer Message acts as a shell matching the regu
reaches its end destination. The Outer Message acts as a shell matching the regu lar CoAP message format and includes all options and information
lar CoAP message format and includes all Options and information needed for proxy operation and caching. <xref target="Fig-inner-outer" format="d
needed for proxy operation and caching. <xref target="Fig-inner-outer"/> illustr efault"/> below illustrates this analysis.</t>
ates this analysis.</t> <t>CoAP arranges the options into one of three classes, each granted a s
pecific type of protection by the protocol:</t>
<t>The CoAP protocol arranges the options into one of 3 classes; each granted a <dl spacing="normal">
specific type of protection by the protocol:</t> <dt>Class E:</dt><dd>Encrypted options moved to the Inner Plaintext.</
dd>
<t><list style="symbols"> <dt>Class I:</dt><dd>Integrity-protected options included in the Addit
<t>Class E: Encrypted options moved to the Inner Plaintext,</t> ional Authenticated Data (AAD) for the encryption of the Plaintext but otherwise
<t>Class I: Integrity-protected options included in the AAD for the encryption left untouched in the Outer Message.
of the Plaintext but otherwise left untouched in the Outer Message,</t> </dd>
<t>Class U: Unprotected options left untouched in the Outer Message.</t> <dt>Class U:</dt><dd>Unprotected options left untouched in the Outer M
</list></t> essage.</dd>
</dl>
<t>These classes point out that the Outer option contains the OSCORE Option and <t>These classes point out that the Outer option contains the OSCORE opt
that the message is OSCORE protected; this option carries the information necess ion and that the message is OSCORE protected; this option carries the informatio
ary to retrieve the Security Context. The end-point will use this Security Conte n necessary to retrieve the Security Context. The endpoint will use this Securit
xt to decrypt the message correctly.</t> y Context to decrypt the message correctly.</t>
<figure anchor="Fig-inner-outer">
<figure title="A CoAP packet is split into an OSCORE outer and plaintext" anchor <name>CoAP Packet Split into OSCORE Outer Header and Plaintext</name>
="Fig-inner-outer"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Original CoAP Packet Original CoAP Packet
+-+-+---+-------+---------------+ +-+-+---+-------+---------------+
|v|t|TKL| code | Msg Id. | |v|t|TKL| code | Message ID |
+-+-+---+-------+---------------+....+ +-+-+---+-------+---------------+....+
| Token | | Token |
+-------------------------------.....+ +-------------------------------.....+
| Options (IEU) | | Options (IEU) |
. . . .
. . . .
+------+-------------------+ +------+-------------------+
| 0xFF | | 0xFF |
+------+------------------------+ +------+------------------------+
| | | |
| Payload | | Payload |
| | | |
+-------------------------------+ +-------------------------------+
/ \ / \
/ \ / \
/ \ / \
/ \ / \
Outer Header v v Plaintext Outer Header v v Plaintext
+-+-+---+--------+---------------+ +-------+ +-+-+---+--------+---------------+ +-------+
|v|t|TKL|new code| Msg Id. | | code | |v|t|TKL|new code| Message ID | | code |
+-+-+---+--------+---------------+....+ +-------+-----......+ +-+-+---+--------+---------------+....+ +-------+-----......+
| Token | | Options (E) | | Token | | Options (E) |
+--------------------------------.....+ +-------+------.....+ +--------------------------------.....+ +-------+------.....+
| Options (IU) | | OxFF | | Options (IU) | | 0xFF |
. . +-------+-----------+ . . +-------+-----------+
. OSCORE Option . | | . OSCORE Option . | |
+------+-------------------+ | Payload | +------+-------------------+ | Payload |
| 0xFF | | | | 0xFF | | |
+------+ +-------------------+ +------+ +-------------------+
]]></artwork>
</figure>
]]></artwork></figure> <t><xref target="Fig-inner-outer" format="default"/> shows the packet fo
rmat for the OSCORE Outer header and Plaintext.</t>
<t><xref target="Fig-inner-outer"/> shows the packet format for the OSCORE Outer <t>In the Outer header, the original header code is hidden and replaced
header and Plaintext.</t> by a default dummy value. As seen in
Sections&nbsp;<xref target="RFC8613" section="4.1.3.5" sectionFormat="bare"/> an
<t>In the Outer Header, the original header code is hidden and replaced by a def d <xref target="RFC8613" section="4.2" sectionFormat="bare"/> of <xref target="R
ault dummy value. As seen in Sections 4.1.3.5 and 4.2 of <xref target="RFC8613"/ FC8613"/>, the message code is replaced by POST for requests and Changed for res
>, the message code is replaced by POST for requests and Changed for responses w ponses when CoAP is not using the Observe Option. If CoAP uses Observe, the OSCO
hen CoAP is not using the Observe option. If CoAP uses Observe, the OSCORE messa RE message code is replaced by FETCH for requests and Content for responses.</t>
ge code is replaced by FETCH for requests and Content for responses.</t> <t>The first byte of the Plaintext contains the original packet code, fo
llowed by the message code, the class E options, and, if present, the original m
<t>The first byte of the Plaintext contains the original packet code, followed b essage payload preceded by its payload marker.</t>
y the message code, the class E options, and, if present, the original message P <t>An Authenticated Encryption with Associated Data (AEAD) algorithm now
ayload preceded by its payload marker.</t> encrypts the Plaintext. This integrity-protects the Security Context parameters
and, eventually, any class I options from the Outer header. The resulting ciphe
<t>An AEAD algorithm now encrypts the Plaintext. This integrity protects the Sec rtext becomes the new payload of the OSCORE message, as illustrated in <xref tar
urity Context parameters and, eventually, any class I options from the Outer Hea get="Fig-full-oscore" format="default"/>.</t>
der. The resulting Ciphertext becomes the new payload of the OSCORE message, as <t>As defined in <xref target="RFC5116" format="default"/>, this ciphert
illustrated in <xref target="Fig-full-oscore"/>.</t> ext is the encrypted Plaintext's concatenation of the Authentication Tag. Note t
hat Inner Compression only affects the Plaintext before encryption.
<t>As defined in <xref target="RFC5116"/>, this Ciphertext is the encrypted Plai The Authentication Tag, fixed in length and uncompressed, is considered part of
ntext’s concatenation of the authentication tag. Note that Inner Compression onl the cost of protection.
y affects the Plaintext before encryption. Thus only the first variable-length o </t>
f the Ciphertext can be reduced. The authentication tag is fixed in length and i <figure anchor="Fig-full-oscore">
s considered part of the cost of protection.</t> <name>OSCORE Message</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="OSCORE message" anchor="Fig-full-oscore"><artwork><![CDATA[
Outer Header Outer Header
+-+-+---+--------+---------------+ +-+-+---+--------+---------------+
|v|t|TKL|new code| Msg Id. | |v|t|TKL|new code| Message ID |
+-+-+---+--------+---------------+....+ +-+-+---+--------+---------------+....+
| Token | | Token |
+--------------------------------.....+ +--------------------------------.....+
| Options (IU) | | Options (IU) |
. . . .
. OSCORE Option . . OSCORE Option .
+------+-------------------+ +------+-------------------+
| 0xFF | | 0xFF |
+------+---------------------------+ +------+---------------------------+
| | | |
| Ciphertext: Encrypted Inner | | Ciphertext: Encrypted Inner |
| Header and Payload | | Header and Payload |
| + Authentication Tag | | + Authentication Tag |
| | | |
+----------------------------------+ +----------------------------------+
]]></artwork>
]]></artwork></figure> </figure>
<t>The SCHC compression scheme consists of compressing both the Plaintex
<t>The SCHC Compression scheme consists of compressing both the Plaintext before t before encryption and the resulting OSCORE message after encryption; see <xref
encryption and the resulting OSCORE message after encryption, see <xref target= target="Fig-OSCORE-Compression" format="default"/>.</t>
"Fig-OSCORE-Compression"/>.</t> <t>The OSCORE message translates into a segmented process where SCHC com
pression is applied independently in two stages, each with its corresponding set
<t>The OSCORE message translates into a segmented process where SCHC compression of Rules, with the Inner SCHC Rules and the Outer SCHC Rules. This way, compres
is applied independently in 2 stages, each with its corresponding set of Rules, sion is applied to all fields of the original CoAP message.</t>
with the Inner SCHC Rules and the Outer SCHC Rules. This way, compression is ap <figure anchor="Fig-OSCORE-Compression">
plied to all fields of the original CoAP message.</t> <name>OSCORE Compression Diagram</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>Note that since the corresponding end-point can only decrypt the Inner part o
f the message, this end-point will also have to implement Inner SCHC Compression
/Decompression.</t>
<figure title="OSCORE Compression Diagram" anchor="Fig-OSCORE-Compression"><artw
ork><![CDATA[
Outer Message OSCORE Plaintext Outer Message OSCORE Plaintext
+-+-+---+--------+---------------+ +-------+ +-+-+---+--------+---------------+ +-------+
|v|t|TKL|new code| Msg Id. | | code | |v|t|TKL|new code| Message ID | | code |
+-+-+---+--------+---------------+....+ +-------+-----......+ +-+-+---+--------+---------------+....+ +-------+-----......+
| Token | | Options (E) | | Token | | Options (E) |
+--------------------------------.....+ +-------+------.....+ +--------------------------------.....+ +-------+------.....+
| Options (IU) | | OxFF | | Options (IU) | | 0xFF |
. . +-------+-----------+ . . +-------+-----------+
. OSCORE Option . | | . OSCORE Option . | |
+------+-------------------+ | Payload | +------+-------------------+ | Payload |
| 0xFF | | | | 0xFF | | |
+------+------------+ +-------------------+ +------+------------+ +-------------------+
| Ciphertext |<---------\ | | Ciphertext |<---------\ |
| | | v | | | v
+-------------------+ | +-----------------+ +-------------------+ | +-----------------+
| | | Inner SCHC | | | | Inner SCHC |
v | | Compression | v | | Compression |
skipping to change at line 606 skipping to change at line 712
| | |RuleID | | | |RuleID |
v | +-------+-----------+ v | +-------+-----------+
+--------+ +------------+ |Compression Residue| +--------+ +------------+ |Compression Residue|
|RuleID' | | Encryption | <-- +----------+--------+ |RuleID' | | Encryption | <-- +----------+--------+
+--------+-----------+ +------------+ | | +--------+-----------+ +------------+ | |
|Compression Residue'| | Payload | |Compression Residue'| | Payload |
+-----------+--------+ | | +-----------+--------+ | |
| Ciphertext | +-------------------+ | Ciphertext | +-------------------+
| | | |
+--------------------+ +--------------------+
]]></artwork>
]]></artwork></figure> </figure>
<t>Note that since the corresponding endpoint can only decrypt the Inner
</section> part of the message, this endpoint will also have to implement Inner SCHC Compr
<section anchor="example-oscore-compression" title="Example OSCORE Compression"> ession/Decompression.</t>
</section>
<t>This section gives an example with a GET Request and its consequent Content <section anchor="example-oscore-compression" numbered="true" toc="default"
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 and Outer SCHC <name>Example OSCORE Compression</name>
<t>This section gives an example with a GET request and its consequent C
ontent
response from a Device-based CoAP client to a cloud-based CoAP server.
The example also describes a possible set of Rules for Inner SCHC Compression an
d Outer SCHC
Compression. A dump of the results and a contrast between SCHC + OSCORE Compression. A dump of the results and a contrast between SCHC + OSCORE
performance with SCHC + COAP performance is also listed. This example gives an a pproximation of the performance with SCHC + CoAP performance are also listed. This example gives an approximation of the
cost of security with SCHC-OSCORE.</t> cost of security with SCHC-OSCORE.</t>
<t>Our first CoAP message is the GET request in <xref target="Fig-GET-te
<t>Our first CoAP message is the GET request in <xref target="Fig-GET-temp"/>.</ mp" format="default"/>.</t>
t> <figure anchor="Fig-GET-temp">
<name>CoAP GET Request</name>
<figure title="CoAP GET Request" anchor="Fig-GET-temp"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Original message: Original message:
================= =================
0x4101000182bb74656d7065726174757265 0x4101000182bb74656d7065726174757265
Header: Header:
0x4101 0x4101
01 Ver 01 Ver
00 CON 00 CON
0001 TKL 0001 TKL
00000001 Request Code 1 "GET" 00000001 Request Code 1 "GET"
0x0001 = mid 0x0001 = mid
0x82 = token 0x82 = token
Options: Options:
0xbb74656d7065726174757265 0xbb74656d7065726174757265
Option 11: URI_PATH Option 11: URI_PATH
Value = temperature Value = temperature
Original msg length: 17 bytes. Original message length: 17 bytes
]]></artwork></figure> ]]></artwork>
</figure>
<t>Its corresponding response is the CONTENT Response in <xref target="Fig-CONTE <t>Its corresponding response is the Content response in <xref target="F
NT-temp"/>.</t> ig-CONTENT-temp" format="default"/>.</t>
<figure anchor="Fig-CONTENT-temp">
<figure title="CoAP CONTENT Response" anchor="Fig-CONTENT-temp"><artwork><![CDAT <name>CoAP Content Response</name>
A[ <artwork name="" type="" align="left" alt=""><![CDATA[
Original message: Original message:
================= =================
0x6145000182ff32332043 0x6145000182ff32332043
Header: Header:
0x6145 0x6145
01 Ver 01 Ver
10 ACK 10 ACK
0001 TKL 0001 TKL
01000101 Successful Response Code 69 "2.05 Content" 01000101 Successful Response Code 69 "2.05 Content"
0x0001 = mid 0x0001 = mid
0x82 = token 0x82 = token
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0x32332043 0x32332043
Original msg length: 10 Original message length: 10 bytes
]]></artwork></figure> ]]></artwork>
</figure>
<t>The SCHC Rules for the Inner Compression include all fields already present i
n a regular CoAP message. The methods described in <xref target="CoAPcomp"/> app
ly 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>
<t><xref target="Fig-Inner-Compression-GET"/> shows the Plaintext obtained for t he example GET request. The packet follows the process of Inner Compression and Encryption until the payload. The outer OSCORE Message adds the result of the In ner process.</t> <t>The SCHC Rules for the Inner Compression include all fields already p resent in a regular CoAP message. The methods described in <xref target="CoAPcom p" format="default"/> apply to these fields. <xref target="Table-Inner-Rules" fo rmat="default"/> provides an example.</t>
<t>In this case, the original message has no payload, and its resulting Plaintex <table anchor="Table-Inner-Rules">
t compressed up to only 1 byte (size of the RuleID). The AEAD algorithm preserve <name>Inner SCHC Rule</name>
s this length in its first output and yields a fixed-size tag. SCHC cannot compr <thead>
ess the tag, and the OSCORE message must include it without compression. <tr>
The use of integrity protection translates into an overhead in total message len <th align="left" colspan="8">RuleID 0</th>
gth, limiting the amount of compression that can be achieved and plays into the </tr>
cost of adding security to the exchange.</t> <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>
<figure title="Plaintext compression and encryption for GET Request" anchor="Fig <t><xref target="Fig-Inner-Compression-GET" format="default"/> shows the
-Inner-Compression-GET"><artwork><![CDATA[ Plaintext obtained for the example GET request. The packet follows the process
of Inner Compression and encryption until the payload. The Outer OSCORE message
adds the result of the Inner process.</t>
<figure anchor="Fig-Inner-Compression-GET">
<name>Plaintext Compression and Encryption for GET Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
________________________________________________________ ________________________________________________________
| | | |
| OSCORE Plaintext | | OSCORE Plaintext |
| | | |
| 0x01bb74656d7065726174757265 (13 bytes) | | 0x01bb74656d7065726174757265 (13 bytes) |
| | | |
| 0x01 Request Code GET | | 0x01 Request Code GET |
| | | |
| bb74656d7065726174757265 Option 11: URI_PATH | | bb74656d7065726174757265 Option 11: URI_PATH |
| Value = temperature | | Value = temperature |
skipping to change at line 728 skipping to change at line 871
| AEAD Encryption | AEAD Encryption
| (piv = 0x04) | (piv = 0x04)
v v
_________________________________________________ _________________________________________________
| | | |
| encrypted_plaintext = 0xa2 (1 byte) | | encrypted_plaintext = 0xa2 (1 byte) |
| tag = 0xc54fe1b434297b62 (8 bytes) | | tag = 0xc54fe1b434297b62 (8 bytes) |
| | | |
| ciphertext = 0xa2c54fe1b434297b62 (9 bytes) | | ciphertext = 0xa2c54fe1b434297b62 (9 bytes) |
|_________________________________________________| |_________________________________________________|
]]></artwork>
]]></artwork></figure> </figure>
<t>In this case, the original message has no payload, and its resulting
<t><xref target="Fig-Inner-Compression-CONTENT"/> shows the process for the exam Plaintext is compressed up to only 1 byte (the size of the RuleID). The AEAD alg
ple CONTENT Response. The Compression Residue is 1 bit long. orithm preserves this length in its first output and yields a fixed-size tag. SC
Note that since SCHC adds padding after the payload, this misalignment causes th HC cannot compress the tag, and the OSCORE message must include it without compr
e hexadecimal code from the payload to differ from the original, even if SCHC ca ession.
nnot compress the tag. The overhead for the tag bytes limits the SCHC’s performa The use of integrity protection translates into an overhead in total message len
nce but brings security to the transmission.</t> gth, limiting the amount of compression that can be achieved and playing into th
e cost of adding security to the exchange.</t>
<figure title="Plaintext compression and encryption for CONTENT Response" anchor <t><xref target="Fig-Inner-Compression-CONTENT" format="default"/> shows
="Fig-Inner-Compression-CONTENT"><artwork><![CDATA[ the process for the example Content response. The Compression Residue is 1 bit
long.
Note that since SCHC adds padding after the payload, this misalignment causes th
e hexadecimal code from the payload to differ from the original, even if SCHC ca
nnot compress the tag. The overhead for the tag bytes limits SCHC's performance
but brings security to the transmission.</t>
<figure anchor="Fig-Inner-Compression-CONTENT">
<name>Plaintext Compression and Encryption for Content Response</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
________________________________________________________ ________________________________________________________
| | | |
| OSCORE Plaintext | | OSCORE Plaintext |
| | | |
| 0x45ff32332043 (6 bytes) | | 0x45ff32332043 (6 bytes) |
| | | |
| 0x45 Successful Response Code 69 "2.05 Content" | | 0x45 Successful Response Code 69 "2.05 Content" |
| | | |
| ff Payload marker | | ff Payload marker |
| | | |
| 32332043 Payload | | 32332043 Payload |
|________________________________________________________| |________________________________________________________|
| |
| |
| Inner SCHC Compression | Inner SCHC Compression
| |
v v
_____________________________________________ _________________________________________________
| | | |
| Compressed Plaintext | | Compressed Plaintext |
| | | |
| 0x001919902180 (6 bytes) | | 0x001919902180 (6 bytes) |
| | | |
| 00 RuleID | | 00 RuleID |
| | | |
| 0b0 (1 bit match-map Compression Residue) | | 0b0 (1 bit match-mapping Compression Residue) |
| 0x32332043 >> 1 (shifted payload) | | 0x32332043 >> 1 (shifted payload) |
| 0b0000000 Padding | | 0b0000000 Padding |
|_____________________________________________| |_________________________________________________|
| |
| AEAD Encryption | AEAD Encryption
| (piv = 0x04) | (piv = 0x04)
v v
_________________________________________________________ _________________________________________________________
| | | |
| encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) |
| tag = 0xe9aef3f2461e0c29 (8 bytes) | | tag = 0xe9aef3f2461e0c29 (8 bytes) |
| | | |
| ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |
|_________________________________________________________| |_________________________________________________________|
]]></artwork>
</figure>
<t>The Outer SCHC Rule (<xref target="Table-Outer-Rule" format="default"
/>) must process the OSCORE options fields. Figures&nbsp;<xref target="Fig-Prote
cted-Compressed-GET" format="counter"/> and <xref target="Fig-Protected-Compress
ed-CONTENT" format="counter"/> show a dump of the OSCORE messages generated from
the example messages. They include the Inner Compressed ciphertext in the paylo
ad. These are the messages that have to be compressed via the Outer SCHC Compres
sion scheme.</t>
]]></artwork></figure> <t><xref target="Table-Outer-Rule" format="default"/> shows a possible s et of Outer Rule items to compress the Outer header.</t>
<t>The Outer SCHC Rules (<xref target="Fig-Outer-Rules"/>) must process the OSCO <table anchor="Table-Outer-Rule">
RE Options fields. <xref target="Fig-Protected-Compressed-GET"/> and <xref targe <name>Outer SCHC Rule</name>
t="Fig-Protected-Compressed-CONTENT"/> shows a dump of the OSCORE Messages gener <thead>
ated from the example messages. They include the Inner Compressed Ciphertext in <tr>
the payload. These are the messages that have to be compressed by the Outer SCHC <th align="left" colspan="8">RuleID 0</th>
Compression.</t> </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 and Inner SCHC Compressed GET Request" anchor="Fig-Prot <figure anchor="Fig-Protected-Compressed-GET">
ected-Compressed-GET"><artwork><![CDATA[ <name>Protected and Inner SCHC Compressed GET Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Protected message: Protected message:
================== ==================
0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62 0x4102000182d8080904636c69656e74ffa2c54fe1b434297b62
(25 bytes) (25 bytes)
Header: Header:
0x4102 0x4102
01 Ver 01 Ver
00 CON 00 CON
0001 TKL 0001 TKL
00000010 Request Code 2 "POST" 00000010 Request Code 2 "POST"
0x0001 = mid 0x0001 = mid
0x82 = token 0x82 = token
Options: Options:
0xd8080904636c69656e74 (10 bytes) 0xd8080904636c69656e74 (10 bytes)
Option 21: OBJECT_SECURITY Option 21: OBJECT_SECURITY
Value = 0x0904636c69656e74 Value = 0x0904636c69656e74
09 = 000 0 1 001 Flag byte 09 = 000 0 1 001 flag byte
h k n h k n
04 piv 04 piv
636c69656e74 kid 636c69656e74 kid
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0xa2c54fe1b434297b62 (9 bytes) 0xa2c54fe1b434297b62 (9 bytes)
]]></artwork></figure> ]]></artwork>
</figure>
<figure title="Protected and Inner SCHC Compressed CONTENT Response" anchor="Fig <figure anchor="Fig-Protected-Compressed-CONTENT">
-Protected-Compressed-CONTENT"><artwork><![CDATA[ <name>Protected and Inner SCHC Compressed Content Response</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Protected message: Protected message:
================== ==================
0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29 0x6144000182d008ff10c6d7c26cc1e9aef3f2461e0c29
(22 bytes) (22 bytes)
Header: Header:
0x6144 0x6144
01 Ver 01 Ver
10 ACK 10 ACK
0001 TKL 0001 TKL
skipping to change at line 836 skipping to change at line 1157
0x82 = token 0x82 = token
Options: Options:
0xd008 (2 bytes) 0xd008 (2 bytes)
Option 21: OBJECT_SECURITY Option 21: OBJECT_SECURITY
Value = b'' Value = b''
0xFF Payload marker 0xFF Payload marker
Payload: Payload:
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
]]></artwork></figure> ]]></artwork>
</figure>
<t>For the flag bits, some SCHC compression methods are useful, depending on the <t>For the flag bits, some SCHC compression methods are useful, dependin
Application. The most straightforward alternative is to g on the application. The most straightforward alternative is to
provide a fixed value for the flags, combining MO “equal” and CDA “not-sent.” provide a fixed value for the flags, combining a MO of "equal" and a CDA of "not
This SCHC definition saves most bits but could prevent flexibility. Otherwise, S -sent".
CHC could use a “match-mapping” MO to choose from several configurations for the This SCHC definition saves most bits but could prevent flexibility. Otherwise, S
exchange. If not, the SCHC description may use an “MSB” MO to mask off the thre CHC could use a "match-mapping" MO to choose from several configurations for the
e hard-coded most significant bits.</t> exchange. If not, the SCHC description may use an "MSB" MO to mask off the thre
e hard-coded most significant bits.</t>
<t>Note that fixing a flag bit will limit CoAP Options choice that can be used i <t>Note that fixing a flag bit will limit the choices of CoAP options th
n the exchange since their values are dependent on specific options.</t> at can be used in the exchange, since the values of these choices are dependent
on specific options.
<t>The piv field lends itself to having some bits masked off with “MSB” MO and “ </t>
LSB” CDA. This SCHC description could be useful in applications where the messag <t>The piv field lends itself to having some bits masked off with an "MS
e frequency is low such as LPWAN technologies. B" MO and an "LSB" CDA. This SCHC description could be useful in applications wh
ere the message frequency is low, such as LPWAN technologies.
Note that compressing the sequence numbers may reduce the maximum number of sequ ence numbers that can be used in an exchange. Note that compressing the sequence numbers may reduce the maximum number of sequ ence numbers that can be used in an exchange.
Once the sequence number exceeds the maximum value, the OSCORE keys need to be r e-established.</t> Once the sequence number exceeds the maximum value, the OSCORE keys need to be r e-established.</t>
<t>The size, s, that is included in the kid context field <bcp14>MAY</bc
<t>The size s included in the kid context field MAY be masked off with “LSB” CDA p14> be masked off with an "LSB" CDA. The rest of the field could have additiona
. The rest of the field could have additional bits masked off or have the whole l bits masked off or have the whole field fixed with a MO of "equal" and a CDA o
field fixed with MO “equal” and CDA “not-sent.” The same holds for the kid field f "not-sent". The same holds for the kid field.</t>
.</t> <t>The Outer Rule of <xref target="Table-Outer-Rule" format="default"/>
is applied to the example GET request and Content response.
<t><xref target="Fig-Outer-Rules"/> shows a possible set of Outer Rules to compr Figures&nbsp;<xref target="Fig-Compressed-GET" format="counter"/> and <xref targ
ess the Outer Header.</t> et="Fig-Compressed-CONTENT" format="counter"/> show the resulting messages.</t>
<figure anchor="Fig-Compressed-GET">
<figure title="Outer SCHC Rules" anchor="Fig-Outer-Rules"><artwork><![CDATA[ <name>SCHC-OSCORE Compressed GET Request</name>
RuleID 0 <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------+--+--+--+--------------+-------+--------++------+
| 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 to the example
GET Request and CONTENT Response.
<xref target="Fig-Compressed-GET"/> and <xref target="Fig-Compressed-CONTENT"/>
show the resulting messages.</t>
<figure title="SCHC-OSCORE Compressed GET Request" anchor="Fig-Compressed-GET"><
artwork><![CDATA[
Compressed message: Compressed message:
================== ==================
0x001489458a9fc3686852f6c4 (12 bytes) 0x001489458a9fc3686852f6c4 (12 bytes)
0x00 RuleID 0x00 RuleID
1489 Compression Residue 1489 Compression Residue
458a9fc3686852f6c4 Padded payload 458a9fc3686852f6c4 Padded payload
Compression Residue: Compression Residue:
0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding) 0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding)
mid tkn piv kid mid tkn piv kid
Payload Payload
0xa2c54fe1b434297b62 (9 bytes) 0xa2c54fe1b434297b62 (9 bytes)
Compressed message length: 12 bytes Compressed message length: 12 bytes
]]></artwork></figure> ]]></artwork>
</figure>
<figure title="SCHC-OSCORE Compressed CONTENT Response" anchor="Fig-Compressed-C <figure anchor="Fig-Compressed-CONTENT">
ONTENT"><artwork><![CDATA[ <name>SCHC-OSCORE Compressed Content Response</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message: Compressed message:
================== ==================
0x0014218daf84d983d35de7e48c3c1852 (16 bytes) 0x0014218daf84d983d35de7e48c3c1852 (16 bytes)
0x00 RuleID 0x00 RuleID
14 Compression Residue 14 Compression Residue
218daf84d983d35de7e48c3c1852 Padded payload 218daf84d983d35de7e48c3c1852 Padded payload
Compression Residue: Compression Residue:
0b0001 010 (7 bits -> 1 byte with padding) 0b0001 010 (7 bits -> 1 byte with padding)
mid tkn mid tkn
Payload Payload
0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
Compressed msg length: 16 bytes Compressed message length: 16 bytes
]]></artwork></figure> ]]></artwork>
</figure>
<t>In contrast, comparing these results with what would be obtained by SCHC <t>In contrast, comparing these results with what would be obtained by S
CHC
compressing the original CoAP messages without protecting them with OSCORE is do ne compressing the original CoAP messages without protecting them with OSCORE is do ne
by compressing the CoAP messages according to the SCHC Rules in <xref target="Fi by compressing the CoAP messages according to the SCHC Rule in <xref target="Tab
g-NoOsc-Rules"/>.</t> le-NoOsc-Rule" format="default"/>.</t>
<figure title="SCHC-CoAP Rules (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"/> Rule yields the SCHC compression results in <table anchor="Table-NoOsc-Rule">
<xref target="Fig-GET-temp-no-oscore"/> for request, and <name>SCHC-CoAP Rule (No OSCORE)</name>
<xref target="Fig-CONTENT-temp-no-oscore"/> for the response.</t> <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>
<figure title="CoAP GET Compressed without OSCORE" anchor="Fig-GET-temp-no-oscor <t>The Rule in <xref target="Table-NoOsc-Rule" format="default"/> yields
e"><artwork><![CDATA[ the SCHC compression results as shown in <xref target="Fig-GET-temp-no-oscore"
format="default"/> for the request and
<xref target="Fig-CONTENT-temp-no-oscore" format="default"/> for the response.
</t>
<figure anchor="Fig-GET-temp-no-oscore">
<name>CoAP GET Compressed without OSCORE</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message: Compressed message:
================== ==================
0x0114 0x0114
0x01 = RuleID 0x01 = RuleID
Compression Residue: Compression Residue:
0b00010100 (1 byte) 0b00010100 (1 byte)
Compressed msg length: 2 Compressed message length: 2 bytes
]]></artwork>
]]></artwork></figure> </figure>
<figure anchor="Fig-CONTENT-temp-no-oscore">
<figure title="CoAP CONTENT Compressed without OSCORE" anchor="Fig-CONTENT-temp- <name>CoAP Content Compressed without OSCORE</name>
no-oscore"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Compressed message: Compressed message:
================== ==================
0x010a32332043 0x010a32332043
0x01 = RuleID 0x01 = RuleID
Compression Residue: Compression Residue:
0b00001010 (1 byte) 0b00001010 (1 byte)
Payload Payload
0x32332043 0x32332043
Compressed msg length: 6 Compressed message length: 6 bytes
]]></artwork>
]]></artwork></figure> </figure>
<t>As can be seen, the difference between applying SCHC + OSCORE as comp
<t>As can be seen, the difference between applying SCHC + OSCORE as compared to ared to
regular SCHC + COAP is about 10 bytes.</t> regular SCHC + CoAP is about 10 bytes.</t>
</section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>This document has no request to IANA.</t> </section>
<section anchor="SecConsiderations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<section anchor="SecConsiderations" title="Security considerations"> <t>The use of SCHC header compression for CoAP header fields only affects
the representation of the header information. SCHC header compression
<t>The use of SCHC header compression for CoAP header fields only affects
the representation of the header information.  SCHC header compression
itself does not increase or decrease the overall level of security of itself does not increase or decrease the overall level of security of
the communication.  When the connection does not use a security protocol the communication. When the connection does not use a security protocol
(such as OSCORE, DTLS, etc.), it is necessary to use a layer-two (OSCORE, DTLS, etc.), it is necessary to use a Layer 2
security mechanism to protect the SCHC messages.</t> security mechanism to protect the SCHC messages.</t>
<t>If an LPWAN is the Layer 2 technology being used, the SCHC security con
<t>If LPWAN is the layer-two technology, the SCHC security considerations siderations
of <xref target="RFC8724"></xref> continue to apply.  When using another layer-t discussed in <xref target="RFC8724" format="default"/> continue to apply. When
wo protocol, using another Layer 2 protocol, the
use of a cryptographic integrity-protection mechanisms to protect the use of a cryptographic integrity-protection mechanism to protect the
SCHC headers is REQUIRED.  Such cryptographic integrity protection is SCHC headers is <bcp14>REQUIRED</bcp14>. Such cryptographic integrity protection
necessary in order to continue to provide the properties that <xref target="RFC8 is
724"></xref> necessary in order to continue to provide the properties that <xref target="RFC8
724" format="default"/>
relies upon.</t> relies upon.</t>
<t>When SCHC is used with OSCORE, the security considerations discussed in
<t>When SCHC is used with OSCORE, the security considerations of <xref target="R <xref target="RFC8613" format="default"/>
FC8613"></xref>
continue to apply.</t> continue to apply.</t>
<t>When SCHC is used with the OSCORE Outer headers, the Initialization
<t>When SCHC is used with the OSCORE outer headers, the Initialization
Vector (IV) size in the Compression Residue must be carefully selected. Vector (IV) size in the Compression Residue must be carefully selected.
There is a tradeoff between compression efficiency (with a longer “MSB” There is a trade-off between compression efficiency (with a longer "MSB"
MO prefix) and the frequency at which the Device must renew its key 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 material (in order to prevent the IV from expanding to an uncompressible
value).  The key renewal operation itself requires several message value). The key-renewal operation itself requires several message
exchanges and requires energy-intensive computation, but the optimal exchanges and requires energy-intensive computation, but the optimal
tradeoff will depend on the specifics of the device and expected usage trade-off will depend on the specifics of the Device and expected usage
patterns.</t> patterns.</t>
<t>If an attacker can introduce a corrupted SCHC-compressed packet onto a
<t>If an attacker can introduce a corrupted SCHC-compressed packet onto a link, DoS attacks can be mounted by causing excessive resource consumption
link, DoS attacks are possible by causing excessive resource consumption at the decompressor. However, an attacker able to inject packets at the
at the decompressor.  However, an attacker able to inject packets at the
link layer is also capable of other, potentially more damaging, attacks.</t> link layer is also capable of other, potentially more damaging, attacks.</t>
<t>SCHC compression emits variable-length Compression Residues for some
<t>SCHC compression emits variable-length Compression Residues for some CoAP fields. In the representation of the compressed header, the length field
CoAP fields.  In the compressed header representation, the length field
that is sent is not the length of the original header field but rather that is sent is not the length of the original header field but rather
the length of the Compression Residue that is being transmitted.  If a the length of the Compression Residue that is being transmitted. If a
corrupted packet arrives at the decompressor with a longer or shorter corrupted packet arrives at the decompressor with a longer or shorter
length than the original compressed representation possessed, the SCHC length than the original compressed representation possessed, the SCHC
decompression procedures will detect an error and drop the packet.</t> decompression procedures will detect an error and drop the packet.</t>
<t>SCHC header compression Rules <bcp14>MUST</bcp14> remain tightly couple
<t>SCHC header compression rules MUST remain tightly coupled between d between the
compressor and decompressor.  If the compression rules get out of sync, compressor and the decompressor. If the compression Rules get out of sync,
a Compression Residue might be decompressed differently at the receiver a Compression Residue might be decompressed differently at the receiver
than the initial message submitted to compression procedures. than the initial message submitted to compression procedures.
Accordingly, any time the context Rules are updated on an OSCORE Accordingly, any time the context Rules are updated on an OSCORE
endpoint, that endpoint MUST trigger OSCORE key re-establishment. endpoint, that endpoint <bcp14>MUST</bcp14> trigger OSCORE key re-establishment.
Similar procedures may be appropriate to signal Rule udpates when other Similar procedures may be appropriate to signal Rule updates when other
message-protection mechanisms are in use.</t> message-protection mechanisms are in use.</t>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors would like to thank (in alphabetic order): Christian Amsuss, Domi
nique Barthel, Carsten Bormann, Theresa Enghardt, Thomas Fossati, Klaus Hartke,
Benjamin Kaduk, Francesca Palombini, Alexander Pelov, Goran Selander and Eric Vy
ncke.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<references title='Normative References'> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> .2119.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<title>Key words for use in RFCs to Indicate Requirement Levels</title> .5116.xml"/>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
author> .7252.xml"/>
<date year='1997' month='March' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<abstract><t>In many standards track documents several words are used to signify .7967.xml"/>
the requirements in the specification. These words are often capitalized. This <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
document defines these words as they should be interpreted in IETF documents. .7641.xml"/>
This document specifies an Internet Best Current Practices for the Internet Comm <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
unity, and requests discussion and suggestions for improvements.</t></abstract> .7959.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<seriesInfo name='BCP' value='14'/> .8174.xml"/>
<seriesInfo name='RFC' value='2119'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<seriesInfo name='DOI' value='10.17487/RFC2119'/> .8613.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8724.xml"/>
<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 /></au
thor>
<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-independen
t set of cryptoalgorithm suites. This approach provides advantages in efficienc
y and security, and promotes the reuse of crypto implementations. [STANDARDS-TR
ACK]</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 /></au
thor>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></au
thor>
<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 tr
ansfer protocol for use with constrained nodes and constrained (e.g., low-power,
lossy) networks. The nodes often have 8-bit microcontrollers with small amount
s of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireles
s Personal Area Networks (6LoWPANs) often have high packet error rates and a typ
ical throughput of 10s of kbit/s. The protocol is designed for machine- to-mach
ine (M2M) applications such as smart energy and building automation.</t><t>CoAP
provides a request/response interaction model between application endpoints, sup
ports 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 inte
rface with HTTP for integration with the Web while meeting specialized requireme
nts 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</ti
tle>
<author initials='A.' surname='Bhattacharyya' fullname='A. Bhattacharyya'><organ
ization /></author>
<author initials='S.' surname='Bandyopadhyay' fullname='S. Bandyopadhyay'><organ
ization /></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 respon
ses 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 (NO
N) messages that are not acknowledged by the recipient. However, the request/re
sponse semantics still require the server to respond with a status code indicati
ng &quot;the result of the attempt to understand and satisfy the request&q
uot;, 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 i
ts disinterest in all responses against the particular request. This option also
provides granular control to enable expression of disinterest to a particular r
esponse class or a combination of response classes. The server MAY decide to su
ppress the response by not transmitting it back to the client according to the v
alue 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 exampl
es 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 /></au
thor>
<date year='2015' month='September' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful applicatio
n protocol for constrained nodes and networks. The state of a resource on a CoA
P server can change over time. This document specifies a simple protocol extens
ion for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., t
o retrieve a representation of a resource and keep this representation updated b
y the server over a period of time. The protocol follows a best-effort approach
for sending new representations to clients and provides eventual consistency be
tween the state observed by each client and the actual resource state at the ser
ver.</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)</titl
e>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby' role='editor'><organ
ization /></author>
<date year='2016' month='August' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful transfer p
rotocol for constrained nodes and networks. Basic CoAP messages work well for s
mall payloads from sensors and actuators; however, applications will need to tra
nsfer larger payloads occasionally -- for instance, for firmware updates. In co
ntrast to HTTP, where TCP does the grunt work of segmenting and resequencing, Co
AP is based on datagram transports such as UDP or Datagram Transport Layer Secur
ity (DTLS). These transports only offer fragmentation, which is even more probl
ematic 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;Bl
ock&quot; options for transferring multiple blocks of information from a resourc
e representation in multiple request-response pairs. In many important cases, t
he Block options enable a server to be truly stateless: the server can handle ea
ch block transfer separately, with no need for a connection setup or other serve
r-side memory of previous block transfers. Essentially, the Block options provi
de 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 limite
d in the size of the representations that can be exchanged, so there is an expec
tation that the Block options will be widely used in CoAP implementations. Ther
efore, 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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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 /></auth
or>
<date year='2019' month='July' />
<abstract><t>This document defines Object Security for Constrained RESTful Envir
onments (OSCORE), a method for application-layer protection of the Constrained A
pplication Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OS
CORE provides end-to-end protection between endpoints communicating using CoAP o
r CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supp
orting a range of proxy operations, including translation between different tran
sport protocols.</t><t>Although an optional functionality of CoAP, OSCORE alters
CoAP options processing and IANA registration. Therefore, this document update
s 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 Fragmen
tation</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 /></auth
or>
<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 fra
gmentation (SCHC) framework, which provides both a header compression mechanism
and an optional fragmentation mechanism. SCHC has been designed with Low-Power W
ide 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 appl
ication to compress IPv6/UDP headers.</t><t>This document also specifies an opti
onal fragmentation and reassembly mechanism. It can be used to support the IPv6
MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 da
tagrams 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 o
ver which they are used. This document defines generic functionalities and offer
s flexibility with regard to parameter settings and mechanism choices. This docu
ment standardizes the exchange over the LPWAN between two SCHC entities. Setting
s and choices specific to a technology or a product are expected to be grouped i
nto profiles, which are specified in other documents. Data models for the contex
t and profiles are out of scope.</t></abstract>
</front>
<seriesInfo name='RFC' value='8724'/>
<seriesInfo name='DOI' value='10.17487/RFC8724'/>
</reference>
</references> </references>
</back> <section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<!-- ##markdown-source: <t>The authors would like to thank (in alphabetic order):
H4sIAOw+RmAAA+19aXcbx5Xo9/4VdegPIkcADFAktTjOG4qkYj6LIiPS9swk <contact fullname="Christian Amsuss"/>, <contact fullname="Dominique Barthel"/>,
PjkNoEF2CHTjdTe4TOj5Lf4t/mXvrrX0wkXS5OTMBFlENLqqbt26devu1e/3 <contact fullname="Carsten Bormann"/>, <contact fullname="Theresa Enghardt"/>,
o7KKs+lf4nmeJW9MVaySKF0W9FdZbQ6Hr4eb0TSfZPECfp4W8azqp0k168+X <contact fullname="Thomas Fossati"/>, <contact fullname="Klaus Hartke"/>, <conta
13HWn+Txsg89VOkE/s6q5KbqX0z6o9fRJK7emLKaRsv0TWRMebsokln5xjy7 ct fullname="Benjamin Kaduk"/>, <contact fullname="Francesca Palombini"/>, <cont
Tcpn+CAvqtqTqkgnlfs+yRfL2H9Q5RP9ElVpNQeA3p/8tPvBnBIAZo8BMN8l act fullname="Alexander Pelov"/>, <contact fullname="Göran Selander"/>, and
8TQp4OtiWSRlmeaZWT/d+25vw8xyfLx7EsXjcZFcaXt8RMPJ69H1+RtDEzQ/ <contact fullname="Éric Vyncke"/>.</t>
5cVlmp2bPxT5ahnFq+oiL95EfZNmAPnuwBylWTxeFTmAxyjazWL/YV5AV7uT </section>
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
</back>
</rfc> </rfc>
 End of changes. 100 change blocks. 
1488 lines changed or deleted 1331 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/