Packed CBOR: Table set up by reference

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/.¶

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 22 April 2025.¶

Copyright Notice

Copyright (c) 2024 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

Packed CBOR [I-D.ietf-cbor-packed] is a compression mechanism for Concise Binary Object Representation (CBOR, [RFC8949]) that can be used without a decompression step.¶

It depends on compression tables, which can be set up through different means: they can come from the CBOR item's context, be populated in the item itself, or use newly defined CBOR tags. This document defines such a tag that uses dereferenceable identifiers to set up a table, and introduces a pattern of using it without sending long identifiers.¶

2. Setting up the tables by reference

CBOR tag TBD213 is defined with semantics similar to tags TBD113 and TBD1113 from [I-D.ietf-cbor-packed] in that it sets up tables around a rump.¶

Packed-By-Reference = #6.<tbd213>([count, source, rump])
rump = any
source = CRI / ~uri
count = (count-shared-and-argument //    ; similar to tag 113
  count-shared, count-argument )         ; similar to tag 1113

count-shared-and-argument = uint
count-shared = uint
count-argument = uint

tbd213 = 213   ; preliminary value, see IANA considerations

The items inserted by the tables are not given explicitly, but picked out of tables known by their identifier given as source. Such a source needs to represent two lists of CBOR items, one for each kind of tables (one for shared item, one for arguments). The tag prepends some number of items out of those source lists to the tables that are used to decompress the rump.¶

The identifier is given as a URI string (as defined in [RFC3986]) or equivalently as a CRI (as defined in [I-D.ietf-core-href]). Later iterations of this document may introduce additional options.If the stand-in concept of [I-D.bormann-cbor-yang-standin] is generalized, the source item may become the raw list of tables, possibly disallowing the CRI and URI variants. Given that tags 113 and 1113 are capable of expressing cases where the source tables are present, tag TBD213 should then be used by using a dereferencing stand-in in the source position. When the source identifier is dereferenceable, all considerations from [I-D.bormann-t2trg-deref-id] apply. (Simplifying: No dereferencing at runtime -- the recipient either knows it already or treats it as unknown).¶

If the same number of items is prepended to both tables, their count is given as a single number; otherwise, the numbers are given separately.¶

Encoders SHOULD use the most compact form of count, and SHOULD pick the lowest count(s) sufficient to encode the items contained in the rump. When those conflict, they may prioritize either. If the source supports evolution of sources (see Section 2.1.2), disregarding that recommendation may pose an interoperability hazard.¶

count //= (
    skip-shared, count-shared, skip-argument, count-argument
    )

skip-shared = uint
skip-argument = uint

213([7, "tag:example.com,2023:byref"
    [{"store": {
       "book": [
         {simple(1): "reference", simple(2): "Nigel Rees",
          simple(3): "Sayings of the Century", simple(0): simple(5)},
         {simple(1): simple(4), simple(2): "Evelyn Waugh",
          simple(3): "Sword of Honour", simple(0): 12.99},
         {simple(1): simple(4), simple(2): "Herman Melville",
          simple(3): "Moby Dick", simple(6): "0-553-21311-3",
          simple(0): simple(5)},
         {simple(1): simple(4), simple(2): "J. R. R. Tolkien",
          simple(3): "The Lord of the Rings",
          simple(6): "0-395-19395-8", simple(0): 22.99}],
       "bicycle": {"color": "red", simple(0): 19.95}}}]])

3. Nested table setups

Documents that use tables from multiple sources can easily spend many bytes on listing source identifiers. A pattern that reduces the verbosity while staying unambiguous are nested table setups, where the outer tables are extended to contain additional identifiers.¶

In this pattern, tables are set up in two stages:¶

The outer stage contains the CRIs or URIs that may later be used as source values. (It may also contain other items). The inner stage is set up using tag TBD213, and the source given is a packed reference.¶

All table inputs can be evolved orthogonally as described in Section 2.1.2. If an unspecified entry is used as a source, the whole source content is considered unspecified.¶

213([5, 6(42) / outer item 100 /,
     213([2, 6(45) / outer item 101, currently item 105 /,
     [simple(11) / outer item 0, currently item 11,
      "This class has students with the following names" /,
  simple(0) / item 0 of german-names, "Franz" /,
  simple(2) / item 0 of english-names, currently item 2, "George" /,
  simple(1) / item 1 of german-names, "Fritz" /,
  simple(7) / item 5 of english-names, currently item 7, "Jack" /
  ]])])

4. Security Considerations

General security considerations from [I-D.ietf-cbor-packed] and [I-D.bormann-t2trg-deref-id] apply. In particular, any security implications of different applications disagreeing about what tables are implied by a media type apply likewise to situations when different applications disagree about the tables from a specified source.¶

5. IANA Considerations

Appendix A. Change log

From -02 to -03:¶

• Switched from CPA114 to CPA213 to stay out of Carsten's dangerous ASCII region.¶

• Add security considerations.¶

• Provide an actual introduction.¶

• Minor simplifications.¶

From -01 to -02:¶

• Add text on use of unpopulated items, and rationale to count in general.¶

• Split 4-argument form into its own subsection¶

• Fix erroneous example¶

• Augment CDDL with comments and [I-D.ietf-cbor-update-8610-grammar]¶

• Add considerations for splitting between loading and importing through stand-ins¶

• Write IANA considerations¶

• Editorial changes¶

Acknowledgments

[ TBD ]¶

Author's Address