SCHC Payload Compression for Structured Formats
draft-corneo-schc-compress-payload-02

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  <template>  equal-template  send

   where the <template> is omitted from the above for brevity, but is
   defined as follows:

   [$repeat('{"id": "abc123", "value": $1:4}', ", ")]

Corneo, et al.           Expires 4 January 2027                 [Page 8]
Internet-Draft                SCHC-payload                     July 2026

   When a SCHC node computes the rule above, the payload keyword in the
   FID signals the node that application data needs to be compressed.
   Specifically, the equal-template MO triggers the SCHC node to check
   for equality between the current field value and the template
   provided in the TV.  Upon matching, the residue is sent (or
   retrieved) over the network.  For the payload above, the residue
   contains the repetition count (0x02, 1 byte) followed by the values
   -11 and -13, each padded to 4 bytes.

   Please notice that the algorithm used to perform template matching is
   implementation-specific, provided that the result is equivalent to
   the matching procedure defined in Section 2.

6.  An Example of Structured Data Payload without Template

   This section demonstrates how to make use of payload compression
   without a template as defined in this document.  The example below
   will be the target of the payload compression.

   [{"id": "abc123", "value": -11}, {"id": "abc123", "value": -13}]

   The snippet below shows how a SCHC rule (only relevant fields are
   used) MAY be defined using the new payload keyword.

   FID                               TV      MO      CDA
   payload:application/json:1:id     abc123  equal   elide
   payload:application/json:1:value          ignore  send
   payload:application/json:2:id     abc123  equal   elide
   payload:application/json:2:value          ignore  send

   The FIDs in the rule above carry semantics that can be used by the
   SCHC node to perform successful compression and decompression.
   Considering the first field of the above rule, application/json
   signals the decompressor which media type is being reconstructed.
   The subsequent numerical identifier, 1, represents the object the
   compressed field belongs to.  Finally, the last value encoded in the
   FID is the name of the JSON object, id.  Moreover, the target value
   (TV) corresponds to the value of the structured data field, and not
   to the name.

   In the second field of the above rule, the TV is omitted as the send
   CDA implies that the decompressor reads the received residue.
   However, in this case, the decompressor knows that the residue must
   be assigned to the JSON field specified in the FID, value in this
   case.

Corneo, et al.           Expires 4 January 2027                 [Page 9]
Internet-Draft                SCHC-payload                     July 2026

   Please notice that the semantics of the FID described above are not
   normative.  Semantic-specific details of the FID are left to
   implementations as this document only mandates the payload keyword.

7.  Security Considerations

   The security considerations of the SCHC framework [RFC8724] apply to
   this document.

   This document does not define any encryption mechanism.  If payload
   confidentiality is required, it MUST be provided by a lower layer or
   by encrypting the payload before compression.

8.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to this
   document, in accordance with [RFC8126].

8.1.  SCHC Payload Compression Template Functions and Variables

   IANA is requested to create a new registry called "SCHC Payload
   Compression Template Functions and Variables".

   The registration policy for this registry is "Specification Required"
   as defined in Section 4.6 of [RFC8126].

   The registry MUST include the following fields: - Name of function or
   variable - Type (function or variable) - Description - Reference of
   the specification describing the function or variable

   The designated expert(s) SHOULD verify that the template function, or
   variable, name is appropriate and not likely to cause confusion with
   existing entries.

   The registrant of an existing entry may request updates to that
   entry, subject to the same expert review.  They should verify that
   updates preserve backward compatibility with deployed
   implementations, or if breaking changes are necessary, consider
   whether a new registry entry is more appropriate.

   The following template functions and variables are described in this
   document:

Corneo, et al.           Expires 4 January 2027                [Page 10]
Internet-Draft                SCHC-payload                     July 2026

     +===============+==========+===================+================+
     | Function/     | Type     | Description       | Reference      |
     | Variable Name |          |                   |                |
     +===============+==========+===================+================+
     | n             | variable | Positional        | This document, |
     |               |          | Template Variable | Section 3.1    |
     +---------------+----------+-------------------+----------------+
     | repeat        | function | Repeat Template   | This document, |
     |               |          | Function          | Section 3.2    |
     +---------------+----------+-------------------+----------------+

          Table 1: SCHC Payload Compression Template Functions and
                             Variables Registry

9.  References

9.1.  Normative References

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/rfc/rfc8724>.

9.2.  Informative References

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

Corneo, et al.           Expires 4 January 2027                [Page 11]
Internet-Draft                SCHC-payload                     July 2026

Appendix A.  Acknowledgements

   A great token of appreciation to Rajat Kandoi and Ari Keränen for
   their support in the inception and review of this draft.  Their ideas
   and thinking are also reflected in the text of the draft.

Appendix B.  Preliminary ABNF for Template Syntax

   This appendix provides a preliminary ABNF (RFC 5234) grammar for the
   template syntax defined in this document.  This grammar is work in
   progress and is subject to discussion and agreement within the SCHC
   Working Group.

   template       = *( fixed-text / variable / function )

   fixed-text     = 1*( %x00-23 / %x25-FF )  ; any character except "$"

   variable       = "$" pos-id ":" length
   pos-id         = 1*DIGIT
   length         = 1*DIGIT

   function       = "$" func-name "(" func-args ")"
   func-name      = 1*ALPHA
   func-args      = func-arg *( "," SP func-arg )
   func-arg       = quoted-string / template

   quoted-string  = "'" *( %x00-26 / %x28-FF ) "'"

Authors' Addresses

   Lorenzo Corneo
   Ericsson
   Email: lorenzo.corneo@ericsson.com

   Edgar Ramos
   Ericsson
   Email: edgar.ramos@ericsson.com

   Jaime Jimenez
   Ericsson
   Email: jaime.jimenez@ericsson.com

Corneo, et al.           Expires 4 January 2027                [Page 12]