Internet DRAFT - draft-bormann-cbor-dcbor
draft-bormann-cbor-dcbor
CBOR C. Bormann
Internet-Draft UniversitΓ€t Bremen TZI
Intended status: Experimental 5 November 2023
Expires: 8 May 2024
The CDE-based Application Profile dCBOR
draft-bormann-cbor-dcbor-04
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.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-bormann-cbor-dcbor/.
Discussion of this document takes place on the Concise Binary Object
Representation Maintenance and Extensions (CBOR) Working Group
mailing list (mailto:cbor@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at
https://www.ietf.org/mailman/listinfo/cbor/.
Source for this draft and an issue tracker can be found at
https://github.com/cabo/det.
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 https://datatracker.ietf.org/drafts/current/.
Bormann Expires 8 May 2024 [Page 1]
Internet-Draft dCBOR November 2023
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 8 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Gordian dCBOR . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Removing Simple Values . . . . . . . . . . . . . . . . . 3
2.2. Removing Integer Values . . . . . . . . . . . . . . . . . 4
2.3. Numeric Reduction of Floating-Point Values . . . . . . . 4
3. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. dCBOR-wide1 . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. dCBOR-wide2 . . . . . . . . . . . . . . . . . . . . . . . 7
4. CDDL support . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
5.1. Gordian dCBOR Application Profile . . . . . . . . . . . . 10
5.1.1. TypeScript . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Swift . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.3. Rust . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.4. Ruby . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Bormann Expires 8 May 2024 [Page 2]
Internet-Draft dCBOR November 2023
1. Introduction
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.
1.1. Conventions and Definitions
The definitions of [STD94] and the Common Deterministic Encoding
(CDE) Profile [I-D.bormann-cbor-cde] apply.
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. 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.
Bormann Expires 8 May 2024 [Page 3]
Internet-Draft dCBOR November 2023
2.2. Removing Integer Values
Only the integer values in range [-2^63, 2^64-1] can be expressed in
dCBOR ("basic dCBOR integers"). Note that the range is asymmetric,
with only 2^63 negative values, but 2^64 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:
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 dCBOR
integer value, i.e., is in the range [-2^63, 2^64-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.
Bormann Expires 8 May 2024 [Page 4]
Internet-Draft dCBOR November 2023
2. 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:
1. 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.
2. The range of integers that can be provided by an application and
can be interchanged as exact numbers is expanded to [-2^127,
2^128-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^63, 2^64-1].
Bormann Expires 8 May 2024 [Page 5]
Internet-Draft dCBOR November 2023
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 π.
+==========================================+========+
| Application data | dCBOR? |
| Numeric reduction (if any) | |
| Encoding via CDE | |
+==========================================+========+
| 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 | β |
| β | |
Bormann Expires 8 May 2024 [Page 6]
Internet-Draft dCBOR November 2023
| FB47D2CED32A16A1B1 | |
+------------------------------------------+--------+
| -1.0e+38 | β |
| β | |
| FBC7D2CED32A16A1B1 | |
+------------------------------------------+--------+
| 100000000000000000000000000000000000000 | π |
| β | |
| C2504B3B4CA85A86C47A098A224000000000 | |
+------------------------------------------+--------+
| -100000000000000000000000000000000000000 | π |
| β | |
| C3504B3B4CA85A86C47A098A223FFFFFFFFF | |
+------------------------------------------+--------+
Table 1: Speculative "dCBOR-wide1" application
profile
This speculative extended profile does not meet a potential objective
number 3 that unextended dCBOR does meet:
3. 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.
+==========================================+========+
| Application data | dCBOR? |
| Numeric reduction (if any) | |
| Encoding via CDE | |
+==========================================+========+
| 0 | β |
| β | |
| 00 | |
+------------------------------------------+--------+
| 0.0 | β |
| 0 | |
| 00 | |
Bormann Expires 8 May 2024 [Page 7]
Internet-Draft dCBOR November 2023
+------------------------------------------+--------+
| -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 | |
+------------------------------------------+--------+
Table 2: Speculative "dCBOR-wide2" application
profile
Bormann Expires 8 May 2024 [Page 8]
Internet-Draft dCBOR November 2023
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.
4. CDDL support
Similar to the CDDL [RFC8610] support in [I-D.bormann-cbor-cde], this
specification adds two CDDL control operators that can be used to
specify that the data items should be encoded in CBOR Common
Deterministic Encoding (CDE), with the dCBOR application profile
applied as well.
The control operators .dcbor and .dcborseq are exactly like .cde and
.cdeseq except that they also require the encoded data item(s) to
conform to the dCBOR application profile.
For example, the normative comment in Section 3 of
[I-D.draft-mcnally-envelope-03]:
leaf = #6.24(bytes) ; MUST be dCBOR
...can now be formalized as:
leaf = #6.24(bytes .dcbor any)
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.
Bormann Expires 8 May 2024 [Page 9]
Internet-Draft dCBOR November 2023
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:
Bormann Expires 8 May 2024 [Page 10]
Internet-Draft dCBOR November 2023
* 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 (https://cbor.me)
* Licensing: Apache-2.0
6. Security Considerations
TODO Security
7. 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 Table 3 into
the registry "CDDL Control Operators" of [IANA.cddl]:
+===========+===========+
| Name | Reference |
+===========+===========+
| .dcbor | [RFCXXXX] |
+-----------+-----------+
| .dcborseq | [RFCXXXX] |
+-----------+-----------+
Table 3: New control
operators to be
registered
8. References
8.1. Normative References
Bormann Expires 8 May 2024 [Page 11]
Internet-Draft dCBOR November 2023
[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>.
Bormann Expires 8 May 2024 [Page 12]
Internet-Draft dCBOR November 2023
[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>.
Bormann Expires 8 May 2024 [Page 13]
Internet-Draft dCBOR November 2023
Acknowledgments
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.
Contributors
Wolf McNally
Blockchain Commons
Email: wolf@wolfmcnally.com
Christopher Allen
Blockchain Commons
Email: christophera@lifewithalacrity.com
Author's Address
Carsten Bormann
UniversitΓ€t Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires 8 May 2024 [Page 14]
