dCBOR - an Application Profile for Use with CBOR Deterministic Encoding
draft-bormann-cbor-dcbor-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Carsten Bormann | ||
| Last updated | 2023-07-23 | ||
| Replaced by | draft-mcnally-deterministic-cbor | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bormann-cbor-dcbor-00
CBOR C. Bormann
Internet-Draft Universität Bremen TZI
Intended status: Experimental 23 July 2023
Expires: 24 January 2024
dCBOR – an Application Profile for Use with CBOR Deterministic Encoding
draft-bormann-cbor-dcbor-00
Abstract
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
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/.
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.
Bormann Expires 24 January 2024 [Page 1]
Internet-Draft dCBOR July 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 2
2. Application Profile . . . . . . . . . . . . . . . . . . . . . 3
2.1. Numeric reduction . . . . . . . . . . . . . . . . . . . . 3
3. Implementation Status . . . . . . . . . . . . . . . . . . . . 4
3.1. TypeScript . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Swift . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Rust . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Bormann Expires 24 January 2024 [Page 2]
Internet-Draft dCBOR July 2023
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.)
Bormann Expires 24 January 2024 [Page 3]
Internet-Draft dCBOR July 2023
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
Bormann Expires 24 January 2024 [Page 4]
Internet-Draft dCBOR July 2023
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:
Bormann Expires 24 January 2024 [Page 5]
Internet-Draft dCBOR July 2023
* 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
[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>.
[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>.
6.2. Informative References
Bormann Expires 24 January 2024 [Page 6]
Internet-Draft dCBOR July 2023
[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-det]
Bormann, C., "CBOR: On Deterministic Encoding", Work in
Progress, Internet-Draft, draft-bormann-cbor-det-00, 23
July 2023, <https://datatracker.ietf.org/doc/html/draft-
bormann-cbor-det-00>.
[I-D.mcnally-deterministic-cbor]
McNally, W. and C. Allen, "Gordian dCBOR: Deterministic
CBOR Implementation Practices", Work in Progress,
Internet-Draft, draft-mcnally-deterministic-cbor-01, 4 May
2023, <https://datatracker.ietf.org/doc/html/draft-
mcnally-deterministic-cbor-01>.
[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>.
Bormann Expires 24 January 2024 [Page 7]
Internet-Draft dCBOR July 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 24 January 2024 [Page 8]