]> RISE AB

Isafjordsgatan 22 Kista 16440 Sweden marco.tiloca@ri.se

IMT Atlantique

CS 17607, 2 rue de la Chataigneraie Cesson-Sevigne Cedex 35576 France Laurent.Toutain@imt-atlantique.fr

IRISA

263 Av. Général Leclerc Rennes 35000 France ivan-marino.martinez-bolivar@irisa.fr

Consultant

Rue de Rennes Cesson-Sevigne 35510 France anaminaburo@gmail.com

Internet SCHC Working Group Internet-Draft This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices, and it uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. Discussion Venues Discussion of this document takes place on the Static Context Header Compression Working Group mailing list (schc@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) is a request/response protocol designed for microcontrollers with small RAM and ROM, and optimized for services based on REST (Representational State Transfer). Although constrained devices are a leading factor in the design of CoAP, a CoAP header's size is still too large for Low-Power Wide-Area Networks (LPWANs). Applying the Static Context Header Compression and fragmentation (SCHC) framework to CoAP headers is particularly important for improving performance or for enabling the use of CoAP over LPWAN technologies. defines the SCHC framework, which includes a header compression mechanism for LPWANs that is based on a static SCHC Context. explains where compression and decompression occur in the architecture. The SCHC compression scheme assumes as a prerequisite that communicating SCHC Instances share the SCHC Context before message transmission. The way the SCHC Context is configured, provisioned, or exchanged is out of the scope of this document. Since CoAP is an application-layer protocol, compressing CoAP headers requires installing on the communicating SCHC Instances a common SCHC Context that contains the common SCHC Set of Rules (SoR). SCHC compression may apply at two different levels: at the IP and UDP level in the LPWAN, as well as at the application level for CoAP. These two compression techniques may be independent; they are then performed by distinct SCHC Instances, each operating with its own SCHC Context. Both follow the same principle as that described in . As different entities manage the CoAP compression process at different levels, the SCHC Rules driving the compression/decompression are also different. describes how to use SCHC for IP and UDP headers. This document specifies how to apply SCHC compression to CoAP headers. SCHC compresses and decompresses headers based on a common SCHC Context shared between SCHC Instances. The SCHC Context includes multiple Rules in its SCHC Set of Rules (SoR). Each Rule can match the header fields to specific values or ranges of values. If a Rule matches, then the Rule is selected. When performing compression, the matched header fields are replaced by the RuleID and the Compression Residue that contains the residual bits of the compression. Thus, different Rules may correspond to different protocol headers in the packet that a Device expects to send or receive. A Rule describes the packets' entire header with an ordered list of Field Descriptors (see ). In turn, each Field Descriptor contains the Field ID (FID), Field Length (FL), and Field Position (FP), as well as a Direction Indicator (DI) (upstream, downstream, or bidirectional) and some associated Target Values (TVs). The DI allows the compression to be based on the best TV for the Field Descriptor, when the TV to consider is different for the different transmission directions. Therefore, a field may be described several times in the same Rule. Furthermore, a Matching Operator (MO) is associated with each header Field Descriptor. A Rule is selected if all the MOs fit the TVs for all the fields of the header. A Rule cannot be selected if the message contains a field that is unknown to the SCHC compressor. Within a Rule, a Compression/Decompression Action (CDA) associated with each field specifies the method to compress and decompress that field. Compression mainly results in one of four actions:

• send the field value (value-sent),
• send nothing (not-sent),
• send some Least Significant Bits (LSBs) of the field, or
• send an index (mapping-sent).

After applying the compression, there may be some bits to be sent. These values are called "Compression Residue". SCHC is a general mechanism applied to different protocols, with the exact Rules to be used depending on the protocol and the application. describes the compression scheme for IPv6 and UDP headers. This document targets CoAP header compression using SCHC. The use of SCHC compression applied to CoAP headers was originally defined in . While this document does not alter the core approach, design choices, and features specified therein, this document clarifies, updates, and extends the SCHC compression of CoAP headers defined in . In particular, this documents replaces and obsoletes as follows:

• It provides clarifications and amendments to the original specification text, based on collected feedback and reported errata.
• It clarifies the use of the FL within Field Descriptors corresponding to variable-length header fields (see ).
• It generalizes the handling of the Token Length field and of the Token field as well as the use of the "tkl" function to comply with (see and ).
• It clarifies how the SCHC compression handles CoAP options in general (see ).
• It clarifies the SCHC compression for the CoAP options Size1, Size2, Proxy-Uri, and Proxy-Scheme (see ).
• It defines the SCHC compression for the recently defined CoAP options Proxy-Cri and Proxy-Scheme-Number (see ).
• It updates the SCHC compression processing for the CoAP options: ETag and If-Match (see ); and If-None-Match (see ).
• It defines the SCHC compression for the CoAP option Hop-Limit (see ).
• It defines the SCHC compression for the recently defined CoAP options Echo (see ), Request-Tag (see ), EDHOC (see ), as well as Q-Block1 and Q-Block2 (see ).
• It updates the SCHC compression processing for the CoAP option OSCORE (see ), also in the light of recent developments related to the security protocol Object Security for Constrained RESTful Environments (OSCORE) as defined in .
• It clarifies how the SCHC compression handles the CoAP payload marker (see ).
• It defines the SCHC compression of CoAP headers in the presence of CoAP proxies (see ), for which examples are provided (see ).

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts related to the SCHC framework defined in . This document uses the following terms that reflect the terminology introduced in . They all include the word "SCHC" followed by a word that starts with an uppercase letter, in order to avoid ambiguities with similar terms pertaining to other protocols.

• SCHC Endpoint: A logical entity that provides SCHC functionality by hosting the SCHC processing code, rather than a physical device. Multiple SCHC Endpoints can operate on the same physical equipment.
• SCHC Instance: A logical component of a SCHC Endpoint that executes the actual SCHC operations, e.g., compressing and decompressing headers, or fragmenting and reassembling packets. Multiple SCHC Instances can coexist on the same SCHC Endpoint, but each SCHC Instance operates independently, with its own SCHC Context and configuration.
• SCHC Set of Rules (SoR): The collection of Compression and Decompression (C/D), Fragmentation and Reassembly (F/R), and no-compression Rules available to a SCHC Instance.
• SCHC Context: A SCHC SoR together with metadata, shared by two or more SCHC Instances. Metadata may, for example, refer to a data model or a parser compatible with the Rule format.
• SCHC Session: A communication session between two or more SCHC Instances that share a common SCHC Context for SCHC operations.

Readers are also expected to be familiar with the terms and concepts related to:

• CoAP . A notable term is "endpoint", i.e., "[a]n entity participating in the CoAP protocol". This is not to be confused with the term "SCHC Endpoint".
• The security protocols OSCORE and Group Object Security for Constrained RESTful Environments (Group OSCORE) . A notable term is "OSCORE Security Context", denoting the set of information elements necessary to carry out the cryptographic operations in OSCORE. Although not used in this document, the equivalent term "Group OSCORE Security Context" applies to Group OSCORE and its cryptographic operations. These are not to be confused with the term "SCHC Context".

Finally, building on the term "endpoint" from listed above, this document uses the following terminology:

• The terms "origin endpoint" and "application endpoint" interchangeably denote an origin CoAP client or an origin CoAP server.
• The terms "sender endpoint" and "recipient endpoint" denote an endpoint that sends and receives a CoAP message, respectively.
• The term "OSCORE endpoint" denotes an endpoint that processes a CoAP message using OSCORE or Group OSCORE.

The terms "endpoint", "origin endpoint", "application endpoint", "sender endpoint", "recipient endpoint", and "OSCORE endpoint" only pertain to CoAP and (Group) OSCORE. That is, they do not denote a SCHC Endpoint. If any such endpoint is also a SCHC Endpoint, then the SCHC operations that it performs are executed by a SCHC Instance within that SCHC Endpoint.

SCHC Applicability to CoAP SCHC compression for CoAP headers MAY be done in conjunction with the lower layers (IPv6/UDP) or independently. The SCHC adaptation layers described in may be used as shown in , , and below. In the first example depicted in , a Rule compresses the complete header stack from IPv6 to CoAP. In this case, the Device and the Network Gateway (NGW) each comprise a SCHC Endpoint with a SCHC Instance. These SCHC Instances share a common SCHC Context and communicate using a SCHC Session. The application communicating with the Device does not implement SCHC C/D and does not comprise a SCHC Endpoint.

Compression/Decompression at the LPWAN Boundary.

shows the use of SCHC header compression above Layer 2 in the Device and the NGW. The SCHC Instance at the Device receives non-encrypted packets and applies a matching Rule from its SCHC Context to all the headers in the stack. On the other end, the NGW receives the SCHC packet, internally routes it to its correct SCHC Instance, and reconstructs the headers using a matching Rule and the Compression Residue. After the decompression, the NGW forwards the IPv6 packet toward the destination. The same process applies in the other direction when a non-encrypted packet arrives at the NGW. Thanks to the IP forwarding based on the IPv6 prefix, the NGW identifies the Device and compresses headers using a matching Rule from the SCHC Context of the appropriate SCHC Instance. In the second example depicted in , SCHC compression is applied in the CoAP layer, compressing the CoAP header independently of the other layers. The RuleID, Compression Residue, and CoAP payload are encrypted using a mechanism such as DTLS . Only the other end (App) can decrypt the incoming information and then perform SCHC decompression, using a matching Rule from the SCHC Context of the appropriate SCHC Instance. If needed, layers below use separate SCHC Instances to compress and decompress the corresponding headers as defined in (represented by dotted lines in the figure). This use case needs that an end-to-end SCHC Instance and SCHC Context therein are established between the Device and the application. The establishment of the SCHC Instance and SCHC Context is out of scope for this document.

Standalone CoAP End-to-End Compression/Decompression.

The third example depicted in shows the use of the security protocol OSCORE . In this case, the CoAP header is compressed by using in sequence two distinct SCHC Instances on the same SCHC Endpoint, at the Device or at the application. That is, a matching Rule from the SCHC Context of a first SCHC Instance is used to compress the Inner header. The result of this first compression is encrypted using OSCORE. Then, a matching Rule from the SCHC Context of a second SCHC Instance is used to compress the Outer header including the CoAP option OSCORE.

Compression/Decompression when Using OSCORE.

In the case of several SCHC Instances as shown in and , each SCHC Instance operates independently with its own SCHC Context. The SCHC Contexts can be independently provided and managed. This document focuses on CoAP compression, as represented by the dashed boxes in the previous figures.

CoAP Headers Compressed with SCHC The use of SCHC over the CoAP header relies on the same principles and compression/decompression techniques used for IP and UDP headers, as explained in . For CoAP, the SCHC Rules description uses the direction information to optimize the compression by reducing the number of Rules needed to compress headers. The Field Descriptor MAY define both request/response headers and TVs in the same Rule, using the DI to indicate the header type. Like for other header compression protocols, when the compressor does not find a correct Rule to compress the header, the packet MUST be sent uncompressed using the RuleID dedicated to this purpose. In such a case, the Compression Residue is the complete header of the packet (see ).

Differences between CoAP and UDP/IP Compression CoAP compression differs from IPv6 and UDP compression in the following aspects:

• The CoAP message format is asymmetric, i.e., the headers are different for a request and a response. For example, the Uri-Path Option can be used in a request, while it is not used in a response. A request might contain an Accept Option, while both a request and a response might include a Content-Format Option. In comparison, the IPv6 and UDP returning path swaps the value of some fields in the header. However, all the directions have the same fields (e.g., source and destination address fields). defines the use of a DI in the Field Descriptor, which allows a single Rule to process a message header differently, depending on the direction.
• Even when a field is "symmetric" (i.e., found in both directions), the values carried in each direction are different. The compression may use a "match-mapping" MO to limit the range of expected values in a particular direction and reduce the Compression Residue's size. Through the DI, a Field Descriptor in the Rules splits the possible field value into two parts, one for each direction. For instance, if a client sends only Confirmable (CON) requests , the Type can be elided through the compression process, and the reply from the server may use one single bit to carry either the Acknowledgement (ACK) or Reset (RST) type. The field Code has the same behavior: the 0.0X code format value in a request and the Y.ZZ code format in a response.
• 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. On the other hand, some CoAP header fields have variable lengths and the Rule description makes it possible to specify it. For example, the size of the Token field may vary from 0 to 65804 bytes , and the CoAP options rely on the Type-Length-Value encoding format to specify the size of the actual option value in bytes. Given a Rule description and building on , the following defines how the FL is used within the Field Descriptor corresponding to a variable-length field. If the field compression relies on the CDA "value-sent" or LSB, then a function "var" can be used for the FL in the Field Descriptor, with byte being the unit used for the residue value's size. In such case, the residue value's size prepended to the residue value encodes the size of the residue value in bytes, and the decompressor MUST interpret the residue value as consisting of exactly that number of bytes. Alternatively to "var", a function "var_X" can be used for the FL in the Field Descriptor, with X being the unit other than byte that is used for the residue value's size. In particular, this document defines the function "var_bit". When the function "var_bit" is used, the residue value's size prepended to the residue value encodes the size of the residue value in bits, and the decompressor MUST interpret the residue value as consisting of exactly that number of bits. That is, since byte alignment in SCHC applies only at the end of the SCHC packet, the decompressor does not add any per-field padding. When using the function "var" or a function "var_X" in the FL of the Field Descriptor, SCHC will send the residue value's size in the Compression Residue encoded as specified in , using the unit associated with the function. For example, if the function "var_bit" is used and the residue value's size for the compressed field is 17 bits, that size is encoded as 0b1111 00010001. As an alternative to the function "var" or to a function "var_X", if the length of the present field can be determined from the value of a previous field in the CoAP header, then it is possible to define a specific function for the FL in the Field Descriptor of the present field, with that function returning the length of the field in the unit specified with the function (e.g., see the "tkl" function defined in ). Instead, if the field compression relies on the CDA "not-sent" or "mapping-sent", then the same as above applies, with the following differences:
  • The length of the present field is consistent:
    • With the length of the value that is specified in the TV of the Field Descriptor, if CDA is set to "not sent"; or
    • With the length of at least one of the values that are specified in the TV of the Field Descriptor, if CDA is set to "mapping-sent".
  • The function "var" (or any alternative function "var_X") used in the FL of the Field Descriptor still indicates that the length of the present field is variable. However, since the CDA in the Field Descriptor is such that SCHC does not send the residue value's size in the Compression Residue (see ), the unit associated with the function plays no role.
• A field can appear several times in a CoAP header. This is typically the case for elements of a URI (i.e., path segments or query parameters). The SCHC specification allows an FID to appear several times in the Rule and uses the Field Position (FP) to identify the correct occurrence of that field, thus preventing MO's possible ambiguities.
• Field Lengths defined in CoAP can be too large when it comes to LPWAN traffic constraints. For instance, this is particularly true for the Message ID field and the Token field. SCHC uses different MOs to perform the compression (see ). In this case, SCHC can apply the Most Significant Bits (MSBs) MO to reduce the information carried on LPWANs.

Compression of CoAP Header Fields This section discusses the SCHC compression of the CoAP header fields (see ), building on what is specified in . In a SCHC Rule, the first Field Descriptors MUST be those related to the CoAP header fields discussed in this section. In particular, such Field Descriptors MUST be listed in the same order according to which the related CoAP header fields are specified in a CoAP message, i.e.: Version; Type; Token Length; Code; Message ID; and Token (if any). In the rest of this section, those CoAP header fields are discussed according to such an order.

CoAP Version Field The Version field is described as bidirectional in a SCHC Rule, and it MUST be elided during SCHC compression, since it always contains the same value. If a new version of CoAP is defined in the future, new Rules will be needed to avoid ambiguities between versions.

CoAP Type Field The Type field specifies one of the four types of CoAP messages, encoded as specified in : Confirmable (CON), Non-confirmable (NON), Acknowledgement (ACK), and Reset (RST). The SCHC compression scheme SHOULD elide this field if, for instance, a client is sending only NON messages or only CON messages. For RST messages, SCHC may use a dedicated Rule. For other usages, SCHC can use a "match-mapping" MO.

CoAP Token Length (TKL) Field The Token Length (TKL) field specifies the size in bytes of the later Token field (see ) and is described as bidirectional in a SCHC Rule. The Token Length field was originally defined to have a fixed length of 4 bits (see ). Later on, its definition was updated by , thus making Token Length a variable-length field that can have a length of 4, 12, or 20 bits. In particular, the first 4 bits are always present and directly precede the Code field (see ). The value of the first 4 bits determines whether the field comprises 8 or 16 additional bits. In such a case, the additional 8 or 16 bits immediately precede the Token field. In any case, SCHC treats Token Length as a single field of size 4, 12, or 20 bits, which still specifies the size in bytes of the later Token field, as per . If the Token Length field value does not change over time, the SCHC Rule describes the TV set to that value, the MO set to "equal", and the CDA set to "not-sent", thereby eliding the field. Otherwise, if the Token Length field value changes over time, the SCHC Rule does not set the TV, while setting the MO to "ignore" and the CDA to "value-sent". The Rule may also use a "match-mapping" MO to compress the value.

CoAP Code Field The Code field takes value from the "Code" column of the "CoAP Codes" IANA registry, encoded as specified in . This field indicates the Method Code of a CoAP request or the Response Code of a CoAP Response, while the value 0.00 indicates an Empty message. The compression of the CoAP Code field follows the same principle as that of the CoAP Type field. If the Device plays a specific role, SCHC may split the code values into two Field Descriptors: (1) the Method Codes with the 0 class and (2) the Response Codes. SCHC will then use the DI to identify the correct value in the packet. If the Device only implements a CoAP client, SCHC compression may focus only on the Method Codes that the client uses in its outgoing requests. 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.

CoAP Message ID Field SCHC can compress the Message ID field with the MSB MO and the LSB CDA (see ).

CoAP Token Field A CoAP message fully specifies the Token by using two CoAP fields: the Token Length (TKL) field in the mandatory header (see ) and the variable-length Token field that directly follows the mandatory CoAP header and specifies the Token value. For the Token field, SCHC MUST NOT send it as variable-size data in the Compression Residue. As a result, SCHC does not send the size of the residue resulting from the compression of the Token field, which is otherwise requested for variable-size fields when the CDA specified in the Field Descriptor is "value-sent" or LSB (see ). Instead, SCHC MUST use the value of the Token Length field to define the size of the Token field in the Compression Residue. To this end, SCHC designates a specific function, "tkl", that the Rule MUST use to complete the Field Descriptor. During the decompression, this function returns the length of the Token field in bytes, which is specified by the Token Length field as per . This construct avoids ambiguity with the Token Length field and results in a more efficient compression of the Token field.

Compression of CoAP Options CoAP defines the use of options, which are placed after the mandatory header and the Token field and are ordered by option number (see ). As per , each occurrence of an option in a message relies on a format consisting of an Option Delta (D), an Option Length (L), and an Option Value (V). The Option Delta is used to express the option number of a CoAP option within a CoAP message, as the difference between the Option Number of that option and the Option Number of the previous option in that message (or zero for the first option). In the byte-representation of CoAP options used on the wire, Option Delta is encoded either by a 4-bit "Option Delta" field or by that field together with an additional 1- or 2-byte "Option Delta (Extended)" field. The Option Length specifies the length of the Option Value in bytes. In the byte-representation of CoAP options used on the wire, Option Length is encoded either by a 4-bit "Option Length" field or by that field together with an additional 1- or 2-byte "Option Length (Extended)" field.

Field Descriptors for CoAP Options In a SCHC Rule, the Field Descriptors related to CoAP options MUST be specified after the Field Descriptors related to the CoAP header fields discussed in . In particular, the Field Descriptors related to CoAP options MUST be listed in the same order according to which the corresponding CoAP options appear in the CoAP message (i.e., ordered by option number). If a SCHC Rule is intended to compress a CoAP message where a repeatable CoAP option is specified multiple times, then the SCHC Rule generally includes different Field Descriptors that separately correspond to the different occurrences of that CoAP option. Those Field Descriptors MUST be listed in the same order of the corresponding CoAP option occurrences in the CoAP message. In order to optimize the compression, a single Field Descriptor MAY pertain to multiple adjacent occurrences of the same CoAP option that are treated as grouped together (e.g., see ). As further discussed in , the composition and use of Field Descriptors for compressing/decompressing CoAP options can take a "syntactic" approach or a "semantic" approach. The syntactic approach operates faithfully to the byte-representation of CoAP options used on the wire. Consequently, it requires multiple Field Descriptors for each given occurrence of CoAP option to be compressed/decompressed. That is, each of such Field Descriptors pertains to the compression/decompression of the Option Delta, the Option Length, or the Option Value of the CoAP option in question. On the contrary, the typically used semantic approach abstracts away from the byte-representation of CoAP options (or, more generally, of protocol header fields) and maps those into generic representations identified by the FIDs of the related Field Descriptors. The semantic approach effectively streamlines Field Descriptors related to CoAP options as required to specify only information about the compression/decompression of the Option Value. The rest of this document refers to the semantic approach, especially when defining the SCHC compression/decompression of CoAP options as well as when providing examples of CoAP header compression.

Option Value For most CoAP options, the Option Value is a single indivisible field. Consequently, the compression/decompression of the Option Value for such a CoAP option is specified by a Field Descriptor for which the following applies:

• The FID is set to an identifier that unambiguously refers to the CoAP option in question. To this end, the FID provides the following information:
  • An unambiguous identifier of CoAP, as the protocol for which a message is meant to be compressed/decompressed per the present Field Descriptor.
  • The option number of the CoAP option to be compressed/decompressed per the present Field Descriptor. For registered CoAP options, the value is taken from the "Number" column of the corresponding entry in the "CoAP Option Numbers" IANA registry .
  For example, the FID can be set to "CoAP.option(3)" in a Field Descriptor related to the CoAP Uri-Host Option (see ).
• The FL represents the Option Length L of the CoAP option encoded as per .
• The TV is either set to an appropriate value (e.g., the Option Value V of the CoAP option) or not set, consistent with the intent of the SCHC Rule and with the MO and CDA used in the Field Descriptor.

For some CoAP options, it might be possible and more convenient for SCHC to consider the Option Value as composed of distinct subfields. An example is the CoAP OSCORE Option defined in and for which the SCHC compression/decompression is defined in of this document. Instead of pertaining to the SCHC compression/decompression of the Option Value as a whole, a Field Descriptor related to such a CoAP option can instead specifically pertain to the SCHC compression/decompression of one subfield of the Option Value. In this case, the Field Descriptors related to different subfields of the Option Value of a given CoAP option MUST be listed in the same order according to which the corresponding subfields appear in the Option Value. Furthermore, the following applies to each of such Field Descriptors:

• The FID is set to an identifier that unambiguously refers to the CoAP option in question and to the subfield to be compressed/decompressed. To this end, in addition to the two pieces of information mentioned above for the previous case, the FID further provides the following information:
  • An unambiguous identifier of the subfield of the Option Value of the CoAP option to be compressed/decompressed per the present Field Descriptor.
  For example, the FID can be set to "CoAP.option(9).flags" in a Field Descriptor pertaining to the "flags" subfield of the Option Value of the CoAP OSCORE Option (see ).
• The FL either represents the length of the subfield encoded as per or denotes a designated function to compute that length.
• The TV is either set to an appropriate value (e.g., the value of the subfield) or not set, consistent with the intent of the SCHC Rule and with the MO and CDA used in the Field Descriptor.

Note that the MO and the CDA specified in the Field Descriptor operates only on the (subfield of the) Option Value V. That is, SCHC compression produces a residue from the (subfield of the) Option Value V, while ignoring the option number, the Option Delta, and the Option Length or the length of the Option Value's subfield. Therefore, the residue of a SCHC packet conveying a compressed CoAP header does not include the option number, the Option Delta, and the Option Length of the compressed CoAP options. The recipient will be able to reconstruct those when performing SCHC decompression, leveraging the FID and FL of the Field Descriptors within the SCHC Rule used. When the Option Length or the length of the Option Value's subfield has a well-known value, the Rule may specify that information in the FL of the Field Descriptor (see above). In such a case, SCHC compression treats the (subfield of the) Option Value as a fixed-length field (see ). Otherwise, the Rule specifies the FL of the Field Descriptor as indicating a variable length and SCHC compression treats the (subfield of the) Option Value as a variable-length field (see ). In such a case, when the CDA specified in the Field Descriptor is "value-sent" or LSB, then SCHC compression additionally carries the length of the Compression Residue, as prepended to the Compression Residue value. Note that the length coding differs between CoAP options and the Compression Residue of SCHC variable-length fields. CoAP requests and responses do not include the same options. Compression Rules may reflect this asymmetry by using the DI. The following sections present how SCHC compresses some specific CoAP options. Unless otherwise indicated, the referred CoAP options are specified in . If the use of an additional CoAP option is later introduced, the SCHC Rules MAY be updated, in which case a new FID description MUST be assigned to perform the compression of the CoAP option. Otherwise, if no Rule describes that CoAP option, SCHC compression is not achieved and SCHC sends the CoAP header without compression.

CoAP Option Content-Format and Accept Fields If the client expects a single specific value, SCHC can elide these fields, by specifying the value in the TV of a Rule description with an "equal" MO and a "not-sent" CDA. Otherwise, if the client expects several possible values, a "match-mapping" MO SHOULD be used to limit the Compression Residue's size. If not, SCHC has to send the Option Value in the Compression Residue (with fixed or variable length).

CoAP Option Max-Age, Uri-Host, and Uri-Port Fields SCHC compresses these three fields in the same way. When the values of these options are known, SCHC can elide these fields. If the option uses well-known values, SCHC can use a "match-mapping" MO. Otherwise, these options' values will be sent in the Compression Residue, i.e., the SCHC Rule description does not set the TV, while setting the MO to "ignore" and the CDA to "value-sent".

CoAP Option Uri-Path and Uri-Query Fields The Uri-Path and Uri-Query fields are repeatable options, i.e., the CoAP header may include them several times and with different values. The SCHC Rule description uses the FP to distinguish the different occurrences of such options. To compress these repeatable field values, SCHC can use a "match-mapping" MO to reduce the size of variable paths or queries. When doing so, several elements can be regrouped into a single entry in order to optimize the compression. The numbering of elements does not change, and the first matching element sets the MO comparison. For example, as per the Rule descriptions shown in , SCHC can use a single bit in the Compression Residue to code the path segments "/a/b" or the path segments "/c/d". If regrouping were not allowed, then 2 bits in the Compression Residue would be needed. At the same time, SCHC sends the third path element following "/a/b" or "/c/d" as a variable-size field in the Compression Residue. Complex Path Example. CoAP Option Numbers: 11 (Uri-Path).

FID	FL	FP	DI	TV	MO	CDA
CoAP. option(11)	var	1	Up	["/a/b", "/c/d"]	match-mapping	mapping-sent
CoAP. option(11)	var	3	Up		ignore	value-sent

The length of the Uri-Path and Uri-Query Options may be known when the Rule is defined. In any other case, SCHC MUST set the Field Length (FL) to a variable value. The unit of the variable length is bytes, hence the Compression Residue size is expressed in bytes, encoded as defined in . SCHC compression can use the MSB MO for a Uri-Path or Uri-Query element. In such a case, care must be taken when specifying the MSB parameter value in bits, which MUST be a multiple of 8. The length sent at the beginning of the variable-size field Compression Residue indicates the LSB's size in bytes, consistent with the unit of the variable length in the Rule description. For instance, for a CORECONF path /c/X6?k=eth0, the Rule description can be as shown in . That is, SCHC compresses the first part of the URI path with a "not-sent" CDA. Also, SCHC will send the second element of the URI path preceded by the length (i.e., 0b0010 "X6"), which is followed by the query parameter's value preceded by the length (i.e., 0b0100 "eth0"). CORECONF URI compression. CoAP Option Numbers: 11 (Uri-Path), 15 (Uri-Query).

FID	FL	FP	DI	TV	MO	CDA
CoAP. option(11)	var	1	Up	"c"	equal	not-sent
CoAP. option(11)	var	2	Up		ignore	value-sent
CoAP. option(15)	var	1	Up	"k="	MSB(16)	LSB

SCHC fixes the number of Uri-Path or Uri-Query elements in a Rule at Rule creation time. If it is expected that the number of such elements varies across different CoAP messages, then different SCHC Rules need to be created in order to cover the different possibilities.

CoAP Option Size1, Size2, Proxy-Uri, and Proxy-Scheme Fields The Size2 field is an option defined in . The SCHC Rule description MAY define sending some field values by not setting the TV, while setting the MO to "ignore" and the CDA to "value-sent". A Rule MAY also use a "match-mapping" MO when there are different alternatives for the same FID. Otherwise, the Rule sets the TV to a specific value, the MO to "equal", and the CDA to "not-sent".

CoAP Option Proxy-Cri and Proxy-Scheme-Number Fields The Proxy-Cri field is an option defined in . The option carries an encoded CBOR data item that represents an absolute CRI reference (see ). The option is used analogously to the Proxy-Uri Option as defined in . The Proxy-Scheme-Number field is an option defined in . The option carries a CRI Scheme Number represented as a CoAP unsigned integer (see Sections and of ). The option is used analogously to the Proxy-Scheme Option as defined in . The SCHC Rule description MAY define sending some field values by not setting the TV, while setting the MO to "ignore" and the CDA to "value-sent". A Rule MAY also use a "match-mapping" MO when there are different alternatives for the same FID. Otherwise, the Rule sets the TV to a specific value, the MO to "equal", and the CDA to "not-sent".

CoAP Location-Path and Location-Query Fields A Rule entry cannot store these fields' values. Therefore, SCHC compression MUST always send these values in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent".

CoAP Option ETag and If-Match Fields When a CoAP message uses the ETag Option or the If-Match Option, SCHC compression MAY send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent". Alternatively, if a pre-defined set of values determined by the server is known and is used by the client as ETag values or If-Match values, then a Rule MAY use a "match-mapping" MO when there are different alternatives for the same FID.

CoAP Option If-None-Match The If-None-Match Option occurs at most once and is always empty. The SCHC Rule MUST describe an empty TV, with the MO set to "equal" and the CDA set to "not-sent".

CoAP Option Hop-Limit Field The Hop-Limit field is an option defined in that can be used to detect forwarding loops through a chain of CoAP proxies. The first proxy in the chain that understands the option includes it in a received request with a proper value set, before forwarding the request. Any following proxy that understands the option decrements the Option Value and forwards the request if the new value is different from zero, or returns a 5.08 (Hop Limit Reached) error response otherwise. When a CoAP message uses the Hop-Limit Option, SCHC compression SHOULD send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent". As an exception, and consistent with the default value 16 defined for the Hop-Limit Option in , a Rule MAY describe a TV with value 16, with the MO set to "equal" and the CDA set to "not-sent".

CoAP Option Echo Field The Echo field is an option defined in that a server can include in a CoAP response as a challenge to the client, and that the client echoes back to the server in one or more CoAP requests. This enables the server to verify the freshness of a request and to cryptographically verify the aliveness of the client. Also, it forces the client to demonstrate reachability at its claimed network address. When a CoAP message uses the Echo Option, SCHC compression SHOULD send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent". An exception applies in the case that the server generates the values to use for the Echo Option by means of a persistent counter (see ). In such a case, a Rule MAY use the MSB MO and the LSB CDA. This would be effectively applicable until the persistent counter at the server becomes greater than the maximum threshold value that produces an MSB-matching.

CoAP Option Request-Tag Field The Request-Tag field is an option defined in that the client can set in CoAP requests throughout block-wise operations, with value an ephemeral short-lived identifier of the specific block-wise operation in question. This allows the server to match message fragments belonging to the same request operation and, if the server supports it, to reliably process simultaneous block-wise request operations on a single resource. If requests are integrity protected, this also protects against interchange of fragments between different block-wise request operations. When a CoAP message uses the Request-Tag Option, SCHC compression MAY send its content in the Compression Residue. That is, in the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent". Alternatively, if a pre-defined set of Request-Tag values used by the client is known, a Rule MAY use a "match-mapping" MO when there are different alternatives for the same FID.

CoAP Option EDHOC Field The EDHOC field is an option defined in that a client can include in a CoAP request, in order to perform an optimized, shortened execution of the authenticated key exchange protocol EDHOC . Such a request conveys both the final EDHOC message and actual application data, where the latter is protected with OSCORE using a Security Context derived from the result of the current EDHOC execution. The EDHOC Option occurs at most once and is always empty. The SCHC Rule MUST describe an empty TV, with the MO set to "equal" and the CDA set to "not-sent".

Compression of CoAP Extensions The following sections present how SCHC compresses some specific CoAP options that, when used, play a major role in the processing and exchange of CoAP messages.

Block-Wise Transfers When a CoAP message uses a Block1 or Block2 Option or a Q-Block1 or Q-Block2 Option , SCHC compression MUST send its content in the Compression Residue. In the SCHC Rule, the TV is not set, while the MO is set to "ignore" and the CDA is set to "value-sent". The Block1, Block2, Q-Block1, and Q-Block2 Options allow fragmentation at the CoAP level that is compatible with SCHC fragmentation. Both fragmentation mechanisms are complementary, and the node may use them for the same packet as needed.

Observe defines the Observe Option. The SCHC Rule description does not set the TV, while setting the MO to "ignore" and the CDA to "value-sent". SCHC does not limit the maximum size for this option (3 bytes). To reduce the transmission size, either the Device implementation MAY limit the delta between two consecutive values or a proxy can modify the increment. Since the client MAY use a RST message to inform a server that the Observe response is not required, a specific SCHC Rule SHOULD exist to allow the compression of a RST message.

No-Response defines a No-Response Option limiting the CoAP responses made by a server to a CoAP request. Different behaviors exist while using this option to limit the responses made by a server to a request. If both ends know the specific value, then the SCHC Rule describes the TV set to that value, the MO set to "equal", and the CDA set to "not-sent". Otherwise, if the value changes over time, the SCHC Rule does not set the TV, while setting the MO to "ignore" and the CDA to "value-sent". The Rule may also use a "match-mapping" MO to compress the value.

OSCORE The security protocol OSCORE provides end-to-end protection for CoAP messages. Group OSCORE builds on OSCORE and provides end-to-end protection of CoAP messages in group communication . This section describes how SCHC Rules can be applied to compress messages protected with OSCORE or Group OSCORE. shows the OSCORE Option value encoding, as it was originally defined in . As explained below, this has been extended in . The first byte of the OSCORE Option value specifies information to parse the rest of the value by using flags. In particular:

• As defined in , the sixth least significant bit, when set, indicates that the message including the OSCORE Option is protected with the group mode of Group OSCORE (see ). When not set, the bit indicates that the message is protected either with OSCORE or with the pairwise mode of Group OSCORE (see ), while the specific OSCORE Security Context used to protect the message determines which of the two cases applies.
• As defined in , bit h, when set, indicates the presence of the kid context field in the OSCORE Option value. Also, bit k, when set, indicates the presence of the kid field. Finally, the three least significant bits form the n field, which indicates the length of the Partial IV (Partial Initialization Vector) field in bytes. When n = 0, no Partial IV is present.

The flag byte is followed by the Partial IV field. After that, if the h bit is set, the kid context field is present, preceded by one byte "s" indicating its length in bytes. After that, if the k bit is set, the kid field is present, and it ends where the OSCORE Option value ends. Within the flag byte, the eight and seventh least significant bits have been originally defined as reserved and are always set to 0. Future specifications might extend the OSCORE Option value encoding, e.g., by defining the use of the eight and seventh least significant bits in the flag byte. In turn, the use of such bits can result in expanding the space for the OSCORE flag bits by means of additional flag bytes that follow the first flag byte, or in introducing additional fields in the OSCORE Option value besides the original ones.

OSCORE Option Value. +-+-+-+-+-+-+-+-+-----------------------+ |0 0 0|h|k| n | Partial IV (if any) | +-+-+-+-+-+-+-+-+-----------------------+ | | | |<--- flags --->|<-------- piv -------->| <--- 1 byte --> <------- s bytes -----> +---------------+-----------------------+------------------+ | s (if any) | kid context (if any) | kid (if any) ... | +---------------+-----------------------+------------------+ | | | |<--------------- kid_ctx ------------->|<------ kid ----->| ]]>

To better perform OSCORE SCHC compression, the Rule description needs to identify the OSCORE Option value and its inner fields mentioned above. Conceptually, SCHC discerns four distinct pieces of information within the OSCORE Option value: the flag bits, the Partial IV, the kid context prepended by its size s, and the kid. The SCHC Rule splits the OSCORE Option value into four corresponding Field Descriptors, in order to separately compress those pieces of information as distinct subfields:

• flags
• piv
• kid_ctx
• kid

If a SCHC Rule is intended to compress a CoAP message that specifies the OSCORE Option, then the related Field Descriptors MUST be listed in the same order according to which the corresponding pieces of information appear in the OSCORE Option value. shows the original format of the OSCORE Option value with the four subfields flags, piv, kid_ctx, and kid superimposed on it. If future specifications extend the OSCORE Option value encoding, e.g., by defining the use of the eight and seventh least significant bits in the first byte of flags, this might result in additional subfields besides the four original ones, hence in corresponding Field Descriptors intended to be used in SCHC Rules. If a subfield is not present, then the corresponding Field Descriptor in the SCHC Rule describes the TV set to b'', with the MO set to "equal" and the CDA set to "not-sent". Note that, if the subfield kid_ctx is present, it directly includes the size octet, i.e., s. If the piv subfield is present, SCHC MUST NOT send it as variable-size data in the Compression Residue. As a result, SCHC does not send the size of the residue resulting from the compression of the piv subfield, which is otherwise requested for variable-size fields when the CDA specified in the Field Descriptor is "value-sent" or LSB (see ). Instead, SCHC MUST use the value n from the first byte of the OSCORE Option value to define the size of the piv subfield in the Compression Residue. To this end, SCHC designates a specific function, "osc.piv", that the Rule MUST use to complete the Field Descriptor. During the decompression, this function returns the value n, hence the length of the piv subfield in bytes. If the value n is not available (e.g., the present message includes the OSCORE Option with empty Option Value), then the "osc.piv" function returns the value 0. This construct avoids ambiguity with the value n from the first byte of the OSCORE Option value and results in a more efficient compression of the piv subfield.

Compression of the CoAP Payload Marker The following applies with respect to the 0xFF payload marker. A SCHC compression Rule for CoAP includes all the expected CoAP options, therefore the payload marker does not have to be specified in a SCHC Rule description. If the CoAP message to compress with SCHC is not going to be protected with OSCORE and includes a payload, then the 0xFF payload marker MUST NOT be included in the compressed message, which is composed of the Compression RuleID, the Compression Residue (if any), and the CoAP payload. After having decompressed an incoming message, the recipient endpoint MUST prepend the 0xFF payload marker to the CoAP payload, if any was present after the consumed Compression Residue. If the CoAP message to compress with SCHC is going to be protected with OSCORE, the 0xFF payload marker is compressed as specified later in .

Examples of CoAP Header Compression

Mandatory Header with CON Message In this first scenario, the SCHC compressor on the NGW side receives a POST message from an Internet client, which is immediately acknowledged by the Device. describes the SCHC Rule descriptions for this scenario. CoAP Context to compress header without Token. CoAP Option Numbers: 11 (Uri-Path).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not-sent
CoAP. Type	2	1	Dw	CON	equal	not-sent
CoAP. Type	2	1	Up	[ACK, RST]	match- mapping	mapping- sent	T
CoAP. TKL	var	1	Bi	0b0000	equal	not-sent
CoAP. Code	8	1	Bi	[0.00, ... 5.05]	match- mapping	mapping- sent	CC CCC
CoAP. MID	16	1	Bi	0x0000	MSB(7)	LSB	MID
CoAP. option(11)	var	1	Dw	"status"	equal	not-sent

In this example, SCHC compression elides the Version and Token Length fields. The 25 Method and Response Codes defined in have been shrunk to 5 bits using a "match-mapping" MO. The Uri-Path contains a single element with the TV set to "status" and the CDA set to "not-sent", thereby eliding the single occurrence of the Uri-Path Option with value "status". SCHC compression reduces the header, sending only a mapped Type (and only for uplink messages), a mapped code, and the least significant bits of the Message ID (9 bits in the example above). Note that, if a client is located in an Application Server and sends a request to a server located in the Device, then the request may not be compressed through this Rule, since the MID might not start with 7 bits equal to 0. A CoAP proxy placed before SCHC C/D can rewrite the Message ID to fit the value and match the Rule.

OSCORE Compression The OSCORE security protocol specified in provides end-to-end protection for CoAP messages. When doing so, it hides as much as possible of a CoAP message, while still enabling proxy operations. Conceptually, this is achieved by splitting the CoAP message into an Inner Plaintext and an Outer OSCORE message. The Inner Plaintext contains (sensitive) information that is not necessary for performing proxy operations. Therefore, that information can be encrypted end-to-end until it reaches the other origin endpoint as its final destination. The Outer Message acts as a shell matching the regular CoAP message format, and includes all the CoAP options and information needed for performing proxy operations and caching. This is summarized in . In particular, the CoAP options are arranged into three classes, each of which is granted a specific type of protection by the OSCORE protocol:

• Class E: Encrypted and integrity-protected options, which are moved to the Inner Plaintext.
• Class I: Integrity-protected options, which are included in the Additional Authenticated Data (AAD) when protecting the Plaintext, but are otherwise left untouched in the Outer Message.
• Class U: Unprotected options, which are left untouched in the Outer Message.

As per these classes, the Outer options comprise the OSCORE Option, which indicates that the message is protected with OSCORE and carries the information necessary for the recipient endpoint to retrieve the Security Context for decrypting the message.

CoAP Message Split into OSCORE Outer Header and Plaintext.

shows the packet format for the OSCORE Outer header and Plaintext. In the Outer header, the original header code is hidden and replaced by a well-known value. As specified in Sections and of , the original header code is replaced with POST for requests and Changed for responses, when the message does not include the Observe Option. Otherwise, the original header code is replaced with FETCH for requests and Content for responses. The first byte of the Plaintext contains the original header code, the Class E options, and, if present, the original message payload preceded by the payload marker. After that, an Authenticated Encryption with Associated Data (AEAD) algorithm encrypts the Plaintext. This also integrity-protects the Security Context parameters and, if present, any Class I options from the Outer header. The resulting ciphertext becomes the new payload of the OSCORE message, as illustrated in . As defined in , this ciphertext is the encrypted Plaintext's concatenation with the Authentication Tag. Note that Inner Compression only affects the Plaintext before encryption. The Authentication Tag, fixed in length and uncompressed, is considered part of the cost of protection. When the CoAP message is specifically protected with the group mode of Group OSCORE (see ), the ciphertext is followed by a signature, which is computed over the ciphertext and additional authenticated data. That is, in the message protected with Group OSCORE, the CoAP payload includes the ciphertext concatenated with the signature. This has no impact on the SCHC compression/decompression. That is, like in any other case, the CoAP payload of the protected message is sent as-is within the SCHC packet, following the Compression Residue (if any).

OSCORE Message.

The SCHC compression scheme consists of compressing both the Plaintext before encryption and the resulting OSCORE message after encryption, as shown in . Note that, since the recipient endpoint can only decrypt the Inner part of the message, that endpoint will also have to implement Inner SCHC Compression/Decompression.

OSCORE Compression Diagram.

The OSCORE message translates into a segmented process where SCHC compression is applied independently in two stages, each with its corresponding set of Rules, i.e., the Inner SCHC Rules and the Outer SCHC Rules. By doing so, compression is applied to all the fields of the original CoAP message. As to the compression of the 0xFF payload marker, the same rationale described in applies to both the Inner SCHC Compression and the Outer SCHC Compression. That is:

• After the Inner SCHC Compression of a CoAP message including a payload, the payload marker MUST NOT be included in the input to the AEAD Encryption, which is composed of the Inner Compression RuleID, the Inner Compression Residue (if any), and the CoAP payload.
• The Outer SCHC Compression takes as input the OSCORE-protected message, which always includes a payload (i.e., the OSCORE Ciphertext) preceded by the payload marker.
• After the Outer SCHC Compression, the payload marker MUST NOT be included in the final compressed message, which is composed of the Outer Compression RuleID, the Outer Compression Residue (if any), and the OSCORE Ciphertext.

After having completed the Outer SCHC Decompression of an incoming message, the recipient endpoint MUST prepend the 0xFF payload marker to the OSCORE Ciphertext. After having completed the Inner SCHC Decompression of an incoming message, the recipient endpoint MUST prepend the 0xFF payload marker to the CoAP payload, if any was present after the consumed Compression Residue.

Example OSCORE Compression This section provides an example with a GET request and a corresponding Content response, exchanged between a Device-based CoAP client and a cloud-based CoAP server. The example also describes a possible set of Rules for Inner SCHC Compression and Outer SCHC Compression. A dump of the results and a contrast between SCHC + OSCORE performance and SCHC + CoAP performance are also listed. This example shows an estimate of the cost of security with SCHC-OSCORE. Our first CoAP message is the GET request in .

CoAP GET Request.

Its corresponding response is the Content response in .

CoAP Content Response.

The SCHC Rules for the Inner Compression include all the fields that are present in a regular CoAP message. The methods described in apply to these fields. provides an example. Inner SCHC Rule. CoAP Option Numbers: 11 (Uri-Path).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Code	8	1	Up	1	equal	not-sent
CoAP. Code	8	1	Dw	[69, 132]	match- mapping	mapping- sent	C
CoAP. option(11)	var	1	Up	"temperature"	equal	not-sent

shows the 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.

Plaintext Compression and Encryption for GET Request.

In this case, the original message has no payload and its resulting Plaintext is compressed up to only 1 byte (the size of the RuleID). The AEAD algorithm preserves this length in its first output and yields a fixed-size tag. SCHC cannot compress the tag, and the OSCORE message must include it without compression. The use of integrity protection translates into an overhead on the total message length, thus limiting the amount of compression that can be achieved and contributing to the cost of applying security to the message exchange. shows 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 the hexadecimal code from the payload to differ from the original, even if SCHC cannot compress the tag. The overhead for the tag bytes limits SCHC's performance but adds security to the message exchange.

Plaintext Compression and Encryption for Content Response > 1 (shifted payload) | | 0b0000000 Padding | | | +------------------------------------------------+ | | AEAD Encryption | (piv = 0x04) | v +---------------------------------------------------------+ | | | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | | tag = 0xe9aef3f2461e0c29 (8 bytes) | | | | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | | | +---------------------------------------------------------+ ]]>

The Outer SCHC Rule shown in is used, also to process the OSCORE Option fields. and show a dump of the OSCORE messages generated from the example messages, also including the Inner Compressed ciphertext in the payload. These are the messages that have to be compressed via the Outer SCHC Compression scheme. shows a possible set of Outer Rule items to compress the Outer header. Outer SCHC Rule. CoAP Option Numbers: 9 (OSCORE).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not- sent
CoAP. Type	2	1	Up	0	equal	not- sent
CoAP. Type	2	1	Dw	2	equal	not- sent
CoAP. TKL	var	1	Bi	0b0001	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	0x0000	MSB(12)	LSB	MMMM
CoAP. Token	tkl	1	Bi	0x80	MSB(5)	LSB	TTT
CoAP. option(9). flags	8	1	Up	0x09	equal	not- sent
CoAP. option(9). flags	8	1	Dw	b''	equal	not- sent
CoAP. option(9). piv	osc.piv	1	Up	0x00	MSB(4)	LSB	PPPP
CoAP. option(9). piv	osc.piv	1	Dw	b''	equal	not- sent
CoAP. option(9). kid_ctx	var	1	Bi	b''	equal	not- sent
CoAP. option(9). kid	var_bit	1	Up	0x636c69 656e70	MSB(44)	LSB	KKKK
CoAP. option(9). kid	var	1	Dw	b''	equal	not- sent

Protected and Inner SCHC Compressed GET Request.

Protected and Inner SCHC Compressed Content Response.

For the flag bits, some SCHC compression methods are useful, depending on the application. The most straightforward alternative is to provide a fixed value for the flags, combining an "equal" MO and a "not-sent" CDA. This SCHC description saves most bits but could prevent flexibility. Otherwise, SCHC could use a "match-mapping" MO to choose from several configurations for the exchange. If not, the SCHC description may use an MSB MO to mask off the three hard-coded most significant bits. Note that fixing a flag bit will limit the possible OSCORE Options that can be used in the exchange, since the value of the flag bits plays a role in determining a specific OSCORE Option. The piv field lends itself to having some bits masked off with an MSB MO and an LSB CDA. This SCHC description could be useful in applications where the message transmission frequency is low, such as with LPWAN technologies. Note that compressing the piv field may reduce the maximum number of sequence numbers that can be used in an exchange. Once the sequence number exceeds the maximum value, the OSCORE keys need to be re-established. The size, s, that is included in the kid_ctx field MAY be masked off with an LSB CDA. The rest of the kid_ctx field could have additional bits masked off, or the whole field could be fixed in accordance with an "equal" MO and a "not-sent" CDA. The same holds for the kid field. The Outer Rule of is applied to the example GET request and Content response. and show the resulting messages.

SCHC-OSCORE Compressed GET Request. 3 bytes with padding) Payload 0xa2c54fe1b434297b62 (9 bytes) Compressed message length: 13 bytes ]]>

SCHC-OSCORE Compressed Content Response. 1 byte with padding) MID Token Payload 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) ]]>

In contrast, the following compares these results with what would be obtained by SCHC compressing the original CoAP messages without protecting them with OSCORE, according to the SCHC Rule in . SCHC-CoAP Rule (No OSCORE). CoAP Option Numbers: 11 (Uri-Path).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not-sent
CoAP. Type	2	1	Up	0	equal	not-sent
CoAP. Type	2	1	Dw	2	equal	not-sent
CoAP. TKL	var	1	Bi	0b0001	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	0x0000	MSB(12)	LSB	MMMM
CoAP. Token	tkl	1	Bi	0x80	MSB(5)	LSB	TTT
CoAP. option(11)	var	1	Up	"temperature"	equal	not-sent

The Rule in yields the SCHC compression results shown in for the request and in for the response.

CoAP GET Compressed without OSCORE.

CoAP Content Compressed without OSCORE.

As it can be seen, the difference between applying SCHC + OSCORE as compared to regular SCHC + CoAP is about 10 bytes.

CoAP Header Compression with Proxies This section defines how SCHC Compression/Decompression is performed when CoAP proxies are deployed. The following refers to the origin client and origin server as application endpoints. The origin client, the proxy, and the origin server host one or more SCHC Endpoints each. For each communication leg on which SCHC is used, SCHC operations are performed according to SCHC Instances that share a common SCHC Context, consistent with a SCHC Session between those SCHC Instances. An entity that performs SCHC operations on multiple communication legs, such as a proxy, hosts different SCHC Instances for different legs and terminates the corresponding SCHC Session at itself; that is, incoming SCHC-compressed data is not relayed as such across communication legs. Note that SCHC Compression/Decompression of CoAP headers is not necessarily used between each pair of hops in the communication chain. For example, if a proxy is deployed between an origin client and an origin server, SCHC might be used on the communication leg between the origin client and the proxy, but not on the communication leg between the proxy and the origin server.

Without End-to-End Security In the case that OSCORE is not used end-to-end between client and server, the SCHC processing occurs hop-by-hop, by relying on SCHC Rules that are consistently shared between two adjacent hops, i.e., by relying on a SCHC Context shared by the SCHC Instances hosted at the two adjacent hops and taking part in the same SCHC Session. In particular, SCHC is used as defined below.

• The sender application endpoint compresses the CoAP message, by using the SCHC Rules that it shares with the next hop towards the recipient application endpoint. The resulting, compressed message is sent to the next hop towards the recipient application endpoint.
• Each proxy decompresses the incoming compressed message, by using the SCHC Rules that it shares with the (previous hop towards the) sender application endpoint. Then, the proxy compresses the CoAP message to be forwarded, by using the SCHC Rules that it shares with the (next hop towards the) recipient application endpoint. The resulting, compressed message is sent to the (next hop towards the) recipient application endpoint.
• The recipient application endpoint decompresses the incoming compressed message, by using the SCHC Rules that it shares with the previous hop towards the sender application endpoint.

With End-to-End Security In the case that OSCORE is used end-to-end between client and server (see ), the following applies. The SCHC processing occurs end-to-end as to the Inner SCHC Compression/Decompression, by relying on Inner SCHC Rules that are consistently shared between the two application endpoints acting as OSCORE endpoints and sharing the OSCORE Security Context used. The Inner SCHC Rules belong to a SCHC Context shared end-to-end by the SCHC Instances hosted at the two application endpoints and taking part in the same SCHC Session. Instead, the SCHC processing occurs hop-by-hop as to the Outer SCHC Compression/Decompression, by relying on Outer SCHC Rules that are consistently shared between two adjacent hops, i.e., by relying on a per-leg SCHC Context shared by the SCHC Instances hosted at the two adjacent hops and taking part in a distinct SCHC Session. In particular, SCHC is used as defined below.

• The sender application endpoint performs the Inner SCHC Compression on the original CoAP message, by using the Inner SCHC Rules that it shares with the recipient application endpoint. Following the AEAD Encryption of the compressed input obtained from the previous step, the sender application endpoint performs the Outer SCHC Compression on the resulting OSCORE-protected message, by using the Outer SCHC Rules that it shares with the next hop towards the recipient application endpoint. The resulting, compressed message is sent to the next hop towards the recipient application endpoint.
• Each proxy performs the Outer SCHC Decompression on the incoming compressed message, by using the SCHC Rules that it shares with the (previous hop towards the) sender application endpoint. Then, the proxy performs the Outer SCHC Compression of the OSCORE-protected message to be forwarded, by using the SCHC Rules that it shares with the (next hop towards the) recipient application endpoint. The resulting, compressed message is sent to the (next hop towards the) recipient application endpoint.
• The recipient application endpoint performs the Outer SCHC Decompression on the incoming compressed message, by using the Outer SCHC Rules that it shares with the previous hop towards the sender application endpoint. Then, the recipient application endpoint performs the AEAD Decryption of the OSCORE-protected message obtained from the previous step. Finally, the recipient application endpoint performs the Inner SCHC Decompression on the compressed input obtained from the previous step, by using the Inner SCHC Rules that it shares with the sender application endpoint. The result is the original CoAP message produced by the sender application endpoint.

Examples of CoAP Header Compression with Proxies This section provides examples of SCHC Compression/Decompression in the presence of a CoAP proxy. The presented examples refer to the same deployment considered in , including a Device communicating over LPWAN with a Network Gateway (NGW), which in turn communicates with an Application Server over the Internet. The Application Server and the Device exchange CoAP messages through the NGW. The following also applies in the presented examples.

• CoAP request messages are sent only by the Device as targeting the Application Server (uplink traffic), which replies to the Device with corresponding CoAP response messages (downlink traffic). That is, the Device acts as CoAP client, while the Application Server acts as CoAP server.
• A CoAP proxy is co-located on the Network Gateway (NGW) deployed between the Application Server and the Device.
• SCHC is used also on the communication leg between the Application Server and the proxy.

Like in , the presented examples focus on SCHC Compression/Decompression of CoAP headers, i.e., irrespective of possible SCHC Compression/Decompression applied to further protocol headers. The example in considers an exchange of two unprotected messages, while the example in considers an exchange of two messages protected end-to-end with OSCORE. In the examples, the character | denotes bit concatenation. and show the two CoAP messages exchanged between the Device and the Application Server via the proxy. The figures show the two messages as originally generated by the application at the two origin endpoints, i.e., before they are possibly protected end-to-end with OSCORE as considered by the example in . Note that:

• On the communication leg between the Device and the proxy, the CoAP Message ID has value 0x0001 and the CoAP Token has value 0x82.
• On the communication leg between the proxy and the Application Server, the CoAP Message ID has value 0x0004 and the CoAP Token has value 0x75.

CoAP GET Request.

CoAP Content Response.

Without End-to-End Security In the case that OSCORE is not used end-to-end between the Device and the Application Server, the following SCHC Rules are shared between the different entities. Based on those Rules, the SCHC Compression/Decompression is performed as per . The Device and the proxy share the SCHC Rule shown in , with RuleID 0. SCHC Rule between the Device and the Proxy. CoAP Option Numbers: 3 (Uri-Host), 11 (Uri-Path), 39 (Proxy-Scheme).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not-sent
CoAP. Type	2	1	Up	0	equal	not-sent
CoAP. Type	2	1	Dw	[0, 2]	match- mapping	mapping- sent	T
CoAP. TKL	var	1	Bi	0b0001	equal	not-sent
CoAP. Code	8	1	Up	[1, 2, 3, 4]	match- mapping	mapping- sent	CC
CoAP. Code	8	1	Dw	[65, 68, 69, 132]	match- mapping	mapping- sent	CC
CoAP. MID	16	1	Bi	0x0000	MSB(12)	LSB	MMMM
CoAP. Token	tkl	1	Bi	0x80	MSB(5)	LSB	TTT
CoAP. option(3)	var	1	Up		ignore	value- sent
CoAP. option(11)	var	1	Up	"temperature"	equal	not-sent
CoAP. option(39)	var	1	Up	"coap"	equal	not-sent

Instead, the proxy and the Application Server share the SCHC Rule shown in , with RuleID 1. SCHC Rule between the Proxy and the Application Server. CoAP Option Numbers: 3 (Uri-Host), 11 (Uri-Path).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not-sent
CoAP. Type	2	1	Up	0	equal	not-sent
CoAP. Type	2	1	Dw	[0, 2]	match- mapping	mapping- sent	T
CoAP. TKL	var	1	Bi	0b0001	equal	not-sent
CoAP. Code	8	1	Up	[1, 2, 3, 4]	match- mapping	mapping- sent	CC
CoAP. Code	8	1	Dw	[65, 68, 69, 132]	match- mapping	mapping- sent	CC
CoAP. MID	16	1	Bi	0x0000	MSB(12)	LSB	MMMM
CoAP. Token	tkl	1	Bi	0x70	MSB(5)	LSB	TTT
CoAP. option(3)	var	1	Up		ignore	value- sent
CoAP. option(11)	var	1	Up	"temperature"	equal	not-sent

First, the Device applies the Rule in shared with the proxy to the CoAP request in . The result is the compressed CoAP request in that the Device sends to the proxy.

CoAP GET Request Compressed for the Proxy. 13 bytes with padding) 0b 00 0001 010 1011 | 0x6578616d706c652e636f6d Code MID Token Uri-Host (residue size and residue) Compressed message length: 14 bytes ]]>

Upon receiving the message in , the proxy decompresses it with the Rule in shared with the Device and obtains the same CoAP request in . After that, the proxy removes the Proxy-Scheme Option from the decompressed CoAP request. Also, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0004 and 0x75, respectively. The result is the CoAP request shown in .

CoAP GET Request to be Compressed by the Proxy.

Then, the proxy applies the Rule in shared with the Application Server to the CoAP request in . The result is the compressed CoAP request in that the proxy forwards to the Application Server.

CoAP GET Request Forwarded by the Proxy. 13 bytes with padding) 0b 00 0100 101 1011 | 0x6578616d706c652e636f6d Code MID Token Uri-Host (residue size and residue) Compressed message length: 14 bytes ]]>

Upon receiving the message in , the Application Server decompresses it using the Rule in shared with the proxy. The result is the same CoAP request in that the Application Server delivers to the application. After that, the Application Server produces the CoAP response in and compresses it using the Rule in shared with the proxy. The result is the compressed CoAP response shown in that the Application Server sends to the proxy.

CoAP Content Response Compressed for the Proxy. 2 bytes with padding) 0b 1 10 0100 101 Type Code MID Token Payload 0x32332043 (4 bytes) Compressed message length: 7 bytes ]]>

Upon receiving the message in , the proxy decompresses it using the Rule in shared with the Application Server. The result is the same CoAP response in . Then, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0001 and 0x82, respectively. The result is the CoAP response shown in .

CoAP Content Response to be Compressed by the Proxy.

Then, the proxy compresses the CoAP response in with the Rule in shared with the Device. The result is the compressed CoAP response shown in that the proxy forwards to the Device.

CoAP Content Response Forwarded by the Proxy. 2 bytes with padding) 0b 1 10 0001 010 Type Code MID Token Payload 0x32332043 (4 bytes) Compressed message length: 7 bytes ]]>

Upon receiving the message in , the Device decompresses it using the Rule in shared with the proxy. The result is the same CoAP request in that the Device delivers to the application.

With End-to-End Security In the case that OSCORE is used end-to-end between the Device and the Application Server, the following SCHC Rules are shared between the different entities. Based on those Rules, the SCHC Compression/Decompression is performed as per . The Device and the Application Server share the SCHC Rule shown in , with RuleID 2. The Device and the Application Server use this Rule to perform the Inner SCHC Compression/Decompression end-to-end. Inner SCHC Rule between the Device and the Application Server. CoAP Option Numbers: 11 (Uri-Path).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Code	8	1	Up	[1, 2, 3, 4]	match- mapping	mapping- sent	CC
CoAP. Code	8	1	Dw	[65, 68, 69, 132]	match- mapping	mapping- sent	CC
CoAP. option(11)	var	1	Up	"temperature"	equal	not-sent

The Device and the proxy share the SCHC Rule shown in , with RuleID 3. The Device and the proxy use this Rule to perform the Outer SCHC Compression/Decompression hop-by-hop on their communication leg. Outer SCHC Rule between the Device and the Proxy. CoAP Option Numbers: 3 (Uri-Host), 9 (OSCORE), 39 (Proxy-Scheme).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not-sent
CoAP. Type	2	1	Up	0	equal	not-sent
CoAP. Type	2	1	Dw	[0, 2]	match- mapping	mapping- sent	T
CoAP. TKL	var	1	Bi	0b0001	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	0x0000	MSB(12)	LSB	MMMM
CoAP. Token	tkl	1	Bi	0x80	MSB(5)	LSB	TTT
CoAP. option(3)	var	1	Up		ignore	value- sent
CoAP. option(9). flags	8	1	Up	0x09	equal	not-sent
CoAP. option(9). flags	8	1	Dw	b''	equal	not-sent
CoAP. option(9). piv	osc.piv	1	Up	0x00	MSB(4)	LSB	PPPP
CoAP. option(9). piv	osc.piv	1	Dw	b''	equal	not-sent
CoAP. option(9). kid_ctx	var	1	Bi	b''	equal	not-sent
CoAP. option(9). kid	var_bit	1	Up	0x0000	MSB(12)	LSB	KKKK
CoAP. option(9). kid	var	1	Dw	b''	equal	not-sent
CoAP. option(39)	var	1	Up	"coap"	equal	not-sent

The proxy and the Application Server share the SCHC Rule shown in , with RuleID 4. The proxy and the Application Server use this Rule to perform the Outer SCHC Compression/Decompression hop-by-hop on their communication leg. Outer SCHC Rule between the Proxy and the Application Server. CoAP Option Numbers: 3 (Uri-Host), 9 (OSCORE).

FID	FL	FP	DI	TV	MO	CDA	Sent [bits]
CoAP. Version	2	1	Bi	1	equal	not-sent
CoAP. Type	2	1	Up	0	equal	not-sent
CoAP. Type	2	1	Dw	[0, 2]	match- mapping	mapping- sent	T
CoAP. TKL	var	1	Bi	0b0001	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	0x0000	MSB(12)	LSB	MMMM
CoAP. Token	tkl	1	Bi	0x70	MSB(5)	LSB	TTT
CoAP. option(3)	var	1	Up		ignore	value- sent
CoAP. option(9). flags	8	1	Up	0x09	equal	not-sent
CoAP. option(9). flags	8	1	Dw	b''	equal	not-sent
CoAP. option(9). piv	osc.piv	1	Up	0x00	MSB(4)	LSB	PPPP
CoAP. option(9). piv	osc.piv	1	Dw	b''	equal	not-sent
CoAP. option(9). kid_ctx	var	1	Bi	b''	equal	not-sent
CoAP. option(9). kid	var_bit	1	Up	0x0000	MSB(12)	LSB	KKKK
CoAP. option(9). kid	var	1	Dw	b''	equal	not-sent

When the Device applies the Rule in shared with the Application Server to the CoAP request in , this results in the Compressed Plaintext shown in . As per , the message follows the process of SCHC Inner Compression and encryption until the payload (if any). The ciphertext resulting from the overall Inner process is used as payload of the Outer OSCORE message.

Plaintext Compression and Encryption for the GET Request.

When the Application Server applies the Rule in shared with the Device to the CoAP response in , this results in the Compressed Plaintext shown in . As per , the message follows the process of SCHC Inner Compression and encryption until the payload (if any). The ciphertext resulting from the overall Inner process is used as payload of the Outer OSCORE message.

Plaintext Compression and Encryption for the Content Response. > 2 (shifted payload) | | 0b000000 Padding | | | +-------------------------------------------------+ | | AEAD Encryption | (piv = 0x04) | v +---------------------------------------------------------+ | | | encrypted_plaintext = 0x10c6d7c26cc1 (6 bytes) | | tag = 0xe9aef3f2461e0c29 (8 bytes) | | | | ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) | | | +---------------------------------------------------------+ ]]>

After having performed the SCHC Inner Compression of the CoAP request in , the Device protects it with OSCORE by considering the Compressed Plaintext in . The result is the OSCORE-protected CoAP request shown in .

Protected and Inner SCHC Compressed CoAP GET Request.

Then, the Device applies the Rule in shared with the proxy to the OSCORE-protected CoAP request in , thus performing the SCHC Outer Compression of such request. The result is the OSCORE-protected and Outer Compressed CoAP request shown in that the Device sends to the proxy.

SCHC-OSCORE CoAP GET Request Compressed for the Proxy. 14 bytes with padding) Payload 0xa2cfc54fe1b434297b62 (10 bytes) Compressed message length: 25 bytes ]]>

Upon receiving the message in , the proxy decompresses it with the Rule in shared with the Device, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP request in . After that, the proxy removes the Proxy-Scheme Option from the decompressed OSCORE-protected CoAP request. Also, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0004 and 0x75, respectively. The result is the OSCORE-protected CoAP request shown in .

SCHC-OSCORE CoAP GET Request to be Compressed by the Proxy.

Then, the proxy applies the Rule in shared with the Application Server to the OSCORE-protected CoAP request in , thus performing the SCHC Outer Compression of such request. The result is the OSCORE-protected and Outer Compressed CoAP request shown in that the proxy forwards to the Application Server.

SCHC-OSCORE CoAP GET Request Forwarded by the Proxy. 14 bytes with padding) Payload 0xa2cfc54fe1b434297b62 (10 bytes) Compressed message length: 25 bytes ]]>

Upon receiving the message in , the Application Server decompresses it using the Rule in shared with the proxy, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP request in . The Application Server decrypts and verifies such a request, which results in the same Compressed Plaintext in . Then, the Application Server applies the Rule in shared with the Device to such a Compressed Plaintext, thus performing the SCHC Inner Decompression. The result is used to rebuild the same CoAP request in that the Application Server delivers to the application. After having performed the SCHC Inner Compression of the CoAP response in , the Application Server protects it with OSCORE by considering the Compressed Plaintext in . The result is the OSCORE-protected CoAP response shown in .

Protected and Inner SCHC Compressed CoAP Content Response.

Then, the Application Server applies the Rule in shared with the proxy to the OSCORE-protected CoAP response in , thus performing the SCHC Outer Compression of such response. The result is the OSCORE-protected and Outer Compressed CoAP response shown in that the Application Server sends to the proxy.

SCHC-OSCORE CoAP Content Response Compressed for the Proxy. 1 byte with padding) 0b 1 0100 101 Type MID Token Payload 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) Compressed message length: 16 bytes ]]>

Upon receiving the message in , the proxy decompresses it with the Rule in shared with the Application Server, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP response in . After that, the proxy replaces the values of the CoAP Message ID and of the CoAP Token to 0x0001 and 0x82, respectively. The result is the OSCORE-protected CoAP response shown in .

SCHC-OSCORE CoAP Content Response to be Compressed by the Proxy.

Then, the proxy applies the Rule in shared with the Device to the OSCORE-protected CoAP response in , thus performing the SCHC Outer Compression of such response. The result is the OSCORE-protected and Outer Compressed CoAP response shown in that the proxy forwards to the Device.

SCHC-OSCORE CoAP Content Response Forwarded by the Proxy. 1 byte with padding) 0b 1 0001 010 Type MID Token Payload 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) Compressed message length: 16 bytes ]]>

Upon receiving the message in , the Device decompresses it using the Rule in shared with the proxy, thus performing the SCHC Outer Decompression. The result is the same OSCORE-protected CoAP response in . The Device decrypts and verifies such a response, which results in the same Compressed Plaintext shown in . Then, the Device applies the Rule in shared with the Application Server to such a Compressed Plaintext, thus performing the SCHC Inner Decompression. The result is used to rebuild the same CoAP response in that the Device delivers to the application.

CoAP Fields lists the CoAP fields and subfields for which SCHC compression has been defined or revised in this document. CoAP Fields.

Field	Description
CoAP.Version	CoAP header field Version
CoAP.Type	CoAP header field Type
CoAP.TKL	CoAP header field Token Length (TKL)
CoAP.Code	CoAP header field Code
CoAP.Code.Class	CoAP header field Code (subfield Class)
CoAP.Code.Detail	CoAP header field Code (subfield Detail)
CoAP.MID	CoAP header field Message ID
CoAP.Token	CoAP field Token
CoAP.option(1)	CoAP option If-Match
CoAP.option(3)	CoAP option Uri-Host
CoAP.option(4)	CoAP option ETag
CoAP.option(5)	CoAP option If-None-Match
CoAP.option(6)	CoAP option Observe
CoAP.option(7)	CoAP option Uri-Port
CoAP.option(8)	CoAP option Location-Path
CoAP.option(9)	CoAP option OSCORE
CoAP.option(9).flags	CoAP option OSCORE (subfield flags)
CoAP.option(9).piv	CoAP option OSCORE (subfield piv)
CoAP.option(9).kid_ctx	CoAP option OSCORE (subfield kid_ctx)
CoAP.option(9).kid	CoAP option OSCORE (subfield kid)
CoAP.option(11)	CoAP option Uri-Path
CoAP.option(12)	CoAP option Content-Format
CoAP.option(14)	CoAP option Max-Age
CoAP.option(15)	CoAP option Uri-Query
CoAP.option(16)	CoAP option Hop-Limit
CoAP.option(17)	CoAP option Accept
CoAP.option(19)	CoAP option Q-Block1
CoAP.option(20)	CoAP option Location-Query
CoAP.option(21)	CoAP option EDHOC
CoAP.option(23)	CoAP option Block2
CoAP.option(27)	CoAP option Block1
CoAP.option(28)	CoAP option Size2
CoAP.option(31)	CoAP option Q-Block2
CoAP.option(35)	CoAP option Proxy-Uri
CoAP.option(39)	CoAP option Proxy-Scheme
CoAP.option(60)	CoAP option Size1
CoAP.option(235)	CoAP option Proxy-Cri
CoAP.option(239)	CoAP option Proxy-Scheme-Number
CoAP.option(252)	CoAP option Echo
CoAP.option(258)	CoAP option No-Response
CoAP.option(292)	CoAP option Request-Tag

Security Considerations 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 the communication. When the connection does not use a security protocol (e.g., OSCORE or DTLS), it is necessary to use a Layer 2 security mechanism to protect the SCHC packets. If an LPWAN is the Layer 2 technology being used, the SCHC security considerations discussed in continue to apply. When using another Layer 2 protocol, the use of a cryptographic integrity-protection mechanism to protect the SCHC headers is REQUIRED. Such cryptographic integrity protection is necessary in order to continue to provide the properties that relies upon. When SCHC is used with OSCORE, the security considerations discussed in continue to apply. When SCHC is used with Group OSCORE, the security considerations discussed in continue to apply. When SCHC is used in the presence of CoAP proxies, the security considerations discussed in continue to apply. When SCHC is used with the OSCORE Outer headers, the Initialization Vector (IV) size in the Compression Residue must be carefully selected. 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 material (in order to prevent the IV from expanding to an incompressible value). The key-renewal operation itself may require several message exchanges and result in energy-intensive computation, but the optimal trade-off will depend on the specifics of the Device and expected usage patterns. In order to renew its key material with another OSCORE endpoint, the Device can rely on the lightweight key update protocol KUDOS defined in . If an attacker can introduce a corrupted SCHC-compressed packet onto a link, DoS attacks can be mounted by causing excessive resource consumption at the decompressor. However, an attacker able to inject packets at the link layer is also capable of other, potentially more damaging, attacks. SCHC compression emits variable-length Compression Residues for some CoAP fields. In the representation of the compressed header, the length field that is sent is not the length of the original header field but rather the length of the Compression Residue that is being transmitted. If a corrupted packet arrives at the decompressor with a longer or shorter length than that of the original compressed representation, the SCHC decompression procedures will detect an error and drop the packet. SCHC header compression Rules MUST remain tightly coupled between the compressor and the decompressor. If the compression Rules get out of sync, a Compression Residue might be decompressed differently at the receiver, thus yielding a result different than the initial message submitted to compression procedures. Accordingly, any time the Rules within the SCHC Context are updated on an OSCORE endpoint, that endpoint MUST trigger an update of the OSCORE key material, e.g., by running the lightweight key update protocol KUDOS . Similar procedures may be appropriate to signal Rule updates when other message-protection mechanisms are in use.

IANA Considerations This document has the following actions for IANA.

Static Context Header Compression (SCHC) Parameters IANA is asked to establish the "Static Context Header Compression (SCHC) Parameters" registry group. The registry group has been initially populated with the registry established as per .

SCHC Compression of CoAP Fields IANA is asked to establish the "SCHC Compression of CoAP Fields" registry within the "Static Context Header Compression (SCHC) Parameters" registry group established as per . As registration policy, the registry uses "Specification Required" per . Expert Review guidelines are provided in .

Intended Use The objective of this registry is to collect a list of CoAP fields and subfields, for which it has been defined how to perform SCHC compression. Such a definition does not necessarily have to be in the same documentation that defines the CoAP fields and subfields in question. While that can be the case, it is also possible to provide that definition in a separate specification. Each entry of the registry is intended to include references to the documentation that defines the associated CoAP field or subfield, as well as references to the specifications that define the SCHC compression of that CoAP field or subfield. When a specification defines how to perform SCHC compression of a CoAP field, the following applies.

• If a registry entry for the CoAP field does not already exist, it is strongly encouraged to register an associated new entry.
• If a registry entry for the CoAP field already exists, it is strongly encouraged to update its list of references. The update is intended to add references to the specification that provides the new or updated SCHC compression of the CoAP field, as well as to any documentation that updates the definition of the CoAP field itself.

If the defined SCHC compression considers the CoAP field as composed of subfields, it is strongly encouraged that the same as above is also performed for each subfield and the associated registry entry.

Structure of Entries The columns of this registry are:

• Field: a unique identifier of the CoAP field or subfield associated with this entry. This identifier is used as FID in a Field Descriptor of a SCHC compression Rule for compressing/decompressing CoAP messages. This identifier has two possible formats:
  • "CoAP.X", where X is the name of the CoAP field.
  • "CoAP.X.Y", where X is the name of the CoAP field and Y is the name of a subfield of X.
  If the CoAP field in question is specifically a CoAP option, then X has the format "option(N)", where N is the option number of the CoAP option. The value N is taken from the "Number" column of the corresponding entry in the "CoAP Option Numbers" IANA registry .
• Description: a short description of the CoAP field or subfield associated with this entry, together with public references to the resources that define it.
• Reference: public references to the resources that define how a SCHC compression Rule works for the CoAP field or subfield associated with this entry.

In order to make the registry easier to parse, its entries are ordered based on the value of the "Field" column and according to the following criteria:

• Given any two entries for CoAP fields, those entries are in the same relative order as those two fields in a CoAP message. Consequently, given any two entries related to CoAP options, those entries are in the same relative order as the option numbers of the two CoAP options.
• Given any two entries for subfields of the same field, those entries are in the same relative order as those two subfields in a CoAP message.
• Given an entry "CoAP.X" for the field X, any entry "CoAP.X.Y" for the subfield Y of X appears after the entry "CoAP.X" and before the entry for any other field.

This registry has been initially populated with the values in . The "Reference" column for all these entries refers to this document.

Expert Review Instructions The IANA registry established in this document is defined as "Specification Required". This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points:

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. Specifically, for every CoAP field, only one corresponding registry entry is allowed. Also, for every CoAP subfield, only one corresponding registry entry is allowed.
• For a new registry entry, it has to be clear where that entry has to be positioned within the registry, according to the criteria compiled in .
• Consistent with the "Specification Required" registration policy, specifications should exist, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.

If the expert becomes aware of a definition for SCHC compression of CoAP fields and subfields that is deployed and in use, the expert may also initiate a registration or update an existing one on their own, if they deem important that the definition in question gains visibility through the registry entry.

References Normative References This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252. This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. Orange Consultant RISE AB IMT Atlantique The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol. RISE AB RISE AB Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. IMT Atlantique Consultant Orange Orange The Static Context Header Compression and fragmentation (SCHC) framework provides both a header compression mechanism and an optional fragmentation mechanism. This document defines a minimal architecture for SCHC deployments, providing guidance for implementers and operators on the essential components and their interactions required for effective SCHC operation. The architecture defines the components of a SCHC deployment - Endpoints, Instances, Contexts, Sessions, and Domains - their management, the framing of SCHC Datagrams, and considerations for technology-specific profiles.

Document Updates

Version -09 to -10

• Terminology aligned with that in draft-ietf-schc-architecture.
• FL defined as non-empty.
• Fixed example rules to have FL not empty.
• Clarified semantics of the osc.piv function.
• Removed the YANG module ietf-schc-coap and text related to it.
• Removed text related to the YANG module ietf-schc defined in RFC 9363.
• Removed unnecessary references as not needed anymore: RFC 9363, RFC 3688, RFC 6020, RFC8407.

Version -08 to -09

• Clarified overview of changes from RFC 8824 in Section 1, as to the CoAP options ETag, If-Match, and If-None-Match.
• Clarified use of functions "var" and "var_X" in the FL of the Field Descriptor.
• Fixed occurrence of SCHC subfield name from kid_context to kid_ctx.
• A Field Descriptor can pertain to multiple adjacent occurrences of the same CoAP option grouped together.
• Handling a variable number of path segments and query parameters requires different SCHC Rules.
• Final text about updated reference in the YANG data model from RFC 9363.
• YANG data model:
  • Updated legal boilerplate and other metadata.
  • Consistent use of placeholders for RFC numbers.
  • Added the identity fl-variable-bit.
• Editorial fixes and improvements.

Version -07 to -08

• Updated editor's notes about the YANG data model from RFC 9363.
• Shortened one too-long line in the YANG data model.
• Editorial update of reference entries.

Version -06 to -07

• Removed content about the updates to the OSCORE Option expected from draft-ietf-core-oscore-key-update.
• Requested creation of new IANA registry group.
• Explicit criteria for ordering entries in the new IANA registry.
• Editorial fixes in the initial list of CoAP fields to register.

Version -05 to -06

• Generalized the Token Length field, the Token field, and the "tkl" function to comply with RFC 8974.
• Clarified use of the FL for variable-length fields.
• Explicit definition and use of "var" in the FL of a Field Descriptor.
• Consistent use of "var" in the examples of Rules.
• More robust reference to the YANG data model of RFC 9363.
• Editorial fixes in the examples.
• Minor clarifications and editorial improvements.

Version -04 to -05

• Compression of CoAP options:
  • Clarified definition of Field Descriptors in SCHC Rules.
  • Description of Option Value as possibly composed of sub-fields.
  • Both the syntactic approach and the semantics approach are possible (see draft-ietf-schc-universal-option).
  • Updated the FIDs to be consistent with the semantic approach.
• Compression of OSCORE Option:
  • Revised semantics of the x sub-field related to KUDOS.
  • Removed moot sub-fields related to KUDOS.
• Clarified OSCORE compression when using the group mode of Group OSCORE.
• Updated YANG data model.
• Updated author's contact information.
• Fixes and editorial improvements.

Version -03 to -04

• Clarified the rationale for using the "tkl" function.
• Added the "osc.piv" function to determine the length of the OSCORE piv field.
• Consistent formulation of "tkl", "osc.x.m", and "osc.y.w".
• Explicitly stated that Field Descriptors have to be ordered in a determistic way.
• Fixed format of TV in Rule Descriptors for CoAP MID.
• Fixed order of OSCORE-related Field Descriptors in example Rules.
• Use "bit" instead of "b" as symbol for bit (per ISO/IEC 80000-13).
• Made YANG extractable.
• Updated references.
• Fixes and editorial improvements.

Version -02 to -03

• Consistent representation of "CoAP Version" 1 in example Rules.
• Split the compression of Token Length and Token into two sections.
• Disambiguated example of Rule on eliding a Uri-Path option.
• Fixed compression examples with OSCORE.
• Inherited security considerations on the YANG module from RFC 9363.
• Fixes and editorial improvements.

Version -01 to -02

• Added compression for the CoAP options Proxy-Cri and Proxy-Scheme-Number.
• Defined new IANA registry "SCHC Compression of CoAP Fields".
• Updated the YANG data model.
• Fixes and editorial improvements.

Version -00 to -01

• Fixed an example, as per the erratum with Errata ID 7623.
• Clarified building of Field Descriptor for CoAP options.
• Clarified what SCHC compression considers for CoAP options.
• Revised SCHC compression of the ETag and If-Match CoAP option.
• Revised SCHC compression of the If-None-Match CoAP option.
• Added YANG data model for the YANG module.
• Added IANA considerations.
• Fixes and editorial improvements.

Acknowledgments The authors sincerely thank , , , , , , , , , and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020 projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant agreement 101020259).