SCHC Working Group L. Corneo Internet-Draft E. Ramos Intended status: Standards Track J. Jimenez Expires: 4 January 2027 Ericsson 3 July 2026 SCHC Payload Compression for Structured Formats draft-corneo-schc-compress-payload-02 Abstract This document describes techniques to adapt the SCHC framework (RFC8724), used for header compression, to also compress and decompress payload of specific protocols. To this end, this document defines a new matching operator, equal-template, to check equality of field values with respect to a user-defined template, and a payload keyword to be used as Field IDentifier (FID) to signal the presence of payload to be compressed or decompressed. Additionally, this document defines a set of template functions and variables to optimize user-defined templates, which can be extended through the IANA registry defined herein. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-corneo-schc-compress-payload/. Discussion of this document takes place on the schc Working Group mailing list (mailto:schc@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/schc/. Subscribe at https://www.ietf.org/mailman/listinfo/schc/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Corneo, et al. Expires 4 January 2027 [Page 1] Internet-Draft SCHC-payload July 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . 3 2. A Matching Operator Providing Equality over Templates . . . . 4 2.1. Matching Procedure . . . . . . . . . . . . . . . . . . . 4 2.2. Residue Encoding . . . . . . . . . . . . . . . . . . . . 4 2.3. Type Handling . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Match Failure . . . . . . . . . . . . . . . . . . . . . . 5 3. Template Variables and Functions . . . . . . . . . . . . . . 5 3.1. Positional Template Variable . . . . . . . . . . . . . . 5 3.2. Repeat Template Function . . . . . . . . . . . . . . . . 6 3.2.1. Repetition Count . . . . . . . . . . . . . . . . . . 6 3.2.2. Positional Variable Scope . . . . . . . . . . . . . . 7 3.2.3. Optimization Example . . . . . . . . . . . . . . . . 7 4. A Keyword for Structured Data Payload Compression . . . . . . 8 5. An Example of Structured Data Payload with Template . . . . . 8 6. An Example of Structured Data Payload without Template . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8.1. SCHC Payload Compression Template Functions and Variables . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Corneo, et al. Expires 4 January 2027 [Page 2] Internet-Draft SCHC-payload July 2026 Appendix B. Preliminary ABNF for Template Syntax . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The main purpose of this document is to extend the SCHC framework [RFC8724] to compress and decompress structured data payloads, e.g., JSON [RFC8259], reusing the same compression and decompression machinery originally designed for protocol headers. This document defines the equal-template Matching Operator (MO), which enables a SCHC compressor to match a field value against a user-defined template and extract only the variable parts as compression residue. Templates may include positional variables and functions to address common patterns in structured data. Additionally, this document defines the payload keyword for use in the Field IDentifier (FID) to signal that payload compression is being performed. The keyword can be used with a template, where the entire payload structure is captured in the Target Value (TV), or without a template, where individual structured data fields are specified in separate rule entries. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here. 1.1.1. Glossary * Template-based compression: Payload compression utilizing a pre- shared model that only requires the values that are changing in the payload. * Template variable: A template variable can be used as a placeholder for variable fields in a template definition. Template variables can carry semantics and other information, e.g., the position and size of a field value in the compression residue (see Section 3.1). * Template function: A template function can be used to perform actions on a template definition, e.g., compress repeated structures in the payload (see Section 3.2). Corneo, et al. Expires 4 January 2027 [Page 3] Internet-Draft SCHC-payload July 2026 * Payload keyword: The keyword payload used in the FID to signal that payload compression is being performed. 2. A Matching Operator Providing Equality over Templates This section introduces the equal-template Matching Operator (MO), which evaluates equality between a field value and a provided template specified in the Target Value (TV). 2.1. Matching Procedure The equal-template MO MUST perform the following steps: 1. Parse the template specified in the TV to identify the fixed portions and the positions of template variables (see Section 3.1) and functions (see Section 3.2). 2. Compare the fixed portions of the template against the corresponding portions of the field value. The comparison MUST be performed as a byte-wise exact match on the textual representation of the field value. 3. Extract the substrings of the field value that correspond to each template variable. Each extracted substring represents a value to be included in the compression residue. 4. If all fixed portions match, the MO evaluates to true and the extracted values are passed to the Compression/Decompression Action (CDA). If any fixed portion does not match, the MO evaluates to false and the rule MUST NOT be applied. 2.2. Residue Encoding When the equal-template MO evaluates to true, the extracted values MUST be encoded in the compression residue in the order determined by their positional identifiers (i.e., $1 before $2, and so on). Each positional template variable MUST specify the length of the value it captures, expressed in bytes, using the notation $n:length. For example, $1:10 indicates that the first positional variable captures a value occupying exactly 10 bytes in the residue. If the actual extracted value is shorter than the declared length, it MUST be right-padded with zeros to fill the declared length. Upon decompression, the decompressor MUST strip trailing zero bytes from each extracted value before reconstructing the payload. This is safe because the equal-template MO operates on textual representations where the null byte (0x00) is not a valid character. Corneo, et al. Expires 4 January 2027 [Page 4] Internet-Draft SCHC-payload July 2026 The decompressor uses this fixed length to unambiguously parse the residue. This approach keeps the length information co-located with the template variable it describes and does not require changes to the SCHC rule structure defined in [RFC8724]. Alternatively, the Field Length (FL) field of the rule could be extended to carry a list of lengths, one per positional variable. Such an approach would require additional standardization effort and is left for future discussion within the Working Group. 2.3. Type Handling The equal-template MO operates on the textual (serialized) representation of the field value. Template variables capture substrings as-is, preserving the original serialization. For example, given the template {"value": $1:4} and the field value {"value": -11}, the extracted value for $1 is the string -11 right- padded with one zero byte to fill 4 bytes. Type interpretation is left to the application layer after decompression. 2.4. Match Failure If the equal-template MO evaluates to false for a given rule, the SCHC compressor MUST proceed to evaluate the next rule in the rule set, as specified in Section 7.2 of [RFC8724]. If no rule matches, the packet MUST be sent uncompressed. 3. Template Variables and Functions This section specifies one variable and one function, to be used in templates, that address common patterns in structured data. Template variables and functions are identified through a special character, hereby defined as the dollar sign $. It is possible to define additional template variables and functions in the IANA registry defined in Section 8.1. 3.1. Positional Template Variable The positional template variable, $n:length, uses a numerical identifier, n, to represent the position of the field value in the compression residue, and a length to specify the fixed size in bytes of the captured value (see Section 2.2). That is, $1:10 represents the first field value in the residue with a fixed length of 10 bytes, while $2:4 represents the second one with 4 bytes. Corneo, et al. Expires 4 January 2027 [Page 5] Internet-Draft SCHC-payload July 2026 For example, a target value (TV) using two positional template variables may look as follows: {"id": $1:10, "value": $2:4} Considering the above example, the MO equal-template will match the following payload: {"id": "abc123", "value": -11} As a result, the values "abc123" and -11 will be encoded in the residue during compression phase, while the rest of the template will be elided. Note that since the matching is byte-wise (see Section 2), the positional variable captures exactly the substring between the surrounding fixed portions. In this example, $1 captures "abc123" including the JSON quotes (8 bytes), while $2 captures -11 without quotes (3 bytes). 3.2. Repeat Template Function The repeat template function, $repeat(template, separator), is used to repeat multiple times the template passed as argument. The function requires two arguments as input, namely, the template to repeat, and the separator between template repetitions. The example below is indicative of a common pattern found in structured data payloads. [{"id": "abc123", "value": -11}, {"id": "abc123", "value": -13}] Using the repeat template function, $repeat(), the above example may look as follows: [$repeat('{"id": $1:10, "value": $2:4}', ", ")] As noted above, it is possible to use the repeat template function, $repeat(), in conjunction with the positional template variable, $n. 3.2.1. Repetition Count The number of repetitions is not known a-priori from the template and varies per payload. The compressor MUST infer the number of repetitions by matching the template against the field value, and MUST encode this count as the first byte of the residue for the $repeat() block, as an unsigned 8-bit integer. The decompressor MUST read this count first, then extract the positional variable values for each repetition in sequence. Corneo, et al. Expires 4 January 2027 [Page 6] Internet-Draft SCHC-payload July 2026 For the example above with two repetitions, the residue is structured as follows: | Count (1 byte) | $1 rep.1 | $2 rep.1 | $1 rep.2 | $2 rep.2 | | 0x02 | 10 bytes | 4 bytes | 10 bytes | 4 bytes | Since each positional variable has a fixed length declared via the $n:length notation (see Section 2.2), the decompressor knows that each repetition contributes a fixed number of bytes to the residue. In the example above, each repetition contributes 14 bytes (10 + 4). A repetition count of zero is valid. In this case, the residue for the $repeat() block contains only the count byte (0x00), and the decompressor MUST reconstruct an empty sequence, retaining only the surrounding fixed portions of the template. However, a repetition count of zero is discouraged as it likely indicates a misconfigured rule or an unexpected payload structure. Since the repetition count is encoded as an unsigned 8-bit integer, the maximum number of repetitions is 255. This is expected to be sufficient for constrained IoT use cases. Whether a larger count field is needed is left for discussion within the Working Group. 3.2.2. Positional Variable Scope Positional variable identifiers ($n) are scoped to a single repetition. That is, $1 and $2 refer to the first and second extracted values within each repetition, not across the entire payload. The residue contains the values for all positional variables of the first repetition, followed by those of the second repetition, and so on. 3.2.3. Optimization Example The level of payload compression that can be achieved greatly varies depending on the use case. For example, if it is known a-priori that the value of the field id never changes, the above payload example could be further optimized as follows: [$repeat('{"id": "abc123", "value": $1:4}', ", ")] The above template allows the compressor to avoid adding the value of the field id to the residue, unlike in the previous example. Corneo, et al. Expires 4 January 2027 [Page 7] Internet-Draft SCHC-payload July 2026 4. A Keyword for Structured Data Payload Compression This section defines the keyword payload that MUST be used whenever payload compression is needed. In such cases, the keyword payload MUST be specified in the Field IDentifier (FID). When payload compression is performed by individually specifying one structured field at a time, the FID MUST include the keyword payload as prefix, followed by a colon : and the name of the structured data field, e.g., payload:name for the structured data field called name. An extended FID notation that includes additional context such as media type and field index is illustrated in Section 6. Whether such extended notation should be normative is left for discussion within the Working Group. When payload compression is provided through a template, thus all the structured data fields are included in the TV, the FID MUST include only the keyword payload. 5. An Example of Structured Data Payload with Template This section demonstrates the use of the equal-template matching operator (MO) in conjunction with payload compression templates and the payload keyword. Considering the example below [{"id": "abc123", "value": -11}, {"id": "abc123", "value": -13}] a SCHC rule (with only relevant fields) MAY be defined using the new payload keyword, the equal-template MO, and the payload compression templates (functions and variables). Such a rule may look as follows: FID TV MO CDA payload