The CDE-based Application Profile dCBOR

Internet-Draft	dCBOR	November 2023
Bormann	Expires 8 May 2024	[Page]

Abstract

CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. The CBOR Common Deterministic Encoding (CDE) Profile provides a more detail common base for Deterministic Encoding, facilitating it be offered as a selectable feature of generic encoders, as well as the concept of Application Profiles that are layered on top of CDE. This document defines the application profile "dCBOR" as an example of such an application profile.¶

2. Gordian dCBOR

Gordian dCBOR [I-D.mcnally-deterministic-cbor] provides an application profile that requires encoders to produce valid CBOR in deterministic encoding as defined in CDE). Gordian dCBOR also requires dCBOR decoders to reject CBOR data items that were not deterministically encoded.¶

Beyond CDE, dCBOR imposes certain limitations on the CBOR basic generic data model. Some items that can be represented in the CBOR basic generic data model are entirely outlawed by this application profile. Other items are represented by what are considered equivalent data items by the dCBOR equivalence model, so a recipient application might receive data that may not be the same data in the CBOR equivalence model as the ones the generating application produced.¶

These restrictions mainly are about numeric values, which are therefore the subject of the main subsection of this section.¶

2.1. Removing Simple Values

Only the three simple values false (0xf4), true (0xf5), and null (0xf6) are allowed at the application level; the remaining 253 values must be rejected.¶

2.2. Removing Integer Values

Only the integer values in range [-2⁶³, 2⁶⁴-1] can be expressed in dCBOR ("basic dCBOR integers"). Note that the range is asymmetric, with only 2⁶³ negative values, but 2⁶⁴ unsigned (non-negative) values, creating an (approximately) 64.6 bit integer.¶

This maps to a choice between a platform 64-bit two's complement signed integer (often called int64) and a 64-bit unsigned integer (uint64). (Specific applications will, of course, further restrict ranges of integers that are considered valid for the application, based on their position and semantics in the CBOR data item.)¶

2.3. Numeric Reduction of Floating-Point Values

dCBOR implementations that do support floating point numbers MUST perform the following two reductions of numeric values when constructing CBOR data items:¶

When representing integral floating point values (floating point values with a zero fractional part), check whether the mathematically identical value can be represented as a dCBOR integer value, i.e., is in the range [-2⁶³, 2⁶⁴-1] given above. If that is the case, convert the integral floating point to that mathematically identical integer value before encoding it. (Deterministic Encoding will then ensure the shortest length encoding is used.) This means that if a floating point value has a non-zero fractional part, or an exponent that takes it out of the given range of basic dCBOR integers, the original floating point value is used for encoding. (Specifically, conversion to a bignum is never considered.)¶

This also means that the three representations of a zero number in CBOR (0, 0.0, -0.0 in diagnostic notation) are all reduced to the basic integer 0 (with preferred encoding 0x00).¶

Note that this reduction can turn valid maps into invalid ones, as it can create duplicate keys, e.g., for:¶
```
{
   10: "integer ten",
   10.0: "floating ten"
}
```
¶
This means that, at the application level, the application MUST prevent the creation of maps that would turn invalid in dCBOR processing.¶
In addition, before encoding, represent all NaN values by using the quiet NaN value having the half-width CBOR representation 0xf97e00.¶

dCBOR-based applications MUST accept these "reduced" numbers in place of the original value, e.g., a dCBOR-based application that expects a floating point value needs to accept a basic dCBOR integer in its place (and, if needed, convert it to a floating point value for its own further processing).¶

dCBOR-based applications MUST NOT accept numbers that have not been reduced as specified in this section, except maybe by making the unreduced numbers available for their diagnostic value when there has been an explicit request to do so. This is similar to a checking flag mentioned in Section 5.1 (API Considerations) of [I-D.bormann-cbor-det] being set by default.¶

3. Extensibility

[I-D.mcnally-deterministic-cbor] does not discuss extensibility. A meaningful way to handle extensibility in this application profile would be to lift value range restrictions, keeping the profile-specific equivalence rules shown here intact and possibly adding equivalences as needed for newly allowed values.¶

This subsection presents two speculative extensions of dCBOR, called dCBOR-wide1 and dCBOR-wide2, to point out different objectives that can lead the development of an extension.¶

3.1. dCBOR-wide1

This speculative extension of dCBOR attempts to meet two objectives:¶

All instances that meet dCBOR are also instances of dCBOR-wide1; due to the nature of deterministic serialization this also means that dCBOR-wide1 instances that only use application data model values that are allowed by dCBOR are also dCBOR instances.¶
The range of integers that can be provided by an application and can be interchanged as exact numbers is expanded to [-2¹²⁷, 2¹²⁸-1], now also covering the types i128 and u128 in Rust [i128][u128].¶

This extension is achieved by simply removing the integers in the extended range from the exclusion range of dCBOR. The numeric reduction rule is not changed, so it still applies only to integral-valued floating-point numbers in the range [-2⁶³, 2⁶⁴-1].¶

Examples for the application-to-CDE mapping of dCBOR-wide1 are shown in Table 1. In the dCBOR column, items that are not excluded in dCBOR are marked ✓, items that are excluded in dCBOR and therefore are new in dCBOR-wide1 are marked 👎.¶

Table 1: Speculative "dCBOR-wide1" application profile
Application data Numeric reduction (if any) Encoding via CDE	dCBOR?
`0` `—` `00`	✓
`0.0` `0` `00`	✓
`-0.0` `0` `00`	✓
`4.0` `4` `04`	✓
`-4.0` `-4` `23`	✓
`1.0e+19` `10000000000000000000` `1B8AC7230489E80000`	✓
`-1.0e+19` `—` `FBC3E158E460913D00`	✓
`10000000000000000000` `—` `1B8AC7230489E80000`	✓
`-10000000000000000000` `—` `3B8AC7230489E7FFFF`	👎
`1.0e+38` `—` `FB47D2CED32A16A1B1`	✓
`-1.0e+38` `—` `FBC7D2CED32A16A1B1`	✓
`100000000000000000000000000000000000000` `—` `C2504B3B4CA85A86C47A098A224000000000`	👎
`-100000000000000000000000000000000000000` `—` `C3504B3B4CA85A86C47A098A223FFFFFFFFF`	👎

This speculative extended profile does not meet a potential objective number 3 that unextended dCBOR does meet:¶

All integral-valued floating point numbers coming from an application that fit into an integer representation allowed by the application profile are represented as such.¶

Objective 1 prevents numeric reduction from being applied to values that are not excluded in dCBOR but do to receive numeric reduction there.¶

3.2. dCBOR-wide2

The speculative dCBOR-wide2 extension of dCBOR attempts to meet objectives 2 and 3 mentioned in Section 3.1. It cannot meet objective 1: items in Table 2 marked with a 💣 character are allows in dCBOR but have different serializations.¶

Table 2: Speculative "dCBOR-wide2" application profile
Application data Numeric reduction (if any) Encoding via CDE	dCBOR?
`0` `—` `00`	✓
`0.0` `0` `00`	✓
`-0.0` `0` `00`	✓
`4.0` `4` `04`	✓
`-4.0` `-4` `23`	✓
`1.0e+19` `10000000000000000000` `1B8AC7230489E80000`	✓
`-1.0e+19` `-10000000000000000000` `3B8AC7230489E7FFFF`	✓ 💣
`10000000000000000000` `—` `1B8AC7230489E80000`	✓
`-10000000000000000000` `—` `3B8AC7230489E7FFFF`	👎
`1.0e+38` `99999999999999997748809823456034029568` `C2504B3B4CA85A86C4000000000000000000`	✓ 💣
`-1.0e+38` `-99999999999999997748809823456034029568` `C3504B3B4CA85A86C3FFFFFFFFFFFFFFFFFF`	✓ 💣
`100000000000000000000000000000000000000` `—` `C2504B3B4CA85A86C47A098A224000000000`	👎
`-100000000000000000000000000000000000000` `—` `C3504B3B4CA85A86C47A098A223FFFFFFFFF`	👎

This extension is achieved by removing the integers in the extended range from the exclusion range of dCBOR, and by adding the extended range to the target range of numeric reduction.¶

5. Implementation Status

This section is to be removed before publishing as an RFC.¶

(Boilerplate as per Section 2.1 of [RFC7942]:)¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

5.1. Gordian dCBOR Application Profile

5.1.1. TypeScript

Implementation Location: [bc-dcbor-ts]¶
Primary Maintainer:¶
Languages: TypeScript (transpiles to JavaScript)¶
Coverage:¶
Testing:¶
Licensing:¶

5.1.2. Swift

Implementation Location: [BCSwiftDCBOR]¶
Primary Maintainer:¶
Languages: Swift¶
Coverage:¶
Testing:¶
Licensing: BSD-2-Clause-Patent¶

5.1.3. Rust

Implementation Location: [bc-dcbor-rust]¶
Primary Maintainer:¶
Languages: Rust¶
Coverage:¶
Testing:¶
Licensing: Custom¶

5.1.4. Ruby

Implementation Location: [cbor-dcbor]¶
Primary Maintainer: Carsten Bormann¶
Languages: Ruby¶
Coverage: Complete specification; complemented by CBOR encoder/decoder and command line interface from [cbor-diag] and deterministic encoding from [cbor-deterministic]. Checking of dCBOR exclusions not yet implemented.¶
Testing: Also available at https://cbor.me ¶
Licensing: Apache-2.0¶

Table 3: New control operators to be registered
Name	Reference
.dcbor	[RFCXXXX]
.dcborseq	[RFCXXXX]

8. References

8.1. Normative References

[IANA.cddl]: IANA, "Concise Data Definition Language (CDDL)", <https://www.iana.org/assignments/cddl>.
[RFC2119]: 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/rfc/rfc2119>.
[RFC8174]: 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/rfc/rfc8174>.
[RFC8610]: Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[STD94]: Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

8.2. Informative References

[bc-dcbor-rust]: "Blockchain Commons Deterministic CBOR ("dCBOR") for Rust", n.d., <https://github.com/BlockchainCommons/bc-dcbor-rust>.
[bc-dcbor-ts]: "Blockchain Commons Deterministic CBOR ("dCBOR") for TypeScript", n.d., <https://github.com/BlockchainCommons/bc-dcbor-ts>.
[BCSwiftDCBOR]: "Blockchain Commons Deterministic CBOR ("dCBOR") for Swift", n.d., <https://github.com/BlockchainCommons/BCSwiftDCBOR>.
[cbor-dcbor]: Bormann, C., "PoC of the McNally/Allen "dCBOR" application-level CBOR representation rules", n.d., <https://github.com/cabo/cbor-dcbor>.
[cbor-deterministic]: Bormann, C., "cbor-deterministic gem", n.d., <https://github.com/cabo/cbor-deterministic>.
[cbor-diag]: Bormann, C., "CBOR diagnostic utilities", n.d., <https://github.com/cabo/cbor-diag>.
[I-D.bormann-cbor-cde]: Bormann, C., "CBOR Common Deterministic Encoding (CDE)", Work in Progress, Internet-Draft, draft-bormann-cbor-cde-00, 5 November 2023, <https://datatracker.ietf.org/doc/html/draft-bormann-cbor-cde-00>.
[I-D.bormann-cbor-det]: Bormann, C., "CBOR: On Deterministic Encoding", Work in Progress, Internet-Draft, draft-bormann-cbor-det-01, 9 August 2023, <https://datatracker.ietf.org/doc/html/draft-bormann-cbor-det-01>.
[I-D.draft-mcnally-envelope-03]: McNally, W. and C. Allen, "The Gordian Envelope Structured Data Format", Work in Progress, Internet-Draft, draft-mcnally-envelope-03, 17 August 2023, <https://datatracker.ietf.org/doc/html/draft-mcnally-envelope-03>.
[I-D.mcnally-deterministic-cbor]: McNally, W. and C. Allen, "Gordian dCBOR: A Deterministic CBOR Application Profile", Work in Progress, Internet-Draft, draft-mcnally-deterministic-cbor-05, 8 August 2023, <https://datatracker.ietf.org/doc/html/draft-mcnally-deterministic-cbor-05>.
[i128]: "Primitive Type i128", n.d., <https://doc.rust-lang.org/std/primitive.i128.html>.
[RFC7942]: Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.
[u128]: "Primitive Type u128", n.d., <https://doc.rust-lang.org/std/primitive.u128.html>.

The CDE-based Application Profile dCBOR

Abstract

About This Document

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

1.1. Conventions and Definitions