]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Applications and Real-Time CBOR CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. This document also introduces the concept of Application Profiles, which are layered on top of the CBOR CDE Profile and can address more application specific requirements. To demonstrate how Application Profiles can be built on the CDE, a companion document defines the application profile "dCBOR". About This Document 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 .

Introduction CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. This document also introduces the concept of Application Profiles, which are layered on top of the CBOR CDE Profile and can address more application specific requirements. To demonstrate how Application Profiles can be built on the CDE, a companion document defines the application profile "dCBOR".

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 when, and only when, they appear in all capitals, as shown here.

CBOR Common Deterministic Encoding Profile (CDE) This specification defines the CBOR Common Deterministic Encoding Profile (CDE) based on the Core Deterministic Encoding Requirements defined for CBOR in . In many cases, CBOR provides more than one way to encode a data item, but also provides a recommendation for a Preferred Encoding. The CoRE Deterministic Encoding Requirements generally pick the preferred encodings as mandatory; they also pick additional choices such as definite-length encoding. Finally, it defines a map ordering based on lexicographic ordering of the (deterministically) encoded map keys. Note that this specific set of requirements is elective — in principle, other variants of deterministic encoding can be defined (and have been, now being phased out slowly, as detailed in ). In many applications of CBOR today, deterministic encoding is not used at all, as its restriction of choices can create some additional performance cost and code complexity. 's core requirements are designed to provide well-understood and easy-to-implement rules while maximizing coverage, i.e., the subset of CBOR data items that are fully specified by these rules, and also placing minimal burden on implementations. picks up on the interaction of extensibility (CBOR tags) and deterministic encoding. CBOR itself uses some tags to increase the range of its basic generic data types, e.g., tags 2/3 extend the range of basic major types 0/1 in a seamless way. recommends handling this transition the same way as with the transition between different integer representation lengths in the basic generic data model, i.e., by mandating the Preferred Encoding ().

1. The CBOR Common Deterministic Encoding Profile (CDE) turns this recommendation into a mandate: Integers that can be represented by basic major type 0 and 1 are encoded using the deterministic encoding defined for them, and integers outside this range are encoded using the preferred serialization () of tag 2 and 3 (i.e., no leading zero bytes).

Most tags capture more specific application semantics and therefore may be harder to define a deterministic encoding for. While the deterministic encoding of their tag internals is often covered by the Core Deterministic Encoding Requirements, the mapping of diverging platform application data types on the tag contents may be hard to do in a deterministic way; see for more explanation as well as examples. As the CDE would continually need to address additional issues raised by the registration of new tags, this specification RECOMMENDS that new tag registrations address deterministic encoding in the context of this Profile. A particularly difficult field to obtain deterministic encoding for is floating point numbers, partially because they themselves are often obtained from processes that are not entirely deterministic between platforms. See for more details. presents a number of choices, which need to be made to obtain a CBOR Common Deterministic Encoding Profile (CDE). Specifically, CDE specifies (in the order of the bullet list at the end of ):

1. Besides the mandated use of preferred encoding, there is no further specific action for the two different zero values, e.g., an encoder that is asked by an application to represent a negative floating point zero will generate 0xf98000.
2. There is no attempt to mix integers and floating point numbers, i.e., all floating point values are encoded as the preferred floating-point representation that accurately represents the value, independent of whether the floating point value is, mathematically, an integral value (choice 2 of the second bullet).
3. There is no special handling of NaN values, except that the preferred encoding rules also apply to NaNs with payloads, using the canonical encoding of NaNs as defined in . Typically, most applications that employ NaNs in their storage and communication interfaces will only use the NaN with payload 0, which encodes as 0xf97e00.
4. There is no special handling of subnormal values.
5. The CBOR Common Deterministic Encoding Profile does not presume equivalence of floating point values with other representation (e.g., tag 4/5) with basic floating point values.

The main intent here is to preserve the basic generic data model, so Application Profiles can make their own decisions within that data model. E.g., an application profile can decide that it only ever allows a single NaN value that would encoded as 0xf97e00, so a CDE implementation focusing on this application profile would not need to provide processing for other NaN values. Basing the definition of both CDE and Application Profiles on the generic data model of CBOR also means that there is no effect on CDDL , except where the data description documents encoding decision for byte strings carrying embedded CBOR.

Application Profiles While the CBOR Common Deterministic Encoding Profile (CDE) provides for commonality between different applications of CBOR, it is useful to further constrain the set of data items handled in a group of applications (exclusions) and to define further mappings (reductions) that help the applications in such a group get by with the exclusions. For example, the dCBOR Application Profile specifies the use of Deterministic Encoding as defined in (see also for more information) together with some application-level rules. See for a definition of the dCBOR Application Profile that makes use of CDE. In general, the application-level rules specified by an Application Profile are based on the same CBOR Common Deterministic Encoding Profile; they do not "fork" CBOR. An Application Profile implementation produces well-formed, deterministically encoded CBOR according to , 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 CBOR that can be processed by Application Profile implementations, if handed Application Profile conforming data model level information from an application. Please note that the separation between standard CBOR processing and the processing required by the Application Profile is a conceptual one: Both Application Profile processing and standard CBOR processing can be combined into a encoder/decoder specifically designed for the Application Profile. An Application Profile is intended to be used in conjunction with an application, which typically will use a subset of the CBOR generic data model, which in turn influences which subset of the application profile is used. As a result, an Application Profile itself places no direct requirement on what minimum subset of CBOR is implemented. For instance, an application profile might define rules for the processing of floating point values, but there is no requirement that implementations of that Application Profile 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.

CDDL support defines control operators to indicate that the contents of a byte string carries a CBOR-encoded data item (.cbor) or a sequence of CBOR-encoded data items (.cborseq). CDDL specifications may want to specify that the data items should be encoded in Common CBOR Deterministic Encoding. This specification adds two CDDL control operators that can be used for this. The control operators .cde and .cdeseq are exactly like .cbor and .cborseq except that they also require the encoded data item(s) to be in Common CBOR Deterministic Encoding. For example, a byte string of embedded CBOR that is to be encoded according to CDE can be formalized as: More importantly, if the encoded data item also needs to have a specific structure, this can be expressed by the right hand side (instead of using the most general CDDL type any here). (Note that the ...seq control operator does not enable specifying different deterministic encoding requirements for the elements of the sequence. If a use case for such a feature becomes known, it could be added.) Obviously, Application Profiles can define similar control operators that also embody the processing required by the Application Profile, and are encouraged to do so.

Security Considerations TODO Security

IANA Considerations RFC Editor: please replace RFCXXXX with the RFC number of this RFC and remove this note. This document requests IANA to register the contents of into the registry "" of : New control operators to be registered

Name	Reference
.cde	[RFCXXXX]
.cdeseq	[RFCXXXX]

References Normative References 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. IEEE This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Universität Bremen TZI CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides additional information about use cases, deployment considerations, and implementation choices for Deterministic Encoding. Universität Bremen TZI CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document discusses a Common CBOR Deterministic Encoding Profile that can be shared by a large set of applications with potentially diverging detailed requirements. The concept of Application Profiles is layered on top of the Common CBOR Deterministic Encoding Profile and can address those more application specific requirements. The document defines the application profile "Gordian dCBOR" as an example of an application profile built on the Common CBOR Deterministic Encoding Profile. Blockchain Commons Blockchain Commons CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides the application profile "dCBOR" that can be used to help achieve interoperable deterministic encoding. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/BlockchainCommons/WIPs-IETF-draft-deterministic- cbor.

Acknowledgments An earlier version of this document was based on the work of Wolf McNally and Christopher Allen as documented in ; the parts directly based on this are now separated out as the dCBOR Application Profile . Nonetheless, we acknowledge that this work has contributed greatly to shaping the concept of a CBOR Common Deterministic Encoding and Application Profiles on top of that.