]>

Austria christian@amsuess.com

cbor cbor packed uri cri Packed CBOR is a mechanism for transforming Concise Binary Object Representation (CBOR) data into a more compact form. This document introduces a means for setting up its tables by means of dereferenceable identifiers, and introduces a pattern of using it without sending long identifiers. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the CBOR Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Packed CBOR is a mechanism for transforming Concise Binary Object Representation (CBOR, ) data into a more compact form that can be used without a decompression step. It depends on packing 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.

Setting up the tables by reference CBOR tag TBD213 is defined with semantics similar to tags TBD113 and TBD1113 from in that it sets up tables around a rump. ([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 unpack the rump. The identifier is given as a URI string (as defined in ) or equivalently as a CRI (as defined in ). Later iterations of this document may introduce additional options.If the stand-in concept of 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 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 ), disregarding that recommendation may pose an interoperability hazard.

Count vs. content of source The count encoded for the number of table entries given in a document will often mismatch with the number of entries the receiver of a document knows to be present in the given source.

Not all known entries are used If the encoded count is less than the number of known entries, this merely expresses that the originator of the document did not use the higher numbers. When a document's tables are populated from multiple sources, encoding the smallest possible count is useful because the table indices used throughout the document stay small and can thus be encoded concisely.

Unknown entries are used – evolution of sources If the encoded count is larger than the number of known entries, this indicates that the document may contain references that the receiver does not know. This can happen when a source has been evolved compatibly to contain more entries, compared to when the receiver learned of the source definition. Source entries beyond the receiver's knowledge stay unpopulated in the receiver's tables, but still shift existing entries to higher indices. Some CBOR protocols come with elements that support isolation of processing errors. For example, a CRI that uses unknown extensions is regarded as "unprocessable" (). It cannot be resolved, is unequal to any other CRI (unless they are identical), but does not inhibit the processing of its surrounding document. In such protocols, references to unpopulated table entries can be tolerated as described in . Care has to be taken around processing tag TBD1112: If that tag is produced in the course of unpacking, comparisons for identity are not reliable. Similarly, if the unpacking mechanism provides access to the serialized form of the unprocessable entity, identity comparisons are only reliable if the items being compared have the same table setup applied. Protocols may also pre-populated entries with values that are reserved in the protocol and specified to be ignored at reception. Later, when the entries are specified, concrete values take their places. This has roughly the same effect, but is harder to describe. (This paragraph may be removed later unless it is found to be particularly useful). Protocols that do not support error isolation need a way to negotiate the understood set of sources and table entries.

Evolution beyond adding items The content of tables may be altered in more ways than just adding entries that were previously unpopulated. Such changes are NOT RECOMMENDED, because while they can be done in a compatible way, providing criteria for this are out of scope of this document. If a later version of this document uses stand-in values more actively, this section will need to be revisited: In that case, the tables may be part of the outer source, and then those would grow internally.

Setup with skipped indices If a large number of items at the beginning of the source tables would not be used, there is an additional four-argument form of count that defines a number of items in the source tables that are skipped before selecting items into the table. This allows keeping the indices low and therefore compact. Source tables should be designed in such a way that commonly used items are at the start to minimize the necessity for the four-argument form.

Example Suppose the URI "tag:example.com,2023:byref" defines the items ["price", "category", "author", "title", "fiction", 8.95, "isbn"] in both tables. Then the example in figure 3 of can be written as: Assuming that the underlying CBOR protocol defines that unknown keys on goods may be ignored, an older receiver that only knows the first 5 entries of the source tables could still process the document, but would be missing all ISBNs and the price of one item.

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 . If an unspecified entry is used as a source, the whole source content is considered unspecified.

Example of nested table setup In this example, the initial table set up is provided by the media type, and contains these items:

• 0: "This class has students with the following names"
• 100: "tag:example.com,2023:english-names.txt"
• 101: "tag:example.com,2023:german-names.txt"

Note that a constrained implementation of a decoder may not even have the fully expanded form of the URIs or CRIs available; it may only be capable of using these table entries in the source position and then find the shipped source lists.

Security Considerations General security considerations from and 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.

IANA Considerations

CBOR Tags Registry In the registry "CBOR Tags", IANA is requested to allocate one tag:

• Tag: 213
• Data item: Array [count(s), source, rump]
• Semantics: "Packed CBOR: table setup"
• Reference: This document

References Normative References Universität Bremen TZI TUD Dresden University of Technology The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // The present version (-14) adds additional stand-in items to the // previously updated implementation draft -13, with minor editorial // improvements. Universität Bremen TZI In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. // The present revision -04 includes a few clarifications. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the URI Schemes registry RFC 7595 describes cooperates with the CRI Scheme Numbers registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –18 integrates two small changes from the CoRE // interim on 2025-01-29 and should be ready for WGLC. Universität Bremen TZI The Concise Data Definition Language (CDDL), as defined in RFC 8610 and RFC 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in CBOR or JSON. The present document updates RFC 8610 by addressing errata and making other small fixes for the ABNF grammar defined for CDDL there. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Informative References Universität Bremen TZI CZ.NIC YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR.

Change log From -03 to -04:

• Aligned terminolgoy with latest Packed CBOR.

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
• Add considerations for splitting between loading and importing through stand-ins
• Write IANA considerations
• Editorial changes

Acknowledgments [ TBD ]