---
# System prepended metadata

title: 'Agenda: Deterministic CBOR (dCBOR) Proposal'

---

Dear CBOR Working Group Members,

We would like to propose an agenda for an upcoming CBOR meeting to discuss certain issues related to dCBOR. We aim to be as collaborative as possible, and would like to discuss pros and cons of each issue in order to foster a productive discussion. It should be noted that nothing in our proposal affects the CBOR RFC or the ways that CBOR is commonly used in any way.

Christopher Allen, Blockchain Commons

# Agenda: Deterministic CBOR (dCBOR) Proposal

The recent update to the dCBOR Internet Draft is the subject of this agenda:

https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-01.html

Some of this draft is a restatement of what’s in the RFC as recommendations, but making its deterministic factors requirements. Other issues raised by the draft have been a subject of discussion. Our aim is to reach consensus on these issues.

## Numerical Reduction

Proposal: All numbers MUST be reduced to the smallest possible representation. Failure to do so is a well-formness error.

Pros:

* Deterministic
* Generally smaller representation
* Not hard to implement (we already have reference implementations in Swift and Rust)
* Support for larger numbers (e.g., BIGNUM) is allowed but not required
* Directly compatible with languages like Javascript and Ruby that have a generic number type
* Generally removes cognitive load from the programmer
* Useful for Gordian Envelope and other protocols requiring determinism
* Can be ignored by other protocols that do not care about determinism

Cons:

* The current recommendations for "deterministic" encoding in the RFC do not have the above requirements, and therefore CBOR encoded with only the recommendations in the RFC will not necessarily conform to the requirements for dCBOR. 
* This includes the reference implementation at https://cbor.me and the Java package at org.webpki.cbor.
   * Though all dCBOR must be CBOR; we do not believe the converse is true, which may reduce this issue.
* Some integer values (such as 1099511627775 [0xffffffffff]) can actually be larger than BIGNUM equivalents!

Alternative: The alternative would be to mandate that floats remain unchanged, which trends away from the suggestions in §4.2 of RFC 8949 for moving data to the shortest encoding possible and has the possibility of damaging determinism, but which matches some current implementations:
   * Floats MUST be maintained as Floats, but otherwise all numbers MUST be reduced to the smallest possible representation. Failure to do so is a well-formness error.

## Adding dCBOR Support to Flagship Implementations and Tools

Proposal: Add a "deterministic" flag to existing implementations and tools such as https://cbor.me and QCBOR.

Pros:

* Would encourage dCBOR adoption
* Would enable such tools to be be used by developers of protocols requiring determinism, including Gordian Envelope
* Would not invalidate other CBOR implementations
* Would be opt-in, and so transparent to existing users and protocols that do not care about determinism

Cons:

* Requires work to implement, test, document, and maintain


## Bringing the dCBOR specification under purview of the CBOR Working Group and putting it on a track to RFC status.

Pros:

* Would be in line with the recommendation of IETF Dispatch.
* Would benefit the entire CBOR community.

Cons:

* Would require active participation from the CBOR WG.