draft-ietf-schc-8824-update-09.txt		draft-ietf-schc-8824-update-10.txt
	SCHC Working Group M. Tiloca		SCHC Working Group M. Tiloca
	Internet-Draft RISE AB		Internet-Draft RISE AB
	Obsoletes: 8824 (if approved) L. Toutain		Obsoletes: 8824 (if approved) L. Toutain
	Intended status: Standards Track IMT Atlantique		Intended status: Standards Track IMT Atlantique
	Expires: 7 January 2027 I. Martínez		Expires: 27 January 2027 I. Martínez
	IRISA		IRISA
	A. Minaburo		A. Minaburo
	Consultant		Consultant
	6 July 2026		26 July 2026
	Static Context Header Compression (SCHC) for the Constrained Application		Static Context Header Compression (SCHC) for the Constrained Application
	Protocol (CoAP)		Protocol (CoAP)
	draft-ietf-schc-8824-update-09		draft-ietf-schc-8824-update-10
	Abstract		Abstract
	This document defines how to compress Constrained Application		This document defines how to compress Constrained Application
	Protocol (CoAP) headers using the Static Context Header Compression		Protocol (CoAP) headers using the Static Context Header Compression
	and fragmentation (SCHC) framework. SCHC defines a header		and fragmentation (SCHC) framework. SCHC defines a header
	compression mechanism adapted for constrained devices, and it uses a		compression mechanism adapted for constrained devices, and it uses a
	static description of the header to reduce the header's redundancy		static description of the header to reduce the header's redundancy
	and size. While RFC 8724 describes the SCHC compression and		and size. While RFC 8724 describes the SCHC compression and
	fragmentation framework and its application for IPv6 and UDP headers,		fragmentation framework and its application for IPv6 and UDP headers,
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 7 January 2027.		This Internet-Draft will expire on 27 January 2027.
	Copyright Notice		Copyright Notice
	Copyright (c) 2026 IETF Trust and the persons identified as the		Copyright (c) 2026 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
	2. SCHC Applicability to CoAP . . . . . . . . . . . . . . . . . 7		2. SCHC Applicability to CoAP . . . . . . . . . . . . . . . . . 8
	3. CoAP Headers Compressed with SCHC . . . . . . . . . . . . . . 9		3. CoAP Headers Compressed with SCHC . . . . . . . . . . . . . . 11
	3.1. Differences between CoAP and UDP/IP Compression . . . . . 10		3.1. Differences between CoAP and UDP/IP Compression . . . . . 12
	4. Compression of CoAP Header Fields . . . . . . . . . . . . . . 12		4. Compression of CoAP Header Fields . . . . . . . . . . . . . . 14
	4.1. CoAP Version Field . . . . . . . . . . . . . . . . . . . 13		4.1. CoAP Version Field . . . . . . . . . . . . . . . . . . . 15
	4.2. CoAP Type Field . . . . . . . . . . . . . . . . . . . . . 13		4.2. CoAP Type Field . . . . . . . . . . . . . . . . . . . . . 15
	4.3. CoAP Token Length (TKL) Field . . . . . . . . . . . . . . 13		4.3. CoAP Token Length (TKL) Field . . . . . . . . . . . . . . 15
	4.4. CoAP Code Field . . . . . . . . . . . . . . . . . . . . . 14		4.4. CoAP Code Field . . . . . . . . . . . . . . . . . . . . . 16
	4.5. CoAP Message ID Field . . . . . . . . . . . . . . . . . . 14		4.5. CoAP Message ID Field . . . . . . . . . . . . . . . . . . 16
	4.6. CoAP Token Field . . . . . . . . . . . . . . . . . . . . 14		4.6. CoAP Token Field . . . . . . . . . . . . . . . . . . . . 16
	5. Compression of CoAP Options . . . . . . . . . . . . . . . . . 15		5. Compression of CoAP Options . . . . . . . . . . . . . . . . . 17
	5.1. Field Descriptors for CoAP Options . . . . . . . . . . . 15		5.1. Field Descriptors for CoAP Options . . . . . . . . . . . 17
	5.1.1. Option Value . . . . . . . . . . . . . . . . . . . . 16		5.1.1. Option Value . . . . . . . . . . . . . . . . . . . . 18
	5.2. CoAP Option Content-Format and Accept Fields . . . . . . 19		5.2. CoAP Option Content-Format and Accept Fields . . . . . . 20
	5.3. CoAP Option Max-Age, Uri-Host, and Uri-Port Fields . . . 19		5.3. CoAP Option Max-Age, Uri-Host, and Uri-Port Fields . . . 21
	5.4. CoAP Option Uri-Path and Uri-Query Fields . . . . . . . . 19		5.4. CoAP Option Uri-Path and Uri-Query Fields . . . . . . . . 21
	5.5. CoAP Option Size1, Size2, Proxy-Uri, and Proxy-Scheme		5.5. CoAP Option Size1, Size2, Proxy-Uri, and Proxy-Scheme
	Fields . . . . . . . . . . . . . . . . . . . . . . . . . 21		Fields . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.6. CoAP Option Proxy-Cri and Proxy-Scheme-Number Fields . . 21		5.6. CoAP Option Proxy-Cri and Proxy-Scheme-Number Fields . . 23
	5.7. CoAP Location-Path and Location-Query Fields . . . . . . 22		5.7. CoAP Location-Path and Location-Query Fields . . . . . . 23
	5.8. CoAP Option ETag and If-Match Fields . . . . . . . . . . 22		5.8. CoAP Option ETag and If-Match Fields . . . . . . . . . . 23
	5.9. CoAP Option If-None-Match . . . . . . . . . . . . . . . . 22		5.9. CoAP Option If-None-Match . . . . . . . . . . . . . . . . 24
	5.10. CoAP Option Hop-Limit Field . . . . . . . . . . . . . . . 22		5.10. CoAP Option Hop-Limit Field . . . . . . . . . . . . . . . 24
	5.11. CoAP Option Echo Field . . . . . . . . . . . . . . . . . 23		5.11. CoAP Option Echo Field . . . . . . . . . . . . . . . . . 24
	5.12. CoAP Option Request-Tag Field . . . . . . . . . . . . . . 23		5.12. CoAP Option Request-Tag Field . . . . . . . . . . . . . . 25
	5.13. CoAP Option EDHOC Field . . . . . . . . . . . . . . . . . 24		5.13. CoAP Option EDHOC Field . . . . . . . . . . . . . . . . . 25
	6. Compression of CoAP Extensions . . . . . . . . . . . . . . . 24		6. Compression of CoAP Extensions . . . . . . . . . . . . . . . 25
	6.1. Block-Wise Transfers . . . . . . . . . . . . . . . . . . 24		6.1. Block-Wise Transfers . . . . . . . . . . . . . . . . . . 25
	6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 24		6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 26
	6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 25		6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 26
	6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 25		6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7. Compression of the CoAP Payload Marker . . . . . . . . . . . 27		7. Compression of the CoAP Payload Marker . . . . . . . . . . . 29
	8. Examples of CoAP Header Compression . . . . . . . . . . . . . 28		8. Examples of CoAP Header Compression . . . . . . . . . . . . . 29
	8.1. Mandatory Header with CON Message . . . . . . . . . . . . 28		8.1. Mandatory Header with CON Message . . . . . . . . . . . . 29
	8.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 30		8.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 31
	8.3. Example OSCORE Compression . . . . . . . . . . . . . . . 34		8.3. Example OSCORE Compression . . . . . . . . . . . . . . . 35
	9. CoAP Header Compression with Proxies . . . . . . . . . . . . 46		9. CoAP Header Compression with Proxies . . . . . . . . . . . . 47
	9.1. Without End-to-End Security . . . . . . . . . . . . . . . 46		9.1. Without End-to-End Security . . . . . . . . . . . . . . . 48
	9.2. With End-to-End Security . . . . . . . . . . . . . . . . 47		9.2. With End-to-End Security . . . . . . . . . . . . . . . . 48
	10. Examples of CoAP Header Compression with Proxies . . . . . . 48		10. Examples of CoAP Header Compression with Proxies . . . . . . 50
	10.1. Without End-to-End Security . . . . . . . . . . . . . . 51		10.1. Without End-to-End Security . . . . . . . . . . . . . . 52
	10.2. With End-to-End Security . . . . . . . . . . . . . . . . 58		10.2. With End-to-End Security . . . . . . . . . . . . . . . . 59
	11. CoAP Fields . . . . . . . . . . . . . . . . . . . . . . . . . 73		11. CoAP Fields . . . . . . . . . . . . . . . . . . . . . . . . . 74
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 75		12. Security Considerations . . . . . . . . . . . . . . . . . . . 76
	12.1. YANG Module . . . . . . . . . . . . . . . . . . . . . . 77		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77		13.1. Static Context Header Compression (SCHC) Parameters . . 78
	13.1. IETF XML . . . . . . . . . . . . . . . . . . . . . . . . 77		13.2. SCHC Compression of CoAP Fields . . . . . . . . . . . . 78
	13.2. YANG Module Names . . . . . . . . . . . . . . . . . . . 77		13.2.1. Intended Use . . . . . . . . . . . . . . . . . . . . 78
	13.3. Static Context Header Compression (SCHC) Parameters . . 78		13.2.2. Structure of Entries . . . . . . . . . . . . . . . . 79
	13.4. SCHC Compression of CoAP Fields . . . . . . . . . . . . 78		13.3. Expert Review Instructions . . . . . . . . . . . . . . . 80
	13.4.1. Intended Use . . . . . . . . . . . . . . . . . . . . 78
	13.4.2. Structure of Entries . . . . . . . . . . . . . . . . 79
	13.5. Expert Review Instructions . . . . . . . . . . . . . . . 80
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
	14.1. Normative References . . . . . . . . . . . . . . . . . . 81		14.1. Normative References . . . . . . . . . . . . . . . . . . 81
	14.2. Informative References . . . . . . . . . . . . . . . . . 83		14.2. Informative References . . . . . . . . . . . . . . . . . 83
	Appendix A. YANG Data Model . . . . . . . . . . . . . . . . . . 84		Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 84
	Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 88		A.1. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 84
	B.1. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 88		A.2. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 85
	B.2. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 88		A.3. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 85
	B.3. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 89		A.4. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 85
	B.4. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 89		A.5. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 86
	B.5. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 89		A.6. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 86
	B.6. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 90		A.7. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 87
	B.7. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 90		A.8. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 87
	B.8. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 91		A.9. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 87
	B.9. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 91		A.10. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 88
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 91		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 88
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
	1. Introduction		1. Introduction
	The Constrained Application Protocol (CoAP) [RFC7252] is a request/		The Constrained Application Protocol (CoAP) [RFC7252] is a request/
	response protocol designed for microcontrollers with small RAM and		response protocol designed for microcontrollers with small RAM and
	ROM, and optimized for services based on REST (Representational State		ROM, and optimized for services based on REST (Representational State
	Transfer). Although constrained devices are a leading factor in the		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		design of CoAP, a CoAP header's size is still too large for Low-Power
	Wide-Area Networks (LPWANs). Applying the Static Context Header		Wide-Area Networks (LPWANs). Applying the Static Context Header
	Compression and fragmentation (SCHC) framework to CoAP headers is		Compression and fragmentation (SCHC) framework to CoAP headers is
	particularly important for improving performance or for enabling the		particularly important for improving performance or for enabling the
	use of CoAP over LPWAN technologies.		use of CoAP over LPWAN technologies.
	[RFC8724] defines the SCHC framework, which includes a header		[RFC8724] defines the SCHC framework, which includes a header
	compression mechanism for LPWANs that is based on a static context.		compression mechanism for LPWANs that is based on a static SCHC
	Section 5 of [RFC8724] explains where compression and decompression		Context. Section 5 of [RFC8724] explains where compression and
	occur in the architecture. The SCHC compression scheme assumes as a		decompression occur in the architecture. The SCHC compression scheme
	prerequisite that both endpoints know the static context before		assumes as a prerequisite that communicating SCHC Instances share the
	transmission. The way the context is configured, provisioned, or		SCHC Context before message transmission. The way the SCHC Context
	exchanged is out of the scope of this document.		is configured, provisioned, or exchanged is out of the scope of this
			document.
	Since CoAP is an application-layer protocol, compressing CoAP headers		Since CoAP is an application-layer protocol, compressing CoAP headers
	requires installing common Rules between the two SCHC instances.		requires installing on the communicating SCHC Instances a common SCHC
	SCHC compression may apply at two different levels: at the IP and UDP		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.		level in the LPWAN, as well as at the application level for CoAP.
	These two compression techniques may be independent. Both follow the		These two compression techniques may be independent; they are then
	same principle as that described in [RFC8724]. As different entities		performed by distinct SCHC Instances, each operating with its own
	manage the CoAP compression process at different levels, the SCHC		SCHC Context. Both follow the same principle as that described in
	Rules driving the compression/decompression are also different.		[RFC8724]. As different entities manage the CoAP compression process
	[RFC8724] describes how to use SCHC for IP and UDP headers. This		at different levels, the SCHC Rules driving the compression/
	document specifies how to apply SCHC compression to CoAP headers.		decompression are also different. [RFC8724] 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 common contexts		SCHC compresses and decompresses headers based on a common SCHC
	between Devices. The SCHC context includes multiple Rules. Each		Context shared between SCHC Instances. The SCHC Context includes
	Rule can match the header fields to specific values or ranges of		multiple Rules in its SCHC Set of Rules (SoR). Each Rule can match
	values. If a Rule matches, then the Rule is selected. When		the header fields to specific values or ranges of values. If a Rule
	performing compression, the matched header fields are replaced by the		matches, then the Rule is selected. When performing compression, the
	RuleID and the Compression Residue that contains the residual bits of		matched header fields are replaced by the RuleID and the Compression
	the compression. Thus, different Rules may correspond to different		Residue that contains the residual bits of the compression. Thus,
	protocol headers in the packet that a Device expects to send or		different Rules may correspond to different protocol headers in the
	receive.		packet that a Device expects to send or receive.
	A Rule describes the packets' entire header with an ordered list of		A Rule describes the packets' entire header with an ordered list of
	Field Descriptors (see Section 7 of [RFC8724]). In turn, each Field		Field Descriptors (see Section 7 of [RFC8724]). In turn, each Field
	Descriptor contains the Field ID (FID), Field Length (FL), and Field		Descriptor contains the Field ID (FID), Field Length (FL), and Field
	Position (FP), as well as a Direction Indicator (DI) (upstream,		Position (FP), as well as a Direction Indicator (DI) (upstream,
	downstream, or bidirectional) and some associated Target Values		downstream, or bidirectional) and some associated Target Values
	(TVs). The DI allows the compression to be based on the best TV for		(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		the Field Descriptor, when the TV to consider is different for the
	different transmission directions. Therefore, a field may be		different transmission directions. Therefore, a field may be
	described several times in the same Rule.		described several times in the same Rule.
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 21 ¶
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Readers are expected to be familiar with the terms and concepts		Readers are expected to be familiar with the terms and concepts
	related to the SCHC framework [RFC8724], CoAP [RFC7252], and the		related to the SCHC framework defined in [RFC8724].
	security protocols OSCORE [RFC8613] and Group Object Security for
	Constrained RESTful Environments (Group OSCORE)		This document uses the following terms that reflect the terminology
	[I-D.ietf-core-oscore-groupcomm].		introduced in [I-D.ietf-schc-architecture]. 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 [RFC7252]. 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 [RFC8613] and Group Object Security
			for Constrained RESTful Environments (Group OSCORE)
			[I-D.ietf-core-oscore-groupcomm]. 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 [RFC7252] 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.
	2. SCHC Applicability to CoAP		2. SCHC Applicability to CoAP
	SCHC compression for CoAP headers MAY be done in conjunction with the		SCHC compression for CoAP headers MAY be done in conjunction with the
	lower layers (IPv6/UDP) or independently. The SCHC adaptation layers		lower layers (IPv6/UDP) or independently. The SCHC adaptation layers
	described in Section 5 of [RFC8724] may be used as shown in Figure 1,		described in Section 5 of [RFC8724] may be used as shown in Figure 1,
	Figure 2, and Figure 3 below.		Figure 2, and Figure 3 below.
	In the first example depicted in Figure 1, a Rule compresses the		In the first example depicted in Figure 1, a Rule compresses the
	complete header stack from IPv6 to CoAP. In this case, the Device		complete header stack from IPv6 to CoAP. In this case, the Device
	and the Network Gateway (NGW) perform SCHC Compression/Decompression		and the Network Gateway (NGW) each comprise a SCHC Endpoint with a
	(SCHC C/D), see [RFC8724]). The application communicating with the		SCHC Instance. These SCHC Instances share a common SCHC Context and
	Device does not implement SCHC C/D.		communicate using a SCHC Session. The application communicating with
			the Device does not implement SCHC C/D and does not comprise a SCHC
			Endpoint.
	(Device) (NGW) (App)		(Device) (NGW) (App)
	+--------+ +--------+		+--------+ +--------+
	| CoAP | | CoAP |		| CoAP | | CoAP |
	+--------+ +--------+		+--------+ +--------+
	| UDP | | UDP |		| UDP | | UDP |
	+--------+ +----------------+ +--------+		+--------+ +----------------+ +--------+
	| IPv6 | | IPv6 | | IPv6 |		| IPv6 | | IPv6 | | IPv6 |
	+--------+ +--------+-------+ +--------+		+--------+ +--------+-------+ +--------+
	| SCHC | | SCHC | | | |		| SCHC | | SCHC | | | |
	+--------+ +--------+ + + +		+--------+ +--------+ + + +
	| LPWAN | | LPWAN | | | |		| LPWAN | | LPWAN | | | |
	+--------+ +--------+-------+ +--------+		+--------+ +--------+-------+ +--------+
	((((LPWAN)))) ------ Internet -------		((((LPWAN)))) ------ Internet -------
	Figure 1: Compression/Decompression at the LPWAN Boundary.		Figure 1: Compression/Decompression at the LPWAN Boundary.
	Figure 1 shows the use of SCHC header compression above Layer 2 in		Figure 1 shows the use of SCHC header compression above Layer 2 in
	the Device and the NGW. The SCHC layer receives non-encrypted		the Device and the NGW. The SCHC Instance at the Device receives
	packets and can apply compression Rules to all the headers in the		non-encrypted packets and applies a matching Rule from its SCHC
	stack. On the other end, the NGW receives the SCHC packet and		Context to all the headers in the stack. On the other end, the NGW
	reconstructs the headers using the Rule and the Compression Residue.		receives the SCHC packet, internally routes it to its correct SCHC
	After the decompression, the NGW forwards the IPv6 packet toward the		Instance, and reconstructs the headers using a matching Rule and the
	destination. The same process applies in the other direction when a		Compression Residue. After the decompression, the NGW forwards the
	non-encrypted packet arrives at the NGW. Thanks to the IP forwarding		IPv6 packet toward the destination. The same process applies in the
	based on the IPv6 prefix, the NGW identifies the Device and		other direction when a non-encrypted packet arrives at the NGW.
	compresses headers using the Device's Rules.		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 Figure 2, SCHC compression is		In the second example depicted in Figure 2, SCHC compression is
	applied in the CoAP layer, compressing the CoAP header independently		applied in the CoAP layer, compressing the CoAP header independently
	of the other layers. The RuleID, Compression Residue, and CoAP		of the other layers. The RuleID, Compression Residue, and CoAP
	payload are encrypted using a mechanism such as DTLS [RFC9147]. Only		payload are encrypted using a mechanism such as DTLS [RFC9147]. Only
	the other end (App) can decipher the information. If needed, layers		the other end (App) can decrypt the incoming information and then
	below use SCHC to compress the header as defined in [RFC8724]		perform SCHC decompression, using a matching Rule from the SCHC
	(represented by dotted lines in the figure).		Context of the appropriate SCHC Instance. If needed, layers below
			use separate SCHC Instances to compress and decompress the
			corresponding headers as defined in [RFC8724] (represented by dotted
			lines in the figure).
	This use case needs an end-to-end context initialization between the		This use case needs that an end-to-end SCHC Instance and SCHC Context
	Device and the application. The context initialization is out of		therein are established between the Device and the application. The
	scope for this document.		establishment of the SCHC Instance and SCHC Context is out of scope
			for this document.
	(Device) (NGW) (App)		(Device) (NGW) (App)
	+--------+ +--------+		+--------+ +--------+
	| CoAP | | CoAP |		| CoAP | | CoAP |
	+--------+ +--------+		+--------+ +--------+
	| SCHC | | SCHC |		| SCHC | | SCHC |
	+--------+ +--------+		+--------+ +--------+
	| DTLS | | DTLS |		| DTLS | | DTLS |
	+--------+ +--------+		+--------+ +--------+
	skipping to change at page 9, line 6 ¶		skipping to change at page 10, line 32 ¶
	.......... .................. ..........		.......... .................. ..........
	. schc . . schc . . . .		. schc . . schc . . . .
	.......... .......... . . .		.......... .......... . . .
	. lpwan . . lpwan . . . .		. lpwan . . lpwan . . . .
	.......... .................. ..........		.......... .................. ..........
	((((LPWAN)))) ------ Internet -------		((((LPWAN)))) ------ Internet -------
	Figure 2: Standalone CoAP End-to-End Compression/Decompression.		Figure 2: Standalone CoAP End-to-End Compression/Decompression.
	The third example depicted in Figure 3 shows the use of the security		The third example depicted in Figure 3 shows the use of the security
	protocol OSCORE [RFC8613]. In this case, SCHC needs two Rules to		protocol OSCORE [RFC8613]. In this case, the CoAP header is
	compress the CoAP header. A first Rule focuses on the Inner header.		compressed by using in sequence two distinct SCHC Instances on the
	The result of this first compression is encrypted using OSCORE.		same SCHC Endpoint, at the Device or at the application. That is, a
	Then, a second Rule compresses the Outer header including the CoAP		matching Rule from the SCHC Context of a first SCHC Instance is used
	option OSCORE.		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.
	(Device) (NGW) (App)		(Device) (NGW) (App)
	+--------+ +--------+		+--------+ +--------+
	| CoAP | | CoAP |		| CoAP | | CoAP |
	| Inner | | Inner |		| Inner | | Inner |
	+--------+ +--------+		+--------+ +--------+
	| SCHC | | SCHC |		| SCHC | | SCHC |
	| Inner | | Inner |		| Inner | | Inner |
	+--------+ +--------+		+--------+ +--------+
	skipping to change at page 9, line 39 ¶		skipping to change at page 11, line 32 ¶
	. ipv6 . . ipv6 . . ipv6 .		. ipv6 . . ipv6 . . ipv6 .
	.......... .................. ..........		.......... .................. ..........
	. schc . . schc . . . .		. schc . . schc . . . .
	.......... .......... . . .		.......... .......... . . .
	. lpwan . . lpwan . . . .		. lpwan . . lpwan . . . .
	.......... .................. ..........		.......... .................. ..........
	((((LPWAN)))) ------ Internet -------		((((LPWAN)))) ------ Internet -------
	Figure 3: Compression/Decompression when Using OSCORE.		Figure 3: Compression/Decompression when Using OSCORE.
	In the case of several SCHC instances as shown in Figure 2 and		In the case of several SCHC Instances as shown in Figure 2 and
	Figure 3, the Rules may come from different provisioning domains.		Figure 3, 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		This document focuses on CoAP compression, as represented by the
	dashed boxes in the previous figures.		dashed boxes in the previous figures.
	3. CoAP Headers Compressed with SCHC		3. CoAP Headers Compressed with SCHC
	The use of SCHC over the CoAP header relies on the same principles		The use of SCHC over the CoAP header relies on the same principles
	and compression/decompression techniques used for IP and UDP headers,		and compression/decompression techniques used for IP and UDP headers,
	as explained in [RFC8724]. For CoAP, the SCHC Rules description uses		as explained in [RFC8724]. For CoAP, the SCHC Rules description uses
	the direction information to optimize the compression by reducing the		the direction information to optimize the compression by reducing the
	skipping to change at page 11, line 12 ¶		skipping to change at page 13, line 8 ¶
	SCHC does not need to send it. In IPv6 and UDP headers, the		SCHC does not need to send it. In IPv6 and UDP headers, the
	fields have a fixed size, known by definition.		fields have a fixed size, known by definition.
	On the other hand, some CoAP header fields have variable lengths		On the other hand, some CoAP header fields have variable lengths
	and the Rule description makes it possible to specify it. For		and the Rule description makes it possible to specify it. For
	example, the size of the Token field may vary from 0 to 65804		example, the size of the Token field may vary from 0 to 65804
	bytes [RFC8974], and the CoAP options rely on the Type-Length-		bytes [RFC8974], and the CoAP options rely on the Type-Length-
	Value encoding format to specify the size of the actual option		Value encoding format to specify the size of the actual option
	value in bytes.		value in bytes.
	Given a Rule description, the following defines how the FL is used		Given a Rule description and building on Section 7.4.2 of
	within the Field Descriptor corresponding to a variable-length		[RFC8724], the following defines how the FL is used within the
	field.		Field Descriptor corresponding to a variable-length field.
	If the CDA in the Field Descriptor is set to "not-sent" or to
	"mapping-sent", then the FL is not set. In fact, the field length
	can always be determined based on what is specified in the TV of
	the Field Descriptor.
	Otherwise, the FL can specify an exact length in bits, if it is
	known in advance that the present header field is going to be used
	with such a length. More generally and building on Section 7.4.2
	of [RFC8724], the following applies when doing SCHC compression of
	a variable-length field for which it is not possible to specify an
	exact, expected length in the FL of the corresponding Field
	Descriptor.
	If the field compression relies on the CDA "value-sent" or LSB,		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		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		Descriptor, with byte being the unit used for the residue value's
	size. In such case, the residue value's size prepended to the		size. In such case, the residue value's size prepended to the
	residue value encodes the size of the residue value in bytes, and		residue value encodes the size of the residue value in bytes, and
	the decompressor MUST interpret the residue value as consisting of		the decompressor MUST interpret the residue value as consisting of
	exactly that number of bytes.		exactly that number of bytes.
	Alternatively to "var", a function "var_X" can be used for the FL		Alternatively to "var", a function "var_X" can be used for the FL
	skipping to change at page 12, line 19 ¶		skipping to change at page 13, line 45 ¶
	example, if the function "var_bit" is used and the residue value's		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		size for the compressed field is 17 bits, that size is encoded as
	0b1111 00010001.		0b1111 00010001.
	As an alternative to the function "var" or to a function "var_X",		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		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		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		to define a specific function for the FL in the Field Descriptor
	of the present field, with that function returning the length of		of the present field, with that function returning the length of
	the field in the unit specified with the function (e.g., see the		the field in the unit specified with the function (e.g., see the
	"tkl" function defined in Section 4.6). This holds irrespective		"tkl" function defined in Section 4.6).
	of the CDA used for compressing the field.
			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:
			o With the length of the value that is specified in the TV of
			the Field Descriptor, if CDA is set to "not sent"; or
			o 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 Section 7.4.2 of [RFC8724]), the unit associated
			with the function plays no role.
	* A field can appear several times in a CoAP header. This is		* 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		typically the case for elements of a URI (i.e., path segments or
	query parameters). The SCHC specification [RFC8724] allows an FID		query parameters). The SCHC specification [RFC8724] allows an FID
	to appear several times in the Rule and uses the Field Position		to appear several times in the Rule and uses the Field Position
	(FP) to identify the correct instance, thus preventing MO's		(FP) to identify the correct occurrence of that field, thus
	possible ambiguities.		preventing MO's possible ambiguities.
	* Field Lengths defined in CoAP can be too large when it comes to		* Field Lengths defined in CoAP can be too large when it comes to
	LPWAN traffic constraints. For instance, this is particularly		LPWAN traffic constraints. For instance, this is particularly
	true for the Message ID field and the Token field. SCHC uses		true for the Message ID field and the Token field. SCHC uses
	different MOs to perform the compression (see Section 7.4 of		different MOs to perform the compression (see Section 7.4 of
	[RFC8724]). In this case, SCHC can apply the Most Significant		[RFC8724]). In this case, SCHC can apply the Most Significant
	Bits (MSBs) MO to reduce the information carried on LPWANs.		Bits (MSBs) MO to reduce the information carried on LPWANs.
	4. Compression of CoAP Header Fields		4. Compression of CoAP Header Fields
	skipping to change at page 14, line 5 ¶		skipping to change at page 16, line 5 ¶
	If the Token Length field value does not change over time, the SCHC		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		Rule describes the TV set to that value, the MO set to "equal", and
	the CDA set to "not-sent", thereby eliding the field.		the CDA set to "not-sent", thereby eliding the field.
	Otherwise, if the Token Length field value changes over time, the		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		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		the CDA to "value-sent". The Rule may also use a "match-mapping" MO
	to compress the value.		to compress the value.
	Consistent with the above, this section updates the ietf-schc module
	defined in [RFC9363]. In particular, the definition of the fid-coap-
	tkl "identity" statement is updated by replacing the argument of its
	"reference" substatement with the following string: "RFC 8974
	Extended Tokens and Stateless Clients in the Constrained Application
	Protocol (CoAP)".
	4.4. CoAP Code Field		4.4. CoAP Code Field
	The Code field takes value from the "Code" column of the "CoAP Codes"		The Code field takes value from the "Code" column of the "CoAP Codes"
	IANA registry, encoded as specified in Section 3 of [RFC7252]. This		IANA registry, encoded as specified in Section 3 of [RFC7252]. This
	field indicates the Method Code of a CoAP request or the Response		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		Code of a CoAP Response, while the value 0.00 indicates an Empty
	message. The compression of the CoAP Code field follows the same		message. The compression of the CoAP Code field follows the same
	principle as that of the CoAP Type field.		principle as that of the CoAP Type field.
	If the Device plays a specific role, SCHC may split the code values		If the Device plays a specific role, SCHC may split the code values
	skipping to change at page 15, line 15 ¶		skipping to change at page 17, line 5 ¶
	Instead, SCHC MUST use the value of the Token Length field to define		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,		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		SCHC designates a specific function, "tkl", that the Rule MUST use to
	complete the Field Descriptor. During the decompression, this		complete the Field Descriptor. During the decompression, this
	function returns the length of the Token field in bytes, which is		function returns the length of the Token field in bytes, which is
	specified by the Token Length field as per Section 2.1 of [RFC8974].		specified by the Token Length field as per Section 2.1 of [RFC8974].
	This construct avoids ambiguity with the Token Length field and		This construct avoids ambiguity with the Token Length field and
	results in a more efficient compression of the Token field.		results in a more efficient compression of the Token field.
	Consistent with the above, this section updates the ietf-schc module
	defined in [RFC9363]. In particular, the definition of the fid-coap-
	token "identity" statement is updated by replacing the argument of
	its "reference" substatement with the following string: "RFC 8974
	Extended Tokens and Stateless Clients in the Constrained Application
	Protocol (CoAP)".
	5. Compression of CoAP Options		5. Compression of CoAP Options
	CoAP defines the use of options, which are placed after the mandatory		CoAP defines the use of options, which are placed after the mandatory
	header and the Token field and are ordered by option number (see		header and the Token field and are ordered by option number (see
	Section 3 of [RFC7252]). As per Section 3.1 of [RFC7252], each		Section 3 of [RFC7252]). As per Section 3.1 of [RFC7252], each
	option instance in a message relies on a format consisting of an		occurrence of an option in a message relies on a format consisting of
	Option Delta (D), an Option Length (L), and an Option Value (V).		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		The Option Delta is used to express the option number of a CoAP
	option within a CoAP message, as the difference between the Option		option within a CoAP message, as the difference between the Option
	Number of that option and the Option Number of the previous option in		Number of that option and the Option Number of the previous option in
	that message (or zero for the first option). In the byte-		that message (or zero for the first option). In the byte-
	representation of CoAP options used on the wire, Option Delta is		representation of CoAP options used on the wire, Option Delta is
	encoded either by a 4-bit "Option Delta" field or by that field		encoded either by a 4-bit "Option Delta" field or by that field
	together with an additional 1- or 2-byte "Option Delta (Extended)"		together with an additional 1- or 2-byte "Option Delta (Extended)"
	field.		field.
	skipping to change at page 16, line 12 ¶		skipping to change at page 17, line 41 ¶
	specified after the Field Descriptors related to the CoAP header		specified after the Field Descriptors related to the CoAP header
	fields discussed in Section 4.		fields discussed in Section 4.
	In particular, the Field Descriptors related to CoAP options MUST be		In particular, the Field Descriptors related to CoAP options MUST be
	listed in the same order according to which the corresponding CoAP		listed in the same order according to which the corresponding CoAP
	options appear in the CoAP message (i.e., ordered by option number).		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		If a SCHC Rule is intended to compress a CoAP message where a
	repeatable CoAP option is specified multiple times, then the SCHC		repeatable CoAP option is specified multiple times, then the SCHC
	Rule generally includes different Field Descriptors that separately		Rule generally includes different Field Descriptors that separately
	correspond to the different instances of that CoAP option. Those		correspond to the different occurrences of that CoAP option. Those
	Field Descriptors MUST be listed in the same order of the		Field Descriptors MUST be listed in the same order of the
	corresponding CoAP option instances in the CoAP message. In order to		corresponding CoAP option occurrences in the CoAP message. In order
	optimize the compression, a single Field Descriptor MAY pertain to		to optimize the compression, a single Field Descriptor MAY pertain to
	multiple adjacent instances of the same CoAP option that are treated		multiple adjacent occurrences of the same CoAP option that are
	as grouped together (e.g., see Section 5.4).		treated as grouped together (e.g., see Section 5.4).
	As further discussed in [I-D.ietf-schc-universal-option], the		As further discussed in [I-D.ietf-schc-universal-option], the
	composition and use of Field Descriptors for compressing/		composition and use of Field Descriptors for compressing/
	decompressing CoAP options can take a "syntactic" approach or a		decompressing CoAP options can take a "syntactic" approach or a
	"semantic" approach.		"semantic" approach.
	The syntactic approach operates faithfully to the byte-representation		The syntactic approach operates faithfully to the byte-representation
	of CoAP options used on the wire. Consequently, it requires multiple		of CoAP options used on the wire. Consequently, it requires multiple
	Field Descriptors for each given instance of CoAP option to be		Field Descriptors for each given occurrence of CoAP option to be
	compressed/decompressed. That is, each of such Field Descriptors		compressed/decompressed. That is, each of such Field Descriptors
	pertains to the compression/decompression of the Option Delta, the		pertains to the compression/decompression of the Option Delta, the
	Option Length, or the Option Value of the CoAP option in question.		Option Length, or the Option Value of the CoAP option in question.
	On the contrary, the typically used semantic approach abstracts away		On the contrary, the typically used semantic approach abstracts away
	from the byte-representation of CoAP options (or, more generally, of		from the byte-representation of CoAP options (or, more generally, of
	protocol header fields) and maps those into generic representations		protocol header fields) and maps those into generic representations
	identified by the FIDs of the related Field Descriptors. The		identified by the FIDs of the related Field Descriptors. The
	semantic approach effectively streamlines Field Descriptors related		semantic approach effectively streamlines Field Descriptors related
	to CoAP options as required to specify only information about the		to CoAP options as required to specify only information about the
	skipping to change at page 19, line 31 ¶		skipping to change at page 21, line 20 ¶
	Otherwise, these options' values will be sent in the Compression		Otherwise, these options' values will be sent in the Compression
	Residue, i.e., the SCHC Rule description does not set the TV, while		Residue, i.e., the SCHC Rule description does not set the TV, while
	setting the MO to "ignore" and the CDA to "value-sent".		setting the MO to "ignore" and the CDA to "value-sent".
	5.4. CoAP Option Uri-Path and Uri-Query Fields		5.4. CoAP Option Uri-Path and Uri-Query Fields
	The Uri-Path and Uri-Query fields are repeatable options, i.e., the		The Uri-Path and Uri-Query fields are repeatable options, i.e., the
	CoAP header may include them several times and with different values.		CoAP header may include them several times and with different values.
	The SCHC Rule description uses the FP to distinguish the different		The SCHC Rule description uses the FP to distinguish the different
	instances of such options.		occurrences of such options.
	To compress these repeatable field values, SCHC can use a "match-		To compress these repeatable field values, SCHC can use a "match-
	mapping" MO to reduce the size of variable paths or queries. When		mapping" MO to reduce the size of variable paths or queries. When
	doing so, several elements can be regrouped into a single entry in		doing so, several elements can be regrouped into a single entry in
	order to optimize the compression. The numbering of elements does		order to optimize the compression. The numbering of elements does
	not change, and the first matching element sets the MO comparison.		not change, and the first matching element sets the MO comparison.
	For example, as per the Rule descriptions shown in Table 1, SCHC can		For example, as per the Rule descriptions shown in Table 1, SCHC can
	use a single bit in the Compression Residue to code the path segments		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,		"/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		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		time, SCHC sends the third path element following "/a/b" or "/c/d" as
	a variable-size field in the Compression Residue.		a variable-size field in the Compression Residue.
	+============+=====+==+====+=========+===============+==============+		+============+=====+==+====+=========+===============+==============+
	| FID | FL |FP| DI | TV | MO | CDA |		| FID | FL |FP| DI | TV | MO | CDA |
	+============+=====+==+====+=========+===============+==============+		+============+=====+==+====+=========+===============+==============+
	| CoAP. | |1 | Up | ["/a/ | match-mapping | mapping-sent |		| CoAP. | var |1 | Up | ["/a/ | match-mapping | mapping-sent |
	| option(11) | | | | b", | | |		| option(11) | | | | b", | | |
	| | | | | "/c/ | | |		| | | | | "/c/ | | |
	| | | | | d"] | | |		| | | | | d"] | | |
	+------------+-----+--+----+---------+---------------+--------------+		+------------+-----+--+----+---------+---------------+--------------+
	| CoAP. | var |3 | Up | | ignore | value-sent |		| CoAP. | var |3 | Up | | ignore | value-sent |
	| option(11) | | | | | | |		| option(11) | | | | | | |
	+------------+-----+--+----+---------+---------------+--------------+		+------------+-----+--+----+---------+---------------+--------------+
	Table 1: Complex Path Example. CoAP Option Numbers: 11 (Uri-Path).		Table 1: Complex Path Example. CoAP Option Numbers: 11 (Uri-Path).
	skipping to change at page 21, line 8 ¶		skipping to change at page 22, line 28 ¶
	For instance, for a CORECONF path /c/X6?k=eth0, the Rule description		For instance, for a CORECONF path /c/X6?k=eth0, the Rule description
	can be as shown in Table 2. That is, SCHC compresses the first part		can be as shown in Table 2. That is, SCHC compresses the first part
	of the URI path with a "not-sent" CDA. Also, SCHC will send the		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		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		"X6"), which is followed by the query parameter's value preceded by
	the length (i.e., 0b0100 "eth0").		the length (i.e., 0b0100 "eth0").
	+============+=====+====+====+======+=========+============+		+============+=====+====+====+======+=========+============+
	| FID | FL | FP | DI | TV | MO | CDA |		| FID | FL | FP | DI | TV | MO | CDA |
	+============+=====+====+====+======+=========+============+		+============+=====+====+====+======+=========+============+
	| CoAP. | | 1 | Up | "c" | equal | not-sent |		| CoAP. | var | 1 | Up | "c" | equal | not-sent |
	| option(11) | | | | | | |		| option(11) | | | | | | |
	+------------+-----+----+----+------+---------+------------+		+------------+-----+----+----+------+---------+------------+
	| CoAP. | var | 2 | Up | | ignore | value-sent |		| CoAP. | var | 2 | Up | | ignore | value-sent |
	| option(11) | | | | | | |		| option(11) | | | | | | |
	+------------+-----+----+----+------+---------+------------+		+------------+-----+----+----+------+---------+------------+
	| CoAP. | var | 1 | Up | "k=" | MSB(16) | LSB |		| CoAP. | var | 1 | Up | "k=" | MSB(16) | LSB |
	| option(15) | | | | | | |		| option(15) | | | | | | |
	+------------+-----+----+----+------+---------+------------+		+------------+-----+----+----+------+---------+------------+
	Table 2: CORECONF URI compression. CoAP Option Numbers:		Table 2: CORECONF URI compression. CoAP Option Numbers:
	skipping to change at page 27, line 38 ¶		skipping to change at page 29, line 10 ¶
	send the size of the residue resulting from the compression of the		send the size of the residue resulting from the compression of the
	piv subfield, which is otherwise requested for variable-size fields		piv subfield, which is otherwise requested for variable-size fields
	when the CDA specified in the Field Descriptor is "value-sent" or LSB		when the CDA specified in the Field Descriptor is "value-sent" or LSB
	(see Section 7.4.2 of [RFC8724]).		(see Section 7.4.2 of [RFC8724]).
	Instead, SCHC MUST use the value n from the first byte of the OSCORE		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		Option value to define the size of the piv subfield in the
	Compression Residue. To this end, SCHC designates a specific		Compression Residue. To this end, SCHC designates a specific
	function, "osc.piv", that the Rule MUST use to complete the Field		function, "osc.piv", that the Rule MUST use to complete the Field
	Descriptor. During the decompression, this function returns the		Descriptor. During the decompression, this function returns the
	value n, hence the length of the piv subfield in bytes.		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		This construct avoids ambiguity with the value n from the first byte
	of the OSCORE Option value and results in a more efficient		of the OSCORE Option value and results in a more efficient
	compression of the piv subfield.		compression of the piv subfield.
	7. Compression of the CoAP Payload Marker		7. Compression of the CoAP Payload Marker
	The following applies with respect to the 0xFF payload marker. A		The following applies with respect to the 0xFF payload marker. A
	SCHC compression Rule for CoAP includes all the expected CoAP		SCHC compression Rule for CoAP includes all the expected CoAP
	options, therefore the payload marker does not have to be specified		options, therefore the payload marker does not have to be specified
	skipping to change at page 29, line 4 ¶		skipping to change at page 30, line 4 ¶
	8.1. Mandatory Header with CON Message		8.1. Mandatory Header with CON Message
	In this first scenario, the SCHC compressor on the NGW side receives		In this first scenario, the SCHC compressor on the NGW side receives
	a POST message from an Internet client, which is immediately		a POST message from an Internet client, which is immediately
	acknowledged by the Device. Table 3 describes the SCHC Rule		acknowledged by the Device. Table 3 describes the SCHC Rule
	descriptions for this scenario.		descriptions for this scenario.
	+----------+		+----------+
	| RuleID 1 |		| RuleID 1 |
	+----------+		+----------+
	+============+==+====+====+==========+=========+==========+========+		+============+=====+==+==+==========+=========+==========+========+
	| FID |FL| FP | DI | TV | MO | CDA | Sent |		| FID | FL |FP|DI| TV | MO | CDA | Sent |
	| | | | | | | | [bits] |		| | | | | | | | [bits] |
	+============+==+====+====+==========+=========+==========+========+		+============+=====+==+==+==========+=========+==========+========+
	| CoAP. |2 | 1 | Bi | 1 | equal | not-sent | |		| CoAP. | 2 |1 |Bi| 1 | equal | not-sent | |
	| Version | | | | | | | |		| Version | | | | | | | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	| CoAP. |2 | 1 | Dw | CON | equal | not-sent | |		| CoAP. | 2 |1 |Dw| CON | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	| CoAP. |2 | 1 | Up | [ACK, | match- | mapping- | T |		| CoAP. | 2 |1 |Up| [ACK, | match- | mapping- | T |
	| Type | | | | RST] | mapping | sent | |		| Type | | | | RST] | mapping | sent | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	| CoAP. | | 1 | Bi | 0b0000 | equal | not-sent | |		| CoAP. | var |1 |Bi| 0b0000 | equal | not-sent | |
	| TKL | | | | | | | |		| TKL | | | | | | | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	| CoAP. |8 | 1 | Bi | [0.00, | match- | mapping- | CC CCC |		| CoAP. | 8 |1 |Bi| [0.00, | match- | mapping- | CC CCC |
	| Code | | | | ... | mapping | sent | |		| Code | | | | ... | mapping | sent | |
	| | | | | 5.05] | | | |		| | | | | 5.05] | | | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	| CoAP. |16| 1 | Bi | 0x0000 | MSB(7) | LSB | MID |		| CoAP. | 16 |1 |Bi| 0x0000 | MSB(7) | LSB | MID |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	| CoAP. | | 1 | Dw | "status" | equal | not-sent | |		| CoAP. | var |1 |Dw| "status" | equal | not-sent | |
	| option(11) | | | | | | | |		| option(11) | | | | | | | |
	+------------+--+----+----+----------+---------+----------+--------+		+------------+-----+--+--+----------+---------+----------+--------+
	Table 3: CoAP Context to compress header without Token. CoAP		Table 3: CoAP Context to compress header without Token. CoAP
	Option Numbers: 11 (Uri-Path).		Option Numbers: 11 (Uri-Path).
	In this example, SCHC compression elides the Version and Token Length		In this example, SCHC compression elides the Version and Token Length
	fields. The 25 Method and Response Codes defined in [RFC7252] have		fields. The 25 Method and Response Codes defined in [RFC7252] have
	been shrunk to 5 bits using a "match-mapping" MO. The Uri-Path		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		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		to "not-sent", thereby eliding the single occurrence of the Uri-Path
	Option with value "status".		Option with value "status".
	SCHC compression reduces the header, sending only a mapped Type (and		SCHC compression reduces the header, sending only a mapped Type (and
	only for uplink messages), a mapped code, and the least significant		only for uplink messages), a mapped code, and the least significant
	skipping to change at page 36, line 13 ¶		skipping to change at page 37, line 13 ¶
	Figure 9: CoAP Content Response.		Figure 9: CoAP Content Response.
	The SCHC Rules for the Inner Compression include all the fields that		The SCHC Rules for the Inner Compression include all the fields that
	are present in a regular CoAP message. The methods described in		are present in a regular CoAP message. The methods described in
	Section 4 apply to these fields. Table 4 provides an example.		Section 4 apply to these fields. Table 4 provides an example.
	+----------+		+----------+
	| RuleID 0 |		| RuleID 0 |
	+----------+		+----------+
	+============+==+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| FID |FL|FP|DI| TV | MO | CDA |Sent |		| FID |FL |FP|DI| TV | MO | CDA |Sent |
	| | | | | | | |[bits]|		| | | | | | | |[bits]|
	+============+==+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| CoAP. |8 |1 |Up| 1 | equal | not-sent | |		| CoAP. |8 |1 |Up| 1 | equal | not-sent | |
	| Code | | | | | | | |		| Code | | | | | | | |
	+------------+--+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Dw| [69, 132] | match- | mapping- |C |		| CoAP. |8 |1 |Dw| [69, 132] | match- | mapping- |C |
	| Code | | | | | mapping | sent | |		| Code | | | | | mapping | sent | |
	+------------+--+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Up| "temperature" | equal | not-sent | |		| CoAP. |var|1 |Up| "temperature" | equal | not-sent | |
	| option(11) | | | | | | | |		| option(11) | | | | | | | |
	+------------+--+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	Table 4: Inner SCHC Rule. CoAP Option Numbers: 11 (Uri-Path).		Table 4: Inner SCHC Rule. CoAP Option Numbers: 11 (Uri-Path).
	Figure 10 shows the Plaintext obtained for the example GET request.		Figure 10 shows the Plaintext obtained for the example GET request.
	The packet follows the process of Inner Compression and encryption		The packet follows the process of Inner Compression and encryption
	until the payload. The Outer OSCORE message adds the result of the		until the payload. The Outer OSCORE message adds the result of the
	Inner process.		Inner process.
	+---------------------------------------------------+		+---------------------------------------------------+
	| |		| |
	| OSCORE Plaintext |		| OSCORE Plaintext |
	| |		| |
	skipping to change at page 40, line 32 ¶		skipping to change at page 41, line 32 ¶
	+============+=========+==+==+==========+=========+======+========+		+============+=========+==+==+==========+=========+======+========+
	| CoAP. | 2 |1 |Bi| 1 | equal | not- | |		| CoAP. | 2 |1 |Bi| 1 | equal | not- | |
	| Version | | | | | | sent | |		| Version | | | | | | sent | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | 2 |1 |Up| 0 | equal | not- | |		| CoAP. | 2 |1 |Up| 0 | equal | not- | |
	| Type | | | | | | sent | |		| Type | | | | | | sent | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | 2 |1 |Dw| 2 | equal | not- | |		| CoAP. | 2 |1 |Dw| 2 | equal | not- | |
	| Type | | | | | | sent | |		| Type | | | | | | sent | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | |1 |Bi| 0b0001 | equal | not- | |		| CoAP. | var |1 |Bi| 0b0001 | equal | not- | |
	| TKL | | | | | | sent | |		| TKL | | | | | | sent | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | 8 |1 |Up| 2 | equal | not- | |		| CoAP. | 8 |1 |Up| 2 | equal | not- | |
	| Code | | | | | | sent | |		| Code | | | | | | sent | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | 8 |1 |Dw| 68 | equal | not- | |		| CoAP. | 8 |1 |Dw| 68 | equal | not- | |
	| Code | | | | | | sent | |		| Code | | | | | | sent | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | 16 |1 |Bi| 0x0000 | MSB(12) | LSB | MMMM |		| CoAP. | 16 |1 |Bi| 0x0000 | MSB(12) | LSB | MMMM |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | tkl |1 |Bi| 0x80 | MSB(5) | LSB | TTT |		| CoAP. | tkl |1 |Bi| 0x80 | MSB(5) | LSB | TTT |
	| Token | | | | | | | |		| Token | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | |1 |Up| 0x09 | equal | not- | |		| CoAP. | 8 |1 |Up| 0x09 | equal | not- | |
	| option(9). | | | | | | sent | |		| option(9). | | | | | | sent | |
	| flags | | | | | | | |		| flags | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | |1 |Dw| b'' | equal | not- | |		| CoAP. | 8 |1 |Dw| b'' | equal | not- | |
	| option(9). | | | | | | sent | |		| option(9). | | | | | | sent | |
	| flags | | | | | | | |		| flags | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | osc.piv |1 |Up| 0x00 | MSB(4) | LSB | PPPP |		| CoAP. | osc.piv |1 |Up| 0x00 | MSB(4) | LSB | PPPP |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| piv | | | | | | | |		| piv | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | |1 |Dw| b'' | equal | not- | |		| CoAP. | osc.piv |1 |Dw| b'' | equal | not- | |
	| option(9). | | | | | | sent | |		| option(9). | | | | | | sent | |
	| piv | | | | | | | |		| piv | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | |1 |Bi| b'' | equal | not- | |		| CoAP. | var |1 |Bi| b'' | equal | not- | |
	| option(9). | | | | | | sent | |		| option(9). | | | | | | sent | |
	| kid_ctx | | | | | | | |		| kid_ctx | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | var_bit |1 |Up| 0x636c69 | MSB(44) | LSB | KKKK |		| CoAP. | var_bit |1 |Up| 0x636c69 | MSB(44) | LSB | KKKK |
	| option(9). | | | | 656e70 | | | |		| option(9). | | | | 656e70 | | | |
	| kid | | | | | | | |		| kid | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	| CoAP. | |1 |Dw| b'' | equal | not- | |		| CoAP. | var |1 |Dw| b'' | equal | not- | |
	| option(9). | | | | | | sent | |		| option(9). | | | | | | sent | |
	| kid | | | | | | | |		| kid | | | | | | | |
	+------------+---------+--+--+----------+---------+------+--------+		+------------+---------+--+--+----------+---------+------+--------+
	Table 5: Outer SCHC Rule. CoAP Option Numbers: 9 (OSCORE).		Table 5: Outer SCHC Rule. CoAP Option Numbers: 9 (OSCORE).
	Protected message:		Protected message:
	==================		==================
	0x4102000182980904636c69656e74ffa2c54fe1b434297b62		0x4102000182980904636c69656e74ffa2c54fe1b434297b62
	(24 bytes)		(24 bytes)
	skipping to change at page 45, line 26 ¶		skipping to change at page 46, line 26 ¶
	+============+===+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| CoAP. |2 |1 |Bi| 1 | equal | not-sent | |		| CoAP. |2 |1 |Bi| 1 | equal | not-sent | |
	| Version | | | | | | | |		| Version | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |2 |1 |Up| 0 | equal | not-sent | |		| CoAP. |2 |1 |Up| 0 | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |2 |1 |Dw| 2 | equal | not-sent | |		| CoAP. |2 |1 |Dw| 2 | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Bi| 0b0001 | equal | not-sent | |		| CoAP. |var|1 |Bi| 0b0001 | equal | not-sent | |
	| TKL | | | | | | | |		| TKL | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Up| 2 | equal | not-sent | |		| CoAP. |8 |1 |Up| 2 | equal | not-sent | |
	| Code | | | | | | | |		| Code | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Dw| [69, 132] | match- | mapping- |C |		| CoAP. |8 |1 |Dw| [69, 132] | match- | mapping- |C |
	| Code | | | | | mapping | sent | |		| Code | | | | | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |16 |1 |Bi| 0x0000 | MSB(12) | LSB |MMMM |		| CoAP. |16 |1 |Bi| 0x0000 | MSB(12) | LSB |MMMM |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |tkl|1 |Bi| 0x80 | MSB(5) | LSB |TTT |		| CoAP. |tkl|1 |Bi| 0x80 | MSB(5) | LSB |TTT |
	| Token | | | | | | | |		| Token | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Up| "temperature" | equal | not-sent | |		| CoAP. |var|1 |Up| "temperature" | equal | not-sent | |
	| option(11) | | | | | | | |		| option(11) | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	Table 6: SCHC-CoAP Rule (No OSCORE). CoAP Option Numbers: 11		Table 6: SCHC-CoAP Rule (No OSCORE). CoAP Option Numbers: 11
	(Uri-Path).		(Uri-Path).
	The Rule in Table 6 yields the SCHC compression results shown in		The Rule in Table 6 yields the SCHC compression results shown in
	Figure 16 for the request and in Figure 17 for the response.		Figure 16 for the request and in Figure 17 for the response.
	Compressed message:		Compressed message:
	skipping to change at page 46, line 39 ¶		skipping to change at page 47, line 39 ¶
	Figure 17: CoAP Content Compressed without OSCORE.		Figure 17: CoAP Content Compressed without OSCORE.
	As it can be seen, the difference between applying SCHC + OSCORE as		As it can be seen, the difference between applying SCHC + OSCORE as
	compared to regular SCHC + CoAP is about 10 bytes.		compared to regular SCHC + CoAP is about 10 bytes.
	9. CoAP Header Compression with Proxies		9. CoAP Header Compression with Proxies
	This section defines how SCHC Compression/Decompression is performed		This section defines how SCHC Compression/Decompression is performed
	when CoAP proxies are deployed. The following refers to the origin		when CoAP proxies are deployed. The following refers to the origin
	client and origin server as application endpoints.		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		Note that SCHC Compression/Decompression of CoAP headers is not
	necessarily used between each pair of hops in the communication		necessarily used between each pair of hops in the communication
	chain. For example, if a proxy is deployed between an origin client		chain. For example, if a proxy is deployed between an origin client
	and an origin server, SCHC might be used on the communication leg		and an origin server, SCHC might be used on the communication leg
	between the origin client and the proxy, but not on the communication		between the origin client and the proxy, but not on the communication
	leg between the proxy and the origin server.		leg between the proxy and the origin server.
	9.1. Without End-to-End Security		9.1. Without End-to-End Security
	In the case that OSCORE is not used end-to-end between client and		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		server, the SCHC processing occurs hop-by-hop, by relying on SCHC
	Rules that are consistently shared between two adjacent hops.		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.		In particular, SCHC is used as defined below.
	* The sender application endpoint compresses the CoAP message, by		* The sender application endpoint compresses the CoAP message, by
	using the SCHC Rules that it shares with the next hop towards the		using the SCHC Rules that it shares with the next hop towards the
	recipient application endpoint. The resulting, compressed message		recipient application endpoint. The resulting, compressed message
	is sent to the next hop towards the recipient application		is sent to the next hop towards the recipient application
	endpoint.		endpoint.
	* Each proxy decompresses the incoming compressed message, by using		* Each proxy decompresses the incoming compressed message, by using
	skipping to change at page 47, line 36 ¶		skipping to change at page 49, line 8 ¶
	the previous hop towards the sender application endpoint.		the previous hop towards the sender application endpoint.
	9.2. With End-to-End Security		9.2. With End-to-End Security
	In the case that OSCORE is used end-to-end between client and server		In the case that OSCORE is used end-to-end between client and server
	(see Section 8.2), the following applies.		(see Section 8.2), the following applies.
	The SCHC processing occurs end-to-end as to the Inner SCHC		The SCHC processing occurs end-to-end as to the Inner SCHC
	Compression/Decompression, by relying on Inner SCHC Rules that are		Compression/Decompression, by relying on Inner SCHC Rules that are
	consistently shared between the two application endpoints acting as		consistently shared between the two application endpoints acting as
	OSCORE endpoints and sharing the used OSCORE Security Context.		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		Instead, the SCHC processing occurs hop-by-hop as to the Outer SCHC
	Compression/Decompression, by relying on Outer SCHC Rules that are		Compression/Decompression, by relying on Outer SCHC Rules that are
	consistently shared between two adjacent hops.		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.		In particular, SCHC is used as defined below.
	* The sender application endpoint performs the Inner SCHC		* The sender application endpoint performs the Inner SCHC
	Compression on the original CoAP message, by using the Inner SCHC		Compression on the original CoAP message, by using the Inner SCHC
	Rules that it shares with the recipient application endpoint.		Rules that it shares with the recipient application endpoint.
	Following the AEAD Encryption of the compressed input obtained		Following the AEAD Encryption of the compressed input obtained
	from the previous step, the sender application endpoint performs		from the previous step, the sender application endpoint performs
	the Outer SCHC Compression on the resulting OSCORE-protected		the Outer SCHC Compression on the resulting OSCORE-protected
	skipping to change at page 52, line 17 ¶		skipping to change at page 53, line 17 ¶
	+============+===+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| CoAP. |2 |1 |Bi| 1 | equal | not-sent | |		| CoAP. |2 |1 |Bi| 1 | equal | not-sent | |
	| Version | | | | | | | |		| Version | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |2 |1 |Up| 0 | equal | not-sent | |		| CoAP. |2 |1 |Up| 0 | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |2 |1 |Dw| [0, 2] | match- | mapping- |T |		| CoAP. |2 |1 |Dw| [0, 2] | match- | mapping- |T |
	| Type | | | | | mapping | sent | |		| Type | | | | | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Bi| 0b0001 | equal | not-sent | |		| CoAP. |var|1 |Bi| 0b0001 | equal | not-sent | |
	| TKL | | | | | | | |		| TKL | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Up| [1, 2, | match- | mapping- |CC |		| CoAP. |8 |1 |Up| [1, 2, | match- | mapping- |CC |
	| Code | | | | 3, 4] | mapping | sent | |		| Code | | | | 3, 4] | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Dw| [65, 68, | match- | mapping- |CC |		| CoAP. |8 |1 |Dw| [65, 68, | match- | mapping- |CC |
	| Code | | | | 69, 132] | mapping | sent | |		| Code | | | | 69, 132] | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |16 |1 |Bi| 0x0000 | MSB(12) | LSB |MMMM |		| CoAP. |16 |1 |Bi| 0x0000 | MSB(12) | LSB |MMMM |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |tkl|1 |Bi| 0x80 | MSB(5) | LSB |TTT |		| CoAP. |tkl|1 |Bi| 0x80 | MSB(5) | LSB |TTT |
	| Token | | | | | | | |		| Token | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |var|1 |Up| | ignore | value- | |		| CoAP. |var|1 |Up| | ignore | value- | |
	| option(3) | | | | | | sent | |		| option(3) | | | | | | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Up| "temperature" | equal | not-sent | |		| CoAP. |var|1 |Up| "temperature" | equal | not-sent | |
	| option(11) | | | | | | | |		| option(11) | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Up| "coap" | equal | not-sent | |		| CoAP. |var|1 |Up| "coap" | equal | not-sent | |
	| option(39) | | | | | | | |		| option(39) | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	Table 7: SCHC Rule between the Device and the Proxy. CoAP		Table 7: SCHC Rule between the Device and the Proxy. CoAP
	Option Numbers: 3 (Uri-Host), 11 (Uri-Path), 39 (Proxy-Scheme).		Option Numbers: 3 (Uri-Host), 11 (Uri-Path), 39 (Proxy-Scheme).
	Instead, the proxy and the Application Server share the SCHC Rule		Instead, the proxy and the Application Server share the SCHC Rule
	shown in Table 8, with RuleID 1.		shown in Table 8, with RuleID 1.
	+----------+		+----------+
	skipping to change at page 53, line 17 ¶		skipping to change at page 54, line 17 ¶
	+============+===+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| CoAP. |2 |1 |Bi| 1 | equal | not-sent | |		| CoAP. |2 |1 |Bi| 1 | equal | not-sent | |
	| Version | | | | | | | |		| Version | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |2 |1 |Up| 0 | equal | not-sent | |		| CoAP. |2 |1 |Up| 0 | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |2 |1 |Dw| [0, 2] | match- | mapping- |T |		| CoAP. |2 |1 |Dw| [0, 2] | match- | mapping- |T |
	| Type | | | | | mapping | sent | |		| Type | | | | | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Bi| 0b0001 | equal | not-sent | |		| CoAP. |var|1 |Bi| 0b0001 | equal | not-sent | |
	| TKL | | | | | | | |		| TKL | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Up| [1, 2, | match- | mapping- |CC |		| CoAP. |8 |1 |Up| [1, 2, | match- | mapping- |CC |
	| Code | | | | 3, 4] | mapping | sent | |		| Code | | | | 3, 4] | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Dw| [65, 68, | match- | mapping- |CC |		| CoAP. |8 |1 |Dw| [65, 68, | match- | mapping- |CC |
	| Code | | | | 69, 132] | mapping | sent | |		| Code | | | | 69, 132] | mapping | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |16 |1 |Bi| 0x0000 | MSB(12) | LSB |MMMM |		| CoAP. |16 |1 |Bi| 0x0000 | MSB(12) | LSB |MMMM |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |tkl|1 |Bi| 0x70 | MSB(5) | LSB |TTT |		| CoAP. |tkl|1 |Bi| 0x70 | MSB(5) | LSB |TTT |
	| Token | | | | | | | |		| Token | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |var|1 |Up| | ignore | value- | |		| CoAP. |var|1 |Up| | ignore | value- | |
	| option(3) | | | | | | sent | |		| option(3) | | | | | | sent | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Up| "temperature" | equal | not-sent | |		| CoAP. |var|1 |Up| "temperature" | equal | not-sent | |
	| option(11) | | | | | | | |		| option(11) | | | | | | | |
	+------------+---+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	Table 8: SCHC Rule between the Proxy and the Application Server.		Table 8: SCHC Rule between the Proxy and the Application Server.
	CoAP Option Numbers: 3 (Uri-Host), 11 (Uri-Path).		CoAP Option Numbers: 3 (Uri-Host), 11 (Uri-Path).
	First, the Device applies the Rule in Table 7 shared with the proxy		First, the Device applies the Rule in Table 7 shared with the proxy
	to the CoAP request in Figure 18. The result is the compressed CoAP		to the CoAP request in Figure 18. The result is the compressed CoAP
	request in Figure 20 that the Device sends to the proxy.		request in Figure 20 that the Device sends to the proxy.
	skipping to change at page 58, line 26 ¶		skipping to change at page 59, line 26 ¶
	The Device and the Application Server share the SCHC Rule shown in		The Device and the Application Server share the SCHC Rule shown in
	Table 9, with RuleID 2. The Device and the Application Server use		Table 9, with RuleID 2. The Device and the Application Server use
	this Rule to perform the Inner SCHC Compression/Decompression end-to-		this Rule to perform the Inner SCHC Compression/Decompression end-to-
	end.		end.
	+----------+		+----------+
	| RuleID 2 |		| RuleID 2 |
	+----------+		+----------+
	+============+==+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| FID |FL|FP|DI| TV | MO | CDA |Sent |		| FID |FL |FP|DI| TV | MO | CDA |Sent |
	| | | | | | | |[bits]|		| | | | | | | |[bits]|
	+============+==+==+==+===============+=========+==========+======+		+============+===+==+==+===============+=========+==========+======+
	| CoAP. |8 |1 |Up| [1, 2, | match- | mapping- |CC |		| CoAP. |8 |1 |Up| [1, 2, | match- | mapping- |CC |
	| Code | | | | 3, 4] | mapping | sent | |		| Code | | | | 3, 4] | mapping | sent | |
	+------------+--+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. |8 |1 |Dw| [65, 68, | match- | mapping- |CC |		| CoAP. |8 |1 |Dw| [65, 68, | match- | mapping- |CC |
	| Code | | | | 69, 132] | mapping | sent | |		| Code | | | | 69, 132] | mapping | sent | |
	+------------+--+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	| CoAP. | |1 |Up| "temperature" | equal | not-sent | |		| CoAP. |var|1 |Up| "temperature" | equal | not-sent | |
	| option(11) | | | | | | | |		| option(11) | | | | | | | |
	+------------+--+--+--+---------------+---------+----------+------+		+------------+---+--+--+---------------+---------+----------+------+
	Table 9: Inner SCHC Rule between the Device and the Application		Table 9: Inner SCHC Rule between the Device and the Application
	Server. CoAP Option Numbers: 11 (Uri-Path).		Server. CoAP Option Numbers: 11 (Uri-Path).
	The Device and the proxy share the SCHC Rule shown in Table 10, with		The Device and the proxy share the SCHC Rule shown in Table 10, with
	RuleID 3. The Device and the proxy use this Rule to perform the		RuleID 3. The Device and the proxy use this Rule to perform the
	Outer SCHC Compression/Decompression hop-by-hop on their		Outer SCHC Compression/Decompression hop-by-hop on their
	communication leg.		communication leg.
	+----------+		+----------+
	| RuleID 3 |		| RuleID 3 |
	+----------+		+----------+
	+============+=========+==+==+======+=========+==========+========+		+============+=========+==+==+======+=========+==========+========+
	skipping to change at page 59, line 17 ¶		skipping to change at page 60, line 17 ¶
	+============+=========+==+==+======+=========+==========+========+		+============+=========+==+==+======+=========+==========+========+
	| CoAP. | 2 |1 |Bi|1 | equal | not-sent | |		| CoAP. | 2 |1 |Bi|1 | equal | not-sent | |
	| Version | | | | | | | |		| Version | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 2 |1 |Up|0 | equal | not-sent | |		| CoAP. | 2 |1 |Up|0 | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 2 |1 |Dw|[0, 2]| match- | mapping- | T |		| CoAP. | 2 |1 |Dw|[0, 2]| match- | mapping- | T |
	| Type | | | | | mapping | sent | |		| Type | | | | | mapping | sent | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Bi|0b0001| equal | not-sent | |		| CoAP. | var |1 |Bi|0b0001| equal | not-sent | |
	| TKL | | | | | | | |		| TKL | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 8 |1 |Up|2 | equal | not-sent | |		| CoAP. | 8 |1 |Up|2 | equal | not-sent | |
	| Code | | | | | | | |		| Code | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 8 |1 |Dw|68 | equal | not-sent | |		| CoAP. | 8 |1 |Dw|68 | equal | not-sent | |
	| Code | | | | | | | |		| Code | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 16 |1 |Bi|0x0000| MSB(12) | LSB | MMMM |		| CoAP. | 16 |1 |Bi|0x0000| MSB(12) | LSB | MMMM |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | tkl |1 |Bi|0x80 | MSB(5) | LSB | TTT |		| CoAP. | tkl |1 |Bi|0x80 | MSB(5) | LSB | TTT |
	| Token | | | | | | | |		| Token | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | var |1 |Up| | ignore | value- | |		| CoAP. | var |1 |Up| | ignore | value- | |
	| option(3) | | | | | | sent | |		| option(3) | | | | | | sent | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Up|0x09 | equal | not-sent | |		| CoAP. | 8 |1 |Up|0x09 | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| flags | | | | | | | |		| flags | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Dw|b'' | equal | not-sent | |		| CoAP. | 8 |1 |Dw|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| flags | | | | | | | |		| flags | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | osc.piv |1 |Up|0x00 | MSB(4) | LSB | PPPP |		| CoAP. | osc.piv |1 |Up|0x00 | MSB(4) | LSB | PPPP |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| piv | | | | | | | |		| piv | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Dw|b'' | equal | not-sent | |		| CoAP. | osc.piv |1 |Dw|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| piv | | | | | | | |		| piv | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Bi|b'' | equal | not-sent | |		| CoAP. | var |1 |Bi|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| kid_ctx | | | | | | | |		| kid_ctx | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | var_bit |1 |Up|0x0000| MSB(12) | LSB | KKKK |		| CoAP. | var_bit |1 |Up|0x0000| MSB(12) | LSB | KKKK |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| kid | | | | | | | |		| kid | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Dw|b'' | equal | not-sent | |		| CoAP. | var |1 |Dw|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| kid | | | | | | | |		| kid | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Up|"coap"| equal | not-sent | |		| CoAP. | var |1 |Up|"coap"| equal | not-sent | |
	| option(39) | | | | | | | |		| option(39) | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	Table 10: Outer SCHC Rule between the Device and the Proxy.		Table 10: Outer SCHC Rule between the Device and the Proxy.
	CoAP Option Numbers: 3 (Uri-Host), 9 (OSCORE), 39 (Proxy-		CoAP Option Numbers: 3 (Uri-Host), 9 (OSCORE), 39 (Proxy-
	Scheme).		Scheme).
	The proxy and the Application Server share the SCHC Rule shown in		The proxy and the Application Server share the SCHC Rule shown in
	Table 11, with RuleID 4. The proxy and the Application Server use		Table 11, with RuleID 4. The proxy and the Application Server use
	this Rule to perform the Outer SCHC Compression/Decompression hop-by-		this Rule to perform the Outer SCHC Compression/Decompression hop-by-
	skipping to change at page 60, line 45 ¶		skipping to change at page 61, line 45 ¶
	+============+=========+==+==+======+=========+==========+========+		+============+=========+==+==+======+=========+==========+========+
	| CoAP. | 2 |1 |Bi|1 | equal | not-sent | |		| CoAP. | 2 |1 |Bi|1 | equal | not-sent | |
	| Version | | | | | | | |		| Version | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 2 |1 |Up|0 | equal | not-sent | |		| CoAP. | 2 |1 |Up|0 | equal | not-sent | |
	| Type | | | | | | | |		| Type | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 2 |1 |Dw|[0, 2]| match- | mapping- | T |		| CoAP. | 2 |1 |Dw|[0, 2]| match- | mapping- | T |
	| Type | | | | | mapping | sent | |		| Type | | | | | mapping | sent | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Bi|0b0001| equal | not-sent | |		| CoAP. | var |1 |Bi|0b0001| equal | not-sent | |
	| TKL | | | | | | | |		| TKL | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 8 |1 |Up|2 | equal | not-sent | |		| CoAP. | 8 |1 |Up|2 | equal | not-sent | |
	| Code | | | | | | | |		| Code | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 8 |1 |Dw|68 | equal | not-sent | |		| CoAP. | 8 |1 |Dw|68 | equal | not-sent | |
	| Code | | | | | | | |		| Code | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | 16 |1 |Bi|0x0000| MSB(12) | LSB | MMMM |		| CoAP. | 16 |1 |Bi|0x0000| MSB(12) | LSB | MMMM |
	| MID | | | | | | | |		| MID | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | tkl |1 |Bi|0x70 | MSB(5) | LSB | TTT |		| CoAP. | tkl |1 |Bi|0x70 | MSB(5) | LSB | TTT |
	| Token | | | | | | | |		| Token | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | var |1 |Up| | ignore | value- | |		| CoAP. | var |1 |Up| | ignore | value- | |
	| option(3) | | | | | | sent | |		| option(3) | | | | | | sent | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Up|0x09 | equal | not-sent | |		| CoAP. | 8 |1 |Up|0x09 | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| flags | | | | | | | |		| flags | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Dw|b'' | equal | not-sent | |		| CoAP. | 8 |1 |Dw|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| flags | | | | | | | |		| flags | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | osc.piv |1 |Up|0x00 | MSB(4) | LSB | PPPP |		| CoAP. | osc.piv |1 |Up|0x00 | MSB(4) | LSB | PPPP |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| piv | | | | | | | |		| piv | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Dw|b'' | equal | not-sent | |		| CoAP. | osc.piv |1 |Dw|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| piv | | | | | | | |		| piv | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Bi|b'' | equal | not-sent | |		| CoAP. | var |1 |Bi|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| kid_ctx | | | | | | | |		| kid_ctx | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | var_bit |1 |Up|0x0000| MSB(12) | LSB | KKKK |		| CoAP. | var_bit |1 |Up|0x0000| MSB(12) | LSB | KKKK |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| kid | | | | | | | |		| kid | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	| CoAP. | |1 |Dw|b'' | equal | not-sent | |		| CoAP. | var |1 |Dw|b'' | equal | not-sent | |
	| option(9). | | | | | | | |		| option(9). | | | | | | | |
	| kid | | | | | | | |		| kid | | | | | | | |
	+------------+---------+--+--+------+---------+----------+--------+		+------------+---------+--+--+------+---------+----------+--------+
	Table 11: Outer SCHC Rule between the Proxy and the Application		Table 11: Outer SCHC Rule between the Proxy and the Application
	Server. CoAP Option Numbers: 3 (Uri-Host), 9 (OSCORE).		Server. CoAP Option Numbers: 3 (Uri-Host), 9 (OSCORE).
	When the Device applies the Rule in Table 9 shared with the		When the Device applies the Rule in Table 9 shared with the
	Application Server to the CoAP request in Figure 18, this results in		Application Server to the CoAP request in Figure 18, this results in
	the Compressed Plaintext shown in Figure 26.		the Compressed Plaintext shown in Figure 26.
	skipping to change at page 76, line 51 ¶		skipping to change at page 77, line 51 ¶
	field but rather the length of the Compression Residue that is being		field but rather the length of the Compression Residue that is being
	transmitted. If a corrupted packet arrives at the decompressor with		transmitted. If a corrupted packet arrives at the decompressor with
	a longer or shorter length than that of the original compressed		a longer or shorter length than that of the original compressed
	representation, the SCHC decompression procedures will detect an		representation, the SCHC decompression procedures will detect an
	error and drop the packet.		error and drop the packet.
	SCHC header compression Rules MUST remain tightly coupled between the		SCHC header compression Rules MUST remain tightly coupled between the
	compressor and the decompressor. If the compression Rules get out of		compressor and the decompressor. If the compression Rules get out of
	sync, a Compression Residue might be decompressed differently at the		sync, a Compression Residue might be decompressed differently at the
	receiver, thus yielding a result different than the initial message		receiver, thus yielding a result different than the initial message
	submitted to compression procedures. Accordingly, any time the		submitted to compression procedures. Accordingly, any time the Rules
	context Rules are updated on an OSCORE endpoint, that endpoint MUST		within the SCHC Context are updated on an OSCORE endpoint, that
	trigger an update of the OSCORE key material, e.g., by running the		endpoint MUST trigger an update of the OSCORE key material, e.g., by
	lightweight key update protocol KUDOS		running the lightweight key update protocol KUDOS
	[I-D.ietf-core-oscore-key-update]. Similar procedures may be		[I-D.ietf-core-oscore-key-update]. Similar procedures may be
	appropriate to signal Rule updates when other message-protection		appropriate to signal Rule updates when other message-protection
	mechanisms are in use.		mechanisms are in use.
	12.1. YANG Module
	The YANG data model defined in Appendix A extends the ietf-schc
	module defined in [RFC9363].
	Therefore, all the security considerations compiled in Section 8 of
	[RFC9363] also apply to the resulting extended YANG data model.
	13. IANA Considerations		13. IANA Considerations
	This document has the following actions for IANA.		This document has the following actions for IANA.
	Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"		13.1. Static Context Header Compression (SCHC) Parameters
	with the RFC number of this specification and delete this paragraph.
	13.1. IETF XML
	IANA is asked to register the following entry in the "IETF XML"
	registry [RFC3688].
	* URI: urn:ietf:params:xml:ns:yang:ietf-schc-coap
	* Registrant Contact: The IESG.
	* XML: N/A; the requested URI is an XML namespace.
	13.2. YANG Module Names
	IANA is asked to register the following entry in the "YANG Module
	Names" registry [RFC6020][RFC8407] within the "YANG Parameters"
	registry group.
	* Name: ietf-schc-coap
	* Namespace: urn:ietf:params:xml:ns:yang:ietf-schc-coap
	* Prefix: schc-coap
	* Reference: [RFC-XXXX]
	13.3. Static Context Header Compression (SCHC) Parameters
	IANA is asked to establish the "Static Context Header Compression		IANA is asked to establish the "Static Context Header Compression
	(SCHC) Parameters" registry group.		(SCHC) Parameters" registry group.
	The registry group has been initially populated with the registry		The registry group has been initially populated with the registry
	established as per Section 13.4.		established as per Section 13.2.
	13.4. SCHC Compression of CoAP Fields		13.2. SCHC Compression of CoAP Fields
	IANA is asked to establish the "SCHC Compression of CoAP Fields"		IANA is asked to establish the "SCHC Compression of CoAP Fields"
	registry within the "Static Context Header Compression (SCHC)		registry within the "Static Context Header Compression (SCHC)
	Parameters" registry group established as per Section 13.3.		Parameters" registry group established as per Section 13.1.
	As registration policy, the registry uses "Specification Required"		As registration policy, the registry uses "Specification Required"
	per Section 4.6 of [RFC8126]. Expert Review guidelines are provided		per Section 4.6 of [RFC8126]. Expert Review guidelines are provided
	in Section 13.5.		in Section 13.3.
	13.4.1. Intended Use		13.2.1. Intended Use
	The objective of this registry is to collect a list of CoAP fields		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		and subfields, for which it has been defined how to perform SCHC
	compression.		compression.
	Such a definition does not necessarily have to be in the same		Such a definition does not necessarily have to be in the same
	documentation that defines the CoAP fields and subfields in question.		documentation that defines the CoAP fields and subfields in question.
	While that can be the case, it is also possible to provide that		While that can be the case, it is also possible to provide that
	definition in a separate specification.		definition in a separate specification.
	skipping to change at page 79, line 9 ¶		skipping to change at page 79, line 19 ¶
	strongly encouraged to update its list of references. The update		strongly encouraged to update its list of references. The update
	is intended to add references to the specification that provides		is intended to add references to the specification that provides
	the new or updated SCHC compression of the CoAP field, as well as		the new or updated SCHC compression of the CoAP field, as well as
	to any documentation that updates the definition of the CoAP field		to any documentation that updates the definition of the CoAP field
	itself.		itself.
	If the defined SCHC compression considers the CoAP field as composed		If the defined SCHC compression considers the CoAP field as composed
	of subfields, it is strongly encouraged that the same as above is		of subfields, it is strongly encouraged that the same as above is
	also performed for each subfield and the associated registry entry.		also performed for each subfield and the associated registry entry.
	13.4.2. Structure of Entries		13.2.2. Structure of Entries
	The columns of this registry are:		The columns of this registry are:
	* Field: a unique identifier of the CoAP field or subfield		* Field: a unique identifier of the CoAP field or subfield
	associated with this entry. This identifier is used as FID in a		associated with this entry. This identifier is used as FID in a
	Field Descriptor of a SCHC compression Rule for compressing/		Field Descriptor of a SCHC compression Rule for compressing/
	decompressing CoAP messages.		decompressing CoAP messages.
	This identifier has two possible formats:		This identifier has two possible formats:
	skipping to change at page 79, line 31 ¶		skipping to change at page 79, line 41 ¶
	- "CoAP.X.Y", where X is the name of the CoAP field and Y is the		- "CoAP.X.Y", where X is the name of the CoAP field and Y is the
	name of a subfield of X.		name of a subfield of X.
	If the CoAP field in question is specifically a CoAP option, then		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		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		CoAP option. The value N is taken from the "Number" column of the
	corresponding entry in the "CoAP Option Numbers" IANA registry		corresponding entry in the "CoAP Option Numbers" IANA registry
	[CoAP.Option.Numbers].		[CoAP.Option.Numbers].
	Within the YANG data model originally specified in Section 6 of
	[RFC9363], this identifier must have a corresponding item or set
	of items for the CoAP field or subfield associated with this
	entry.
	* Description: a short description of the CoAP field or subfield		* Description: a short description of the CoAP field or subfield
	associated with this entry, together with public references to the		associated with this entry, together with public references to the
	resources that define it.		resources that define it.
	* Reference: public references to the resources that define how a		* Reference: public references to the resources that define how a
	SCHC compression Rule works for the CoAP field or subfield		SCHC compression Rule works for the CoAP field or subfield
	associated with this entry.		associated with this entry.
	In order to make the registry easier to parse, its entries are		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		ordered based on the value of the "Field" column and according to the
	skipping to change at page 80, line 21 ¶		skipping to change at page 80, line 24 ¶
	CoAP message.		CoAP message.
	* Given an entry "CoAP.X" for the field X, any entry "CoAP.X.Y" for		* 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 subfield Y of X appears after the entry "CoAP.X" and before
	the entry for any other field.		the entry for any other field.
	This registry has been initially populated with the values in		This registry has been initially populated with the values in
	Table 12. The "Reference" column for all these entries refers to		Table 12. The "Reference" column for all these entries refers to
	this document.		this document.
	13.5. Expert Review Instructions		13.3. Expert Review Instructions
	The IANA registry established in this document is defined as		The IANA registry established in this document is defined as
	"Specification Required". This section gives some general guidelines		"Specification Required". This section gives some general guidelines
	for what the experts should be looking for, but they are being		for what the experts should be looking for, but they are being
	designated as experts for a reason so they should be given		designated as experts for a reason so they should be given
	substantial latitude.		substantial latitude.
	Expert reviewers should take into consideration the following points:		Expert reviewers should take into consideration the following points:
	* Point squatting should be discouraged. Reviewers are encouraged		* Point squatting should be discouraged. Reviewers are encouraged
	to get sufficient information for registration requests to ensure		to get sufficient information for registration requests to ensure
	that the usage is not going to duplicate one that is already		that the usage is not going to duplicate one that is already
	registered and that the point is likely to be used in deployments.		registered and that the point is likely to be used in deployments.
	Specifically, for every CoAP field, only one corresponding		Specifically, for every CoAP field, only one corresponding
	registry entry is allowed. Also, for every CoAP subfield, only		registry entry is allowed. Also, for every CoAP subfield, only
	one corresponding registry entry is allowed.		one corresponding registry entry is allowed.
	* For a new registry entry, it has to be clear where that entry has		* For a new registry entry, it has to be clear where that entry has
	to be positioned within the registry, according to the criteria		to be positioned within the registry, according to the criteria
	compiled in Section 13.4.2.		compiled in Section 13.2.2.
	* Consistent with the "Specification Required" registration policy,		* Consistent with the "Specification Required" registration policy,
	specifications should exist, but early assignment before a		specifications should exist, but early assignment before a
	specification is available is considered to be permissible. When		specification is available is considered to be permissible. When
	specifications are not provided, the description provided needs to		specifications are not provided, the description provided needs to
	have sufficient information to identify what the point is being		have sufficient information to identify what the point is being
	used for.		used for.
	If the expert becomes aware of a definition for SCHC compression of		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		CoAP fields and subfields that is deployed and in use, the expert may
	skipping to change at page 81, line 40 ¶		skipping to change at page 81, line 40 ¶
	RESTful Environments (Group OSCORE)", Work in Progress,		RESTful Environments (Group OSCORE)", Work in Progress,
	Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23		Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23
	December 2025, <https://datatracker.ietf.org/doc/html/		December 2025, <https://datatracker.ietf.org/doc/html/
	draft-ietf-core-oscore-groupcomm-28>.		draft-ietf-core-oscore-groupcomm-28>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/rfc/rfc3688>.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated		[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,		Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<https://www.rfc-editor.org/rfc/rfc5116>.		<https://www.rfc-editor.org/rfc/rfc5116>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/rfc/rfc6020>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/rfc/rfc7252>.		<https://www.rfc-editor.org/rfc/rfc7252>.
	[RFC7641] Hartke, K., "Observing Resources in the Constrained		[RFC7641] Hartke, K., "Observing Resources in the Constrained
	Application Protocol (CoAP)", RFC 7641,		Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,		DOI 10.17487/RFC7641, September 2015,
	<https://www.rfc-editor.org/rfc/rfc7641>.		<https://www.rfc-editor.org/rfc/rfc7641>.
	skipping to change at page 82, line 40 ¶		skipping to change at page 82, line 30 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
	Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained		Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
	Application Protocol) over TCP, TLS, and WebSockets",		Application Protocol) over TCP, TLS, and WebSockets",
	RFC 8323, DOI 10.17487/RFC8323, February 2018,		RFC 8323, DOI 10.17487/RFC8323, February 2018,
	<https://www.rfc-editor.org/rfc/rfc8323>.		<https://www.rfc-editor.org/rfc/rfc8323>.
	[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
	Documents Containing YANG Data Models", RFC 8407,
	DOI 10.17487/RFC8407, October 2018,
	<https://www.rfc-editor.org/rfc/rfc8407>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/rfc/rfc8613>.		<https://www.rfc-editor.org/rfc/rfc8613>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
	<https://www.rfc-editor.org/rfc/rfc8724>.		<https://www.rfc-editor.org/rfc/rfc8724>.
	skipping to change at page 83, line 37 ¶		skipping to change at page 83, line 21 ¶
	"Constrained Application Protocol (CoAP): Echo, Request-		"Constrained Application Protocol (CoAP): Echo, Request-
	Tag, and Token Processing", RFC 9175,		Tag, and Token Processing", RFC 9175,
	DOI 10.17487/RFC9175, February 2022,		DOI 10.17487/RFC9175, February 2022,
	<https://www.rfc-editor.org/rfc/rfc9175>.		<https://www.rfc-editor.org/rfc/rfc9175>.
	[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application		[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
	Protocol (CoAP) Block-Wise Transfer Options Supporting		Protocol (CoAP) Block-Wise Transfer Options Supporting
	Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,		Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
	March 2022, <https://www.rfc-editor.org/rfc/rfc9177>.		March 2022, <https://www.rfc-editor.org/rfc/rfc9177>.
	[RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static
	Context Header Compression (SCHC)", RFC 9363,
	DOI 10.17487/RFC9363, March 2023,
	<https://www.rfc-editor.org/rfc/rfc9363>.
	[RFC9668] Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and		[RFC9668] Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
	G. Selander, "Using Ephemeral Diffie-Hellman Over COSE		G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
	(EDHOC) with the Constrained Application Protocol (CoAP)		(EDHOC) with the Constrained Application Protocol (CoAP)
	and Object Security for Constrained RESTful Environments		and Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,		(OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
	<https://www.rfc-editor.org/rfc/rfc9668>.		<https://www.rfc-editor.org/rfc/rfc9668>.
	14.2. Informative References		14.2. Informative References
	[I-D.ietf-core-groupcomm-bis]		[I-D.ietf-core-groupcomm-bis]
	Dijk, E. and M. Tiloca, "Group Communication for the		Dijk, E. and M. Tiloca, "Group Communication for the
	Constrained Application Protocol (CoAP)", Work in		Constrained Application Protocol (CoAP)", Work in
	Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-		Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
	18, 10 February 2026,		18, 10 February 2026,
	<https://datatracker.ietf.org/doc/html/draft-ietf-core-		<https://datatracker.ietf.org/doc/html/draft-ietf-core-
	groupcomm-bis-18>.		groupcomm-bis-18>.
	[I-D.ietf-core-oscore-key-update]		[I-D.ietf-core-oscore-key-update]
	Höglund, R. and M. Tiloca, "Key Update for OSCORE		Höglund, R. and M. Tiloca, "Key Update for OSCORE
	(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-		(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
	core-oscore-key-update-13, 2 March 2026,		core-oscore-key-update-14, 6 July 2026,
	<https://datatracker.ietf.org/doc/html/draft-ietf-core-		<https://datatracker.ietf.org/doc/html/draft-ietf-core-
	oscore-key-update-13>.		oscore-key-update-14>.
			[I-D.ietf-schc-architecture]
			Pelov, A., Thubert, P., Minaburo, A., Lampin, Q., and M.
			Dumay, "Static Context Header Compression (SCHC)
			Architecture", Work in Progress, Internet-Draft, draft-
			ietf-schc-architecture-06, 6 July 2026,
			<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
			architecture-06>.
	[I-D.ietf-schc-universal-option]		[I-D.ietf-schc-universal-option]
	Lampin, Q., Minaburo, A., Tiloca, M., and L. Toutain,		Lampin, Q., Minaburo, A., Tiloca, M., and L. Toutain,
	"Options representation in SCHC YANG Data Models", Work in		"Options representation in SCHC YANG Data Models", Work in
	Progress, Internet-Draft, draft-ietf-schc-universal-		Progress, Internet-Draft, draft-ietf-schc-universal-
	option-01, 17 October 2025,		option-01, 17 October 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-schc-		<https://datatracker.ietf.org/doc/html/draft-ietf-schc-
	universal-option-01>.		universal-option-01>.
	[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static		[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
	skipping to change at page 84, line 44 ¶		skipping to change at page 84, line 29 ¶
	[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The		[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,		1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
	<https://www.rfc-editor.org/rfc/rfc9147>.		<https://www.rfc-editor.org/rfc/rfc9147>.
	[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,		[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
	"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,		"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
	DOI 10.17487/RFC9528, March 2024,		DOI 10.17487/RFC9528, March 2024,
	<https://www.rfc-editor.org/rfc/rfc9528>.		<https://www.rfc-editor.org/rfc/rfc9528>.
	Appendix A. YANG Data Model		Appendix A. Document Updates
	This appendix defines the ietf-schc-coap module, which extends the
	ietf-schc module defined in [RFC9363] to include the new CoAP options
	as defined in the present document.
	Note to RFC Editor: In the YANG data model below, please replace all
	occurrences of "XXXX" with the RFC number of this specification and
	delete this paragraph.
	<CODE BEGINS> file "ietf-schc-coap@2026-06-30.yang"
	module ietf-schc-coap {
	yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-schc-coap";
	prefix schc-coap;
	import ietf-schc {
	prefix schc;
	}
	organization
	"IETF SCHC (Static Context Header Compression) Working Group";
	contact
	"WG Web: https://datatracker.ietf.org/wg/schc
	WG List: SCHC <mailto:schc@ietf.org>
	Editor: Marco Tiloca
	<mailto:marco.tiloca@ri.se>";
	description
	"This module extends the ietf-schc module defined in RFC 9363 to
	include the new CoAP options as defined in RFC XXXX.
	Copyright (c) 2026 IETF Trust and the persons identified
	as authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with
	or without modification, is permitted pursuant to, and
	subject to the license terms contained in, the Revised
	BSD License set forth in Section 4.c of the IETF Trust's
	Legal Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info).
	All revisions of IETF and IANA published modules can be found
	at the YANG Parameters registry group
	(https://www.iana.org/assignments/yang-parameters).
	This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";
	revision 2026-06-30 {
	description
	"New CoAP extensions and extended OSCORE fields.";
	reference
	"RFC XXXX Static Context Header Compression (SCHC) for the
	Constrained Application Protocol (CoAP) (see
	Sections 5 and 6)";
	}
	// Field ID
	identity fid-coap-option-proxy-cri {
	base "schc:fid-coap-option";
	description
	"Proxy-Cri option.";
	reference
	"RFC 9988 Constrained Resource Identifiers";
	}
	identity fid-coap-option-proxy-scheme-number {
	base "schc:fid-coap-option";
	description
	"Proxy-Scheme-Number option.";
	reference
	"RFC 9988 Constrained Resource Identifiers";
	}
	identity fid-coap-option-hop-limit {
	base "schc:fid-coap-option";
	description
	"Hop Limit option to avoid infinite forwarding loops.";
	reference
	"RFC 8768 Constrained Application Protocol (CoAP)
	Hop-Limit Option";
	}
	identity fid-coap-option-echo {
	base "schc:fid-coap-option";
	description
	"Echo option.";
	reference
	"RFC 9175 Constrained Application Protocol (CoAP):
	Echo, Request-Tag, and Token Processing";
	}
	identity fid-coap-option-request-tag {
	base "schc:fid-coap-option";
	description
	"Request-Tag option.";
	reference
	"RFC 9175 Constrained Application Protocol (CoAP):
	Echo, Request-Tag, and Token Processing";
	}
	identity fid-coap-option-q-block1 {		This section is to be removed before publishing as an RFC.
	base "schc:fid-coap-option";
	description
	"Q-Block1 option.";
	reference
	"RFC 9177 Constrained Application Protocol (CoAP)
	Block-Wise Transfer Options Supporting
	Robust Transmission";
	}
	identity fid-coap-option-q-block2 {		A.1. Version -09 to -10
	base "schc:fid-coap-option";
	description
	"Q-Block2 option.";
	reference
	"RFC 9177 Constrained Application Protocol (CoAP)
	Block-Wise Transfer Options Supporting
	Robust Transmission";
	}
	identity fid-coap-option-edhoc {		* Terminology aligned with that in draft-ietf-schc-architecture.
	base "schc:fid-coap-option";
	description
	"EDHOC option.";
	reference
	"RFC 9668 Using Ephemeral Diffie-Hellman Over COSE (EDHOC)
	with the Constrained Application Protocol (CoAP)
	and Object Security for Constrained RESTful
	Environments (OSCORE)";
	}
	// Function Length		* FL defined as non-empty.
	identity fl-variable-bit {		* Fixed example rules to have FL not empty.
	base "schc:fl-base-type";
	description
	"Residue length in bits is sent as defined for CoAP.";
	reference
	"RFC XXXX Static Context Header Compression (SCHC) for the
	Constrained Application Protocol (CoAP) (see
	Section 3.1)";
	}
	identity fl-oscore-piv-length {		* Clarified semantics of the osc.piv function.
	base "schc:fl-base-type";
	description
	"Size in bytes of the OSCORE Partial IV, equal to n.";
	reference
	"RFC XXXX Static Context Header Compression (SCHC) for the
	Constrained Application Protocol (CoAP) (see
	Section 6.4)";
	}
	}
	<CODE ENDS>
	Figure 36: SCHC CoAP Extension YANG Data Model.		* Removed the YANG module ietf-schc-coap and text related to it.
	Appendix B. Document Updates		* Removed text related to the YANG module ietf-schc defined in RFC
			9363.
	This section is to be removed before publishing as an RFC.		* Removed unnecessary references as not needed anymore: RFC 9363,
			RFC 3688, RFC 6020, RFC8407.
	B.1. Version -08 to -09		A.2. Version -08 to -09
	* Clarified overview of changes from RFC 8824 in Section 1, as to		* Clarified overview of changes from RFC 8824 in Section 1, as to
	the CoAP options ETag, If-Match, and If-None-Match.		the CoAP options ETag, If-Match, and If-None-Match.
	* Clarified use of functions "var" and "var_X" in the FL of the		* Clarified use of functions "var" and "var_X" in the FL of the
	Field Descriptor.		Field Descriptor.
	* Fixed occurrence of SCHC subfield name from kid_context to		* Fixed occurrence of SCHC subfield name from kid_context to
	kid_ctx.		kid_ctx.
	* A Field Descriptor can pertain to multiple adjacent instances of		* A Field Descriptor can pertain to multiple adjacent occurrences of
	the same CoAP option grouped together.		the same CoAP option grouped together.
	* Handling a variable number of path segments and query parameters		* Handling a variable number of path segments and query parameters
	requires different SCHC Rules.		requires different SCHC Rules.
	* Final text about updated reference in the YANG data model from RFC		* Final text about updated reference in the YANG data model from RFC
	9363.		9363.
	* YANG data model:		* YANG data model:
	- Updated legal boilerplate and other metadata.		- Updated legal boilerplate and other metadata.
	- Consistent use of placeholders for RFC numbers.		- Consistent use of placeholders for RFC numbers.
	- Added the identity fl-variable-bit.		- Added the identity fl-variable-bit.
	* Editorial fixes and improvements.		* Editorial fixes and improvements.
	B.2. Version -07 to -08		A.3. Version -07 to -08
	* Updated editor's notes about the YANG data model from [RFC9363].		* Updated editor's notes about the YANG data model from RFC 9363.
	* Shortened one too-long line in the YANG data model.		* Shortened one too-long line in the YANG data model.
	* Editorial update of reference entries.		* Editorial update of reference entries.
	B.3. Version -06 to -07		A.4. Version -06 to -07
	* Removed content about the updates to the OSCORE Option expected		* Removed content about the updates to the OSCORE Option expected
	from draft-ietf-core-oscore-key-update.		from draft-ietf-core-oscore-key-update.
	* Requested creation of new IANA registry group.		* Requested creation of new IANA registry group.
	* Explicit criteria for ordering entries in the new IANA registry.		* Explicit criteria for ordering entries in the new IANA registry.
	* Editorial fixes in the initial list of CoAP fields to register.		* Editorial fixes in the initial list of CoAP fields to register.
	B.4. Version -05 to -06		A.5. Version -05 to -06
	* Generalized the Token Length field, the Token field, and the "tkl"		* Generalized the Token Length field, the Token field, and the "tkl"
	function to comply with RFC 8974.		function to comply with RFC 8974.
	* Clarified use of the FL for variable-length fields.		* Clarified use of the FL for variable-length fields.
	* Explicit definition and use of "var" in the FL of a Field		* Explicit definition and use of "var" in the FL of a Field
	Descriptor.		Descriptor.
	* Consistent use of "var" in the examples of Rules.		* Consistent use of "var" in the examples of Rules.
	* More robust reference to the YANG data model of RFC 9363.		* More robust reference to the YANG data model of RFC 9363.
	* Editorial fixes in the examples.		* Editorial fixes in the examples.
	* Minor clarifications and editorial improvements.		* Minor clarifications and editorial improvements.
	B.5. Version -04 to -05		A.6. Version -04 to -05
	* Compression of CoAP options:		* Compression of CoAP options:
	- Clarified definition of Field Descriptors in SCHC Rules.		- Clarified definition of Field Descriptors in SCHC Rules.
	- Description of Option Value as possibly composed of sub-fields.		- Description of Option Value as possibly composed of sub-fields.
	- Both the syntactic approach and the semantics approach are		- Both the syntactic approach and the semantics approach are
	possible (see draft-ietf-schc-universal-option).		possible (see draft-ietf-schc-universal-option).
	skipping to change at page 90, line 14 ¶		skipping to change at page 87, line 5 ¶
	* Clarified OSCORE compression when using the group mode of Group		* Clarified OSCORE compression when using the group mode of Group
	OSCORE.		OSCORE.
	* Updated YANG data model.		* Updated YANG data model.
	* Updated author's contact information.		* Updated author's contact information.
	* Fixes and editorial improvements.		* Fixes and editorial improvements.
	B.6. Version -03 to -04		A.7. Version -03 to -04
	* Clarified the rationale for using the "tkl" function.		* Clarified the rationale for using the "tkl" function.
	* Added the "osc.piv" function to determine the length of the OSCORE		* Added the "osc.piv" function to determine the length of the OSCORE
	piv field.		piv field.
	* Consistent formulation of "tkl", "osc.x.m", and "osc.y.w".		* Consistent formulation of "tkl", "osc.x.m", and "osc.y.w".
	* Explicitly stated that Field Descriptors have to be ordered in a		* Explicitly stated that Field Descriptors have to be ordered in a
	determistic way.		determistic way.
	skipping to change at page 90, line 38 ¶		skipping to change at page 87, line 29 ¶
	* Fixed order of OSCORE-related Field Descriptors in example Rules.		* Fixed order of OSCORE-related Field Descriptors in example Rules.
	* Use "bit" instead of "b" as symbol for bit (per ISO/IEC 80000-13).		* Use "bit" instead of "b" as symbol for bit (per ISO/IEC 80000-13).
	* Made YANG extractable.		* Made YANG extractable.
	* Updated references.		* Updated references.
	* Fixes and editorial improvements.		* Fixes and editorial improvements.
	B.7. Version -02 to -03		A.8. Version -02 to -03
	* Consistent representation of "CoAP Version" 1 in example Rules.		* Consistent representation of "CoAP Version" 1 in example Rules.
	* Split the compression of Token Length and Token into two sections.		* Split the compression of Token Length and Token into two sections.
	* Disambiguated example of Rule on eliding a Uri-Path option.		* Disambiguated example of Rule on eliding a Uri-Path option.
	* Fixed compression examples with OSCORE.		* Fixed compression examples with OSCORE.
	* Inherited security considerations on the YANG module from RFC		* Inherited security considerations on the YANG module from RFC
	9363.		9363.
	* Fixes and editorial improvements.		* Fixes and editorial improvements.
	B.8. Version -01 to -02		A.9. Version -01 to -02
	* Added compression for the CoAP options Proxy-Cri and Proxy-Scheme-		* Added compression for the CoAP options Proxy-Cri and Proxy-Scheme-
	Number.		Number.
	* Defined new IANA registry "SCHC Compression of CoAP Fields".		* Defined new IANA registry "SCHC Compression of CoAP Fields".
	* Updated the YANG data model.		* Updated the YANG data model.
	* Fixes and editorial improvements.		* Fixes and editorial improvements.
	B.9. Version -00 to -01		A.10. Version -00 to -01
	* Fixed an example, as per the erratum with Errata ID 7623.		* Fixed an example, as per the erratum with Errata ID 7623.
	* Clarified building of Field Descriptor for CoAP options.		* Clarified building of Field Descriptor for CoAP options.
	* Clarified what SCHC compression considers 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 ETag and If-Match CoAP option.
	* Revised SCHC compression of the If-None-Match CoAP option.		* Revised SCHC compression of the If-None-Match CoAP option.
	* Added YANG data model for the YANG module.		* Added YANG data model for the YANG module.
	* Added IANA considerations.		* Added IANA considerations.
	* Fixes and editorial improvements.		* Fixes and editorial improvements.
	Acknowledgments		Acknowledgments
	The authors sincerely thank Christian Amsüss, Carles Gomez		The authors sincerely thank Christian Amsüss, Dhruv Dhody, Carles
	Montenegro, Rikard Höglund, Quentin Lampin, Alexander Pelov, John		Gomez Montenegro, Rikard Höglund, Quentin Lampin, Alexander Pelov,
	Preuß Mattsson, Göran Selander, Pascal Thubert, and Éric Vyncke for		John Preuß Mattsson, Göran Selander, Pascal Thubert, and Éric Vyncke
	their comments and feedback.		for their comments and feedback.
	This work was supported by the Sweden's Innovation Agency VINNOVA		This work was supported by the Sweden's Innovation Agency VINNOVA
	within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020		within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020
	projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant		projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant
	agreement 101020259).		agreement 101020259).
	Authors' Addresses		Authors' Addresses
	Marco Tiloca		Marco Tiloca
	RISE AB		RISE AB
End of changes. 108 change blocks.
	496 lines changed or deleted		396 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff