Internet-Draft dCBOR July 2023
Bormann Expires 24 January 2024 [Page]
Intended Status:
C. Bormann
Universität Bremen TZI

dCBOR – an Application Profile for Use with CBOR Deterministic Encoding


CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides the application profile "dCBOR" that can be used with Deterministic Encoding.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at

Discussion of this document takes place on the Concise Binary Object Representation Maintenance and Extensions (CBOR) Working Group mailing list (, which is archived at Subscribe at

Source for this draft and an issue tracker can be found at

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

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 24 January 2024.

Table of Contents

1. Introduction

CBOR ([STD94], also RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides the application profile "dCBOR" that can be used with Deterministic Encoding.

1.1. Conventions and Definitions

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Application Profile

The dCBOR Application Profile specifies the use of Deterministic Encoding as defined in Section 4.2 of [STD94] (see also [I-D.bormann-cbor-det] for more information) together with some application-level rules specified in this section.

The application-level rules specified here do not "fork" CBOR. A dCBOR implementation produces well-formed, deterministically encoded CBOR according to [STD94], and existing generic CBOR decoders will therefore be able to decode it, including those that check for Deterministic Encoding. Similarly, generic CBOR encoders will be able to produce valid dCBOR if handed dCBOR conforming data model level information from an application.

Please note that the separation between standard CBOR processing and the processing required by the dCBOR application profile is a conceptual one: Both dCBOR processing and standard CBOR processing can be combined into a special dCBOR/CBOR encoder/decoder.

This application profile is intended to be used in conjunction with an application, which typically will use a subset of CBOR, which in turn influences which subset of the application profile is used. As a result, this application profile places no direct requirement on what subset of CBOR is implemented. For instance, there is no requirement that dCBOR implementations support floating point numbers (or any other kind of number, such as arbitrary precision integers or 64-bit negative integers) when they are used with applications that do not use them.

2.1. Numeric reduction

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

  1. 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 basic (major type 0/1) integer value. 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 range of basic 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.

  2. In addition, represent all NaN values by using the quiet NaN value having the half-width CBOR representation 0xf97e00 before encoding.

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 integer value in its place (and, if needed, convert it to a floating point value for 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. 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".

3.1. TypeScript

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

3.2. Swift

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

3.3. Rust

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

3.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]
  • Testing:
  • Licensing: Apache-2.0

4. Security Considerations

TODO Security

5. IANA Considerations

This document has no IANA actions.

6. References

6.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <>.

6.2. Informative References

"Blockchain Commons Deterministic CBOR ("dCBOR") for Rust", n.d., <>.
"Blockchain Commons Deterministic CBOR ("dCBOR") for TypeScript", n.d., <>.
"Blockchain Commons Deterministic CBOR ("dCBOR") for Swift", n.d., <>.
Bormann, C., "PoC of the McNally/Allen "dCBOR" application-level CBOR representation rules", n.d., <>.
Bormann, C., "cbor-deterministic gem", n.d., <>.
Bormann, C., "CBOR diagnostic utilities", n.d., <>.
Bormann, C., "CBOR: On Deterministic Encoding", Work in Progress, Internet-Draft, draft-bormann-cbor-det-00, , <>.
McNally, W. and C. Allen, "Gordian dCBOR: Deterministic CBOR Implementation Practices", Work in Progress, Internet-Draft, draft-mcnally-deterministic-cbor-01, , <>.
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <>.


This document is based on the work of Wolf McNally and Christopher Allen as documented in [I-D.mcnally-deterministic-cbor] and discussed in 2023 in the CBOR working group.


Wolf McNally
Blockchain Commons
Christopher Allen
Blockchain Commons

Author's Address

Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen