The tag-42 profile of CBOR
draft-caballero-cbor-cbor42-01
This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bumblefudge,Robin Berjon | ||
| Last updated | 2025-11-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-caballero-cbor-cbor42-01
Concise Binary Object Representation Maintenance and ExtensionsJ. CaballeroInternet-Draft R. BerjonIntended status: Informational IPFS FoundationExpires: 9 May 2026 5 November 2025 The tag-42 profile of CBOR draft-caballero-cbor-cbor42-01Abstract This document defines a very narrow profile of CBOR intended for use with the special tag 42. Like the earlier internet-draft submitted under the name "CBOR Core," much of its design dates to the first CBOR RFC and predates much of the layered approach to determinism and profiling in later years. Also like "CBOR/c", CBOR-42 can be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR-42 objects link to one another by hash-based identifiers tagged "42", deterministic encoding is mandated to verify dereferenced links and encode new ones.About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ipfs- tech.github.io/cborc42/draft-caballero-cbor-cborc42-latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-caballero-cbor-cbor42/. Discussion of this document takes place on the Concise Binary Object Representation Maintenance and Extensions mailing list (mailto:cbor@ietf.org), which is archived at https://www.ietf.org/ mail-archive/web/cbor/current/maillist.html. Subscribe at https://www.ietf.org/mailman/listinfo/cbor/. Source for this draft and an issue tracker can be found at https://github.com/ipfs-tech/cborc42.Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.Caballero & Berjon Expires 9 May 2026 [Page 1]Internet-Draft CBOR42 November 2025 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 9 May 2026.Copyright Notice Copyright (c) 2025 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. Design Goals . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.3. Common Definitions . . . . . . . . . . . . . . . . . . . 4 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Supported CBOR Objects . . . . . . . . . . . . . . . . . 4 2.2. Deterministic Encoding Scheme Profile . . . . . . . . . . 5 2.3. CBOR Tool Requirements . . . . . . . . . . . . . . . . . 6 2.3.1. Protocol Primitives . . . . . . . . . . . . . . . . . 6 2.3.2. Media Type . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. CBOR Sequences . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Binary Content Identifiers . . . . . . . . . . . . . 10 A.1. Legacy Support . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 B.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 12Caballero & Berjon Expires 9 May 2026 [Page 2]Internet-Draft CBOR42 November 2025 B.2. Floating Point Numbers . . . . . . . . . . . . . . . . . 13 B.3. Miscellaneous Items . . . . . . . . . . . . . . . . . . . 17 B.4. Invalid Encodings . . . . . . . . . . . . . . . . . . . . 18 Appendix C. Configuration and ALDRs . . . . . . . . . . . . . . 19 Appendix D. Decoding Strictness . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201. Introduction The developer ecosystem around the Interplanetary File System, a distributed system file and document handling, has long made structural usage of its own home-grown CBOR profile, dating from the early days of the CBOR working group and fine-tuned over the years in community/internal venues. Configuring CBOR tooling in various languages to decode this data and encode new data conformantly has been a challenge, and a unified specification (updated to modern terminology, as the CBOR working group has iterated and evolved so much in the intervening years) is set out in this document. Note: unlike the CBOR/c specification, no opinion on best practices for hashing or signing mechanisms is expressed here, and will be addressed in separate documents, if at all.1.1. Design Goals The primary goal of this specification is enabling application developers to configure CBOR tooling for this profile, and for CBOR tooling to support such configuration, in as language-agnostic a way as possible. The historical design of this profile was to maximize determinism and simplicity for an internet-scale directed acyclical graph of CBOR documents linked to one another by binary hashes. These simple content identifiers, defined in Appendix A, are always expressed as bytestrings of tag 42 (similar in design to [RFC6920] Named Information Hashes). All other tags, and many major and minor types, are forbidden to reduce ambiguity, and developers are encouraged to express many kinds of data at higher layers by using the supported types (such as strings or bytestrings).1.2. Requirements Language 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.Caballero & Berjon Expires 9 May 2026 [Page 3]Internet-Draft CBOR42 November 20251.3. Common Definitions * This document uses the conventions defined in CDDL [RFC8610] for expressing the type of CBOR [RFC8949] data items. * Examples showing CBOR data, are expressed in "diagnostic notation" as defined in Section 8 of [RFC8949]. * The term "CBOR object" is equivalent to "CBOR data item" used in [RFC8949]. * The term "CBOR Core" is in this document abbreviated to "CBOR/c".2. Specification This section describes how CBOR-42 subsets CBOR and differs from a standard CDE encoding.2.1. Supported CBOR Objects +========+=========================================+ | CBOR | Comment | +========+=========================================+ | int | Integer | +--------+-----------------------------------------+ | float | 64-bit [IEEE754] numbers ONLY | +--------+-----------------------------------------+ | tstr | Text string encoded as UTF-8 [RFC3629] | +--------+-----------------------------------------+ | bstr | Byte string | +--------+-----------------------------------------+ | [] | Array | +--------+-----------------------------------------+ | {} | Map | +--------+-----------------------------------------+ | tag 42 | See Appendix A; no other tags allowed | +--------+-----------------------------------------+ | bool | Boolean true and false (major type 7) | +--------+-----------------------------------------+ | null | Represents a null object (major type 7) | +--------+-----------------------------------------+ Table 1Caballero & Berjon Expires 9 May 2026 [Page 4]Internet-Draft CBOR42 November 20252.2. Deterministic Encoding Scheme Profile As in CBOR/c, deterministic encoding is mandatory. The encoding scheme adheres to Section 4.2 of [RFC8949], but adds a few constraints (denoted below by RFC+), where this RFC offers choices. The following list contains a summary of the deterministic encoding rules: * RFC+: Floating-point and integer objects MUST be treated as distinct types regardless of their numeric value. This is compliant with Rule 2 in Section 4.2.2 of [RFC8949]. * RFC: Integers, represented by the int and bigint types, MUST use the int type if the value is between -2^64 and 2^64-1; otherwise, as with timestamp data, they must be encoded at higher layers, whether as bytestrings or strings. - Appendix B.1 features a list of integer sample values and their expected encoding. * RFC+: UNLIKE CBOR/c and standard CDE encoding, floating-point numbers MUST always be encoded using the longest [IEEE754] variant. Appendix B.2 features a list of floating-point sample values and their expected encoding. * RFC+: NaN values with payloads (like f97e01), or having the most significant bit set ("signaling"), MUST be rejected. See also Appendix B.4 for invalid NaN variants. * RCF+: UNLIKE CBOR/c and standard CDE encoding, map keys MUST be typed as strings; no other types are allowed as map keys. * RFC: Map keys MUST be strings and MUST be sorted "length-first", which (because they are strings) can always be achieved by sorting in bytewise lexicographic order. Duplicate keys (i.e. keys with identical deterministic bytestring values) MUST be rejected. Note that semantic equivalence is not tested. - Since map keys must be strings, the following represents a properly sorted map, whether sorted according to the "Canonical CBOR" algorithm (section (3.9) in [RFC7049]) OR the "deterministically encoded" algorithm (section (4.2.3) in [RFC8949]): { "a": ... , "b": ... , "aa": ... }Caballero & Berjon Expires 9 May 2026 [Page 5]Internet-Draft CBOR42 November 2025 * RFC+: Since CBOR encodings according to this specification maintain uniqueness, there are no specific restrictions or tests needed in order to determine map key equivalence. As an (extreme) example, the floating-point numbers 0.0 and -0.0, and the integer number 0 could all get force-typed as three distinct strings (0.0, -0.0, and 0) without colliding. * RFC: Indefinite length objects MUST be rejected.2.3. CBOR Tool Requirements CBOR-42 is designed to allow hashing and signing in raw form. To make "raw" signing safe and verification of such signatures practical, CBOR tooling capable of the following is required: * It MUST be possible to find out the type of a CBOR object, before it is accessed. * It MUST be possible to add, delete, and update the contents of CBOR map and array objects, of decoded CBOR data. * It MUST be possible to reserialize decoded CBOR data, be it updated or not. * Irrespective of whether CBOR data is decoded, updated, or created programmatically, deterministic encoding MUST be maintained. * Invalid or unsupported CBOR constructs, as well as CBOR data not adhering to the deterministic encoding scheme MUST be rejected. See also Appendix D and Appendix B.4.2.3.1. Protocol Primitives To facilitate cross-platform protocol interoperability, implementers of CBOR-42 compatible tools SHOULD include decoder API support for the following primitives.Caballero & Berjon Expires 9 May 2026 [Page 6]Internet-Draft CBOR42 November 2025 +==========+===========+===================================+======+ | CBOR | Primitive | Comment | Note | +==========+===========+===================================+======+ | int | Int8 | 8-bit signed integer | 1 | +----------+-----------+-----------------------------------+------+ | uint | Uint8 | 8-bit unsigned integer | 1 | +----------+-----------+-----------------------------------+------+ | int | Int16 | 16-bit signed integer | 1 | +----------+-----------+-----------------------------------+------+ | uint | Uint16 | 16-bit unsigned integer | 1 | +----------+-----------+-----------------------------------+------+ | int | Int32 | 32-bit signed integer | 1 | +----------+-----------+-----------------------------------+------+ | uint | Uint32 | 32-bit unsigned integer | 1 | +----------+-----------+-----------------------------------+------+ | int | Int64 | 64-bit signed integer | 1 | +----------+-----------+-----------------------------------+------+ | uint | Uint64 | 64-bit unsigned integer | 1 | +----------+-----------+-----------------------------------+------+ | float | Float64 | 64-bit floating-point number | | +----------+-----------+-----------------------------------+------+ | bool | Boolean | Boolean | | +----------+-----------+-----------------------------------+------+ | null | Null | Null | 2 | +----------+-----------+-----------------------------------+------+ | #7.nnn | Simple | ONLY null, false, true | 3 | +----------+-----------+-----------------------------------+------+ | tstr | String | Text string | | +----------+-----------+-----------------------------------+------+ | bstr | Bytes | Byte string | | +----------+-----------+-----------------------------------+------+ | See note | EpochTime | Time object expressed as a number | 4 | +----------+-----------+-----------------------------------+------+ | See note | DateTime | Time object expressed as a text | 4 | | | | string | | +----------+-----------+-----------------------------------+------+ Table 2 1. Range testing MUST be performed using the traditional ranges for unsigned respectively two-complement numbers. That is, a hypothetical getUint8() MUST reject numbers outside of 0 to 255, whereas a hypothetical getInt8(), MUST reject numbers outside of -128 to 127. 2. Since a CBOR null typically represents the absence of a value, a decoder MUST provide a test-function, like isNull().Caballero & Berjon Expires 9 May 2026 [Page 7]Internet-Draft CBOR42 November 2025 3. Simple values in CBOR and CBOR/c include the ranges 0-23 and 32-255, all but three of which are invalid in CBOR-42; however, the capability to refer to boolean values (i.e. true and false) and null as major-type 7 simple values MUST be supported to guarantee interoperability with CBOR tooling generally. 4. Since CBOR lacks a native-level time object, Section 3.4 of [RFC8949] introduces two variants of time objects using the CBOR tags 0 and 1, neither of which are supported by the CBOR/c-42 data model for historical interoperability reasons. To support time encoding stably, it is RECOMMENDED that EpochTime and/or DateTime types in input be force-typed as strings at the application level or at the ALDR level. Interoperability with other tooling may be difficult to achieve if support for these APIs is desired, and validating dates at higher layers may introduce new security issues at higher layers. If a call does not match the underlying CBOR type, the call MUST be rejected.2.3.2. Media Type Protocols transmitting CBOR-42 over HTTP interfaces are RECOMMENDED to send all CBOR-42 data with a media type header of application/ cbor.2.3.3. CBOR Sequences Concatenating or streaming CBOR objects is strongly discouraged except in contexts where the application/cbor-seq media type can be used to set decoder expectations appropriately. See [RFC8742] for guidance on streaming best practices.3. Security Considerations It is assumed that CBOR-42 has no novel security issues compared to CBOR Deterministic Encoding as defined in [RFC8949] but the authors would appreciate any hypotheses or evidence to the contrary. It should be noted that there has been to date little implementer feedback on the ALDR suggestions outlined in the appendices. As such, these should be considered as an understudied security surface for the application layer to consider.4. IANA Considerations This document requests no IANA actions.Caballero & Berjon Expires 9 May 2026 [Page 8]Internet-Draft CBOR42 November 20255. References5.1. Normative References [IEEE754] "IEEE Standard for Floating-Point Arithmetic", IEEE, DOI 10.1109/ieeestd.2019.8766229, ISBN ["9781504459242"], July 2019, <https://doi.org/10.1109/ieeestd.2019.8766229>. [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>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/rfc/rfc7049>. [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>. [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/rfc/rfc8742>. [RFC8949] 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>.5.2. Informative References [DASL.ING] Berjon, R. and J. Caballero, "DASL Content Identifiers", 2024, <https://dasl.ing/cid.html>. [ECMASCRIPT] "ECMAScript® 2024 Language Specification", n.d., <https://www.ecma- international.org/publications/standards/Ecma-262.htm>.Caballero & Berjon Expires 9 May 2026 [Page 9]Internet-Draft CBOR42 November 2025 [MULTIFORMATS] "Multiformats Community Registry", n.d., <https://github.com/multiformats/multicodec/>. [protobuf] "Encoding rules and MIME type for Protocol Buffers", 2012, <https://www.ietf.org/archive/id/draft-rfernando-protocol- buffers-00.txt>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/rfc/rfc3629>. [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 2011, <https://www.rfc-editor.org/rfc/rfc6256>. [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/rfc/rfc6920>.Appendix A. Binary Content Identifiers A simple hash-based "content identifier" is used to link documents in the graph for which CBOR-42 was designed, and tag 42 was registered specifically for those link identifiers in the IANA registry, "Concise Binary Object Representation (CBOR) Tags" created by Section 9.2 (https://datatracker.ietf.org/doc/html/rfc8949#section- 9.2) of [RFC8949]. Being able to navigate or generate new links in this graph are strictly unrelated concerns and of course optional for a CBOR-42 encoder and decoder, so this entire section is provided informationally for the purposes of making less opaque the bytestrings marked by tag 42. Some CBOR-42 parsers may want to introspect the tag 42 values, if only to know which dereference to other CBOR-42 (or vanilla CBOR) documents. Note: this describes tag-42 values from the perspective of the CBOR documents in which they are embedded; a simpler, "application developer"-oriented overview of content identifiers can be found at [DASL.ING].Caballero & Berjon Expires 9 May 2026 [Page 10]Internet-Draft CBOR42 November 2025 The format consists of a few sigils prepended to a hash of the linked document; there are many possible values for these sigils but these are like CBOR tags, extension points rather than required features of the system. All the sigils and the hash are of variable length, encoded as Self-Delimiting Numeric Values ([RFC6256]). The sequence of segments is as follows: 1. Mandatory padding byte 0x00. This is required for interoperability with non-CBOR CID systems and for historical reasons (see Legacy Support section below). 2. Version byte: 0x01 is the only value to expect in a general- purpose tool. 0x00 refers to a legacy form explained below, with 0x02 and 0x03 reserved for potential future use. 3. A contextualizing sigil roughly mapping to content types taken from a community registry called [MULTIFORMATS]. The only values that all CBOR/c-42 decoders need to recognize are: 1. 0x71 - CBOR/c-42 2. 0x51 - Any other form of CBOR 3. 0x55 - Raw, unstructured binary 4. A hash-function sigil, drawn from the same registry. Likewise, the vast majority of values here are optional extensions; the required hash functions to be aware of are: 1. 0x12 - SHA-256 5. A hash-length (as SDNV). 6. The hash (all remaining bytes).A.1. Legacy Support Any tag 42 value that does NOT begin with 0x00 can be considered malformed, and any attempt to recuperate legacy links or variations from such a value is entirely optional.Caballero & Berjon Expires 9 May 2026 [Page 11]Internet-Draft CBOR42 November 2025 The most common form of legacy data from deprecated encodings is the historical v0 form IPFS content identifiers, which were always 34 bytes long and consisted only of segments 4 (0x12), 5 (0x20, i.e. 32 bytes) and 6 above (a 32-byte SHA256 hash). Prepending 0x00 (padding byte), 0x01 (CID version), 0x70 (DAG-profiled protobuf) turns these into valid "v1" content identifiers, although they still dereference to protobuf objects rather than CBOR objects. For guidance on protobuf deserialization, see protobuf.dev or the relevant [protobuf] draft RFC. Likewise, some specialized applications that can strictly assume segments 1-3 or 1-5 will be invariant systemwide have been observed to use "truncated" content identifiers, prepending the invariant prefixes only in transformations at point of egress for interoperability purposes. This is not best practice but can also serve as some explanation for the padding byte.Appendix B. Test VectorsB.1. Integers +=======================+====================+===================+ | Diagnostic Notation | CBOR Encoding | Comment | +=======================+====================+===================+ | 0 | 00 | Smallest positive | | | | implicit int | +-----------------------+--------------------+-------------------+ | -1 | 20 | Smallest negative | | | | implicit int | +-----------------------+--------------------+-------------------+ | 23 | 17 | Largest positive | | | | implicit int | +-----------------------+--------------------+-------------------+ | -24 | 37 | Largest negative | | | | implicit int | +-----------------------+--------------------+-------------------+ | 24 | 1818 | Smallest positive | | | | one-byte int | +-----------------------+--------------------+-------------------+ | -25 | 3818 | Smallest negative | | | | one-byte int | +-----------------------+--------------------+-------------------+ | 255 | 18ff | Largest positive | | | | one-byte int | +-----------------------+--------------------+-------------------+ | -256 | 38ff | Largest negative | | | | one-byte int | +-----------------------+--------------------+-------------------+Caballero & Berjon Expires 9 May 2026 [Page 12]Internet-Draft CBOR42 November 2025 | 256 | 190100 | Smallest positive | | | | two-byte int | +-----------------------+--------------------+-------------------+ | -257 | 390100 | Smallest negative | | | | two-byte int | +-----------------------+--------------------+-------------------+ | 65535 | 19ffff | Largest positive | | | | two-byte int | +-----------------------+--------------------+-------------------+ | -65536 | 39ffff | Largest negative | | | | two-byte int | +-----------------------+--------------------+-------------------+ | 65536 | 1a00010000 | Smallest positive | | | | four-byte int | +-----------------------+--------------------+-------------------+ | -65537 | 3a00010000 | Smallest negative | | | | four-byte int | +-----------------------+--------------------+-------------------+ | 4294967295 | 1affffffff | Largest positive | | | | four-byte int | +-----------------------+--------------------+-------------------+ | -4294967296 | 3affffffff | Largest negative | | | | four-byte int | +-----------------------+--------------------+-------------------+ | 4294967296 | 1b0000000100000000 | Smallest positive | | | | eight-byte int | +-----------------------+--------------------+-------------------+ | -4294967297 | 3b0000000100000000 | Smallest negative | | | | eight-byte int | +-----------------------+--------------------+-------------------+ | 18446744073709551615 | 1bffffffffffffffff | Largest positive | | | | eight-byte int | +-----------------------+--------------------+-------------------+ | -18446744073709551616 | 3bffffffffffffffff | Largest negative | | | | eight-byte int | +-----------------------+--------------------+-------------------+ Table 3B.2. Floating Point Numbers The textual representation of the values is based on the serialization method for the Number data type, defined by [ECMASCRIPT] with one change: to comply with diagnostic notation (section 8 of [RFC8949]), all values are expressed as floating-point numbers. The rationale for using [ECMASCRIPT] serialization is because it is supposed to generate the shortest and most correct representation of [IEEE754] numbers.Caballero & Berjon Expires 9 May 2026 [Page 13]Internet-Draft CBOR42 November 2025 +=========================+==================+==================+===========+ |Diagnostic Notation |CBOR-42 Encoding |CBOR Encoding |Comment | +=========================+==================+==================+===========+ |0.0 |fb0000000000000000|fb0000000000000000|Zero | +-------------------------+------------------+------------------+-----------+ |-0.0 |fb8000000000000000|fb8000000000000000|Negative | | | | |zero | +-------------------------+------------------+------------------+-----------+ |Infinity |invalid |f97c00 |Infinity | +-------------------------+------------------+------------------+-----------+ |-Infinity |invalid |f9fc00 |Negative | | | | |infinity | +-------------------------+------------------+------------------+-----------+ |NaN |invalid |f97e00 |Not a | | | | |number | +-------------------------+------------------+------------------+-----------+ |5.960464477539063e-8 |fb3e70000000000000|f90001 |Smallest | | | | |positive | | | | |subnormal | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |0.00006097555160522461 |fb3f0ff80000000000|f903ff |Largest | | | | |positive | | | | |subnormal | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |0.00006103515625 |fb3f10000000000000|f90400 |Smallest | | | | |positive | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |65504.0 |fb40effc0000000000|f97bff |Largest | | | | |positive | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |1.401298464324817e-45 |fb36a0000000000000|fa00000001 |Smallest | | | | |positive | | | | |subnormal | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |1.1754942106924411e-38 |fb380fffffc0000000|fa007fffff |Largest | | | | |positive | | | | |subnormal | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |1.1754943508222875e-38 |fb3810000000000000|fa00800000 |Smallest | | | | |positive | | | | |float32 | +-------------------------+------------------+------------------+-----------+Caballero & Berjon Expires 9 May 2026 [Page 14]Internet-Draft CBOR42 November 2025 |3.4028234663852886e+38 |fb47efffffe0000000|fa7f7fffff |Largest | | | | |positive | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |5.0e-324 |fb0000000000000001|fb0000000000000001|Smallest | | | | |positive | | | | |subnormal | | | | |float64 | +-------------------------+------------------+------------------+-----------+ |2.225073858507201e-308 |fb000fffffffffffff|fb000fffffffffffff|Largest | | | | |positive | | | | |subnormal | | | | |float64 | +-------------------------+------------------+------------------+-----------+ |2.2250738585072014e-308 |fb0010000000000000|fb0010000000000000|Smallest | | | | |positive | | | | |float64 | +-------------------------+------------------+------------------+-----------+ |1.7976931348623157e+308 |fb7fefffffffffffff|fb7fefffffffffffff|Largest | | | | |positive | | | | |float64 | +-------------------------+------------------+------------------+-----------+ |-0.0000033333333333333333|fbbecbf647612f3696|fbbecbf647612f3696|Randomly | | | | |selected | | | | |number | +-------------------------+------------------+------------------+-----------+ |10.559998512268066 |fb40251eb820000000|fa4128f5c1 |-"- | +-------------------------+------------------+------------------+-----------+ |10.559998512268068 |fb40251eb820000001|fb40251eb820000001|Next in | | | | |succession | +-------------------------+------------------+------------------+-----------+ |295147905179352830000.0 |fb4430000000000000|fa61800000 |268 | | | | |(diagnostic| | | | |notation | | | | |truncates | | | | |precision) | +-------------------------+------------------+------------------+-----------+ |2.0 |fb4000000000000000|f94000 |Number | | | | |without a | | | | |fractional | | | | |part | +-------------------------+------------------+------------------+-----------+ |-5.960464477539063e-8 |fbbe70000000000000|f98001 |Smallest | | | | |negative | | | | |subnormal | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |-5.960464477539062e-8 |fbbe6fffffffffffff|fbbe6fffffffffffff|Adjacent |Caballero & Berjon Expires 9 May 2026 [Page 15]Internet-Draft CBOR42 November 2025 | | | |smallest | | | | |negative | | | | |subnormal | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |-5.960464477539064e-8 |fbbe70000000000001|fbbe70000000000001|-"- | +-------------------------+------------------+------------------+-----------+ |-5.960465188081798e-8 |fbbe70000020000000|fab3800001 |-"- | +-------------------------+------------------+------------------+-----------+ |0.0000609755516052246 |fb3f0ff7ffffffffff|fb3f0ff7ffffffffff|Adjacent | | | | |largest | | | | |subnormal | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |0.000060975551605224616 |fb3f0ff80000000001|fb3f0ff80000000001|-"- | +-------------------------+------------------+------------------+-----------+ |0.000060975555243203416 |fb3f0ff8002000000 |fa387fc001 |-"- | +-------------------------+------------------+------------------+-----------+ |0.00006103515624999999 |fb3f0fffffffffffff|fb3f0fffffffffffff|Adjacent | | | | |smallest | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |0.00006103515625000001 |fb3f10000000000001|fb3f10000000000001|-"- | +-------------------------+------------------+------------------+-----------+ |0.00006103516352595761 |fb3f10000020000000|fa38800001 |-"- | +-------------------------+------------------+------------------+-----------+ |65503.99999999999 |fb40effbffffffffff|fb40effbffffffffff|Adjacent | | | | |largest | | | | |float16 | +-------------------------+------------------+------------------+-----------+ |65504.00000000001 |fb40effc0000000001|fb40effc0000000001|-"- | +-------------------------+------------------+------------------+-----------+ |65504.00390625 |fb40effc0020000000|fa477fe001 |-"- | +-------------------------+------------------+------------------+-----------+ |1.4012984643248169e-45 |fb369fffffffffffff|fb369fffffffffffff|Adjacent | | | | |smallest | | | | |subnormal | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |1.4012984643248174e-45 |fb36a0000000000001|fb36a0000000000001|-"- | +-------------------------+------------------+------------------+-----------+ |1.175494210692441e-38 |fb380fffffbfffffff|fb380fffffbfffffff|Adjacent | | | | |largest | | | | |subnormal | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |1.1754942106924412e-38 |fb380fffffc0000001|fb380fffffc0000001|-"- | +-------------------------+------------------+------------------+-----------+Caballero & Berjon Expires 9 May 2026 [Page 16]Internet-Draft CBOR42 November 2025 |1.1754943508222874e-38 |fb380fffffffffffff|fb380fffffffffffff|Adjacent | | | | |smallest | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |1.1754943508222878e-38 |fb3810000000000001|fb3810000000000001|-"- | +-------------------------+------------------+------------------+-----------+ |3.4028234663852882e+38 |fb47efffffdfffffff|fb47efffffdfffffff|Adjacent | | | | |largest | | | | |float32 | +-------------------------+------------------+------------------+-----------+ |3.402823466385289e+38 |fb47efffffe0000001|fb47efffffe0000001|-"- | +-------------------------+------------------+------------------+-----------+ Table 4B.3. Miscellaneous Items +=========================+==========================+=============+ |Diagnostic Notation |CBOR Encoding |Comment | +=========================+==========================+=============+ |true |f5 |Boolean true | | | |(allowed | | | |simple value)| +-------------------------+--------------------------+-------------+ |null |f6 |Null (allowed| | | |simple value)| +-------------------------+--------------------------+-------------+ |simple(59) |f83b |Disallowed | | | |simple value | +-------------------------+--------------------------+-------------+ |59 |183b |unsigned | | | |integer | +-------------------------+--------------------------+-------------+ |-59 |383a |signed | | | |integer | +-------------------------+--------------------------+-------------+ |0("2025-03-30T12:24:16Z")|c074323032352d30332d33 | | +-------------------------+--------------------------+-------------+ |305431323a32343a31365a |Disallowed ISO date/time | | +-------------------------+--------------------------+-------------+ |[1, [2, 3], [4, 5]] |8301820203820405 |Array | | | |combinations | +-------------------------+--------------------------+-------------+ |{ "a": 0, "b": 1, "aa": |a361610161620262616103 |Map object | |2} | | | +-------------------------+--------------------------+-------------+ |h'48656c6c6f2043424f5221'|4b48656c6c6f2043424f5221 |Binary string| +-------------------------+--------------------------+-------------+Caballero & Berjon Expires 9 May 2026 [Page 17]Internet-Draft CBOR42 November 2025 |"🚀 science" |6cf09f9a8020736369656e6365|Text string | | | |with emoji | +-------------------------+--------------------------+-------------+ Table 5B.4. Invalid Encodings +==========================+=====================+================+ | CBOR Encoding |Diagnostic Notation |Comment | +==========================+=====================+================+ | a2616201616100 |{ "b": 1, "a": 0 } |Improper map key| | | |ordering | +--------------------------+---------------------+----------------+ | 1900ff |255 |Number with | | | |leading zero | | | |bytes | +--------------------------+---------------------+----------------+ | c34a00010000000000000000 |-18446744073709551617|Number with | | | |leading zero | | | |bytes | +--------------------------+---------------------+----------------+ | Fa41280000 |10.5 |Only 64-bit | | | |floats | +--------------------------+---------------------+----------------+ | c243010000 |65536 |bigints not | | | |allowed | +--------------------------+---------------------+----------------+ | c249010000000000000000 |18446744073709551616 |bigints not | | | |allowed | +--------------------------+---------------------+----------------+ | c349010000000000000000 |-18446744073709551617|bigints not | | | |allowed | +--------------------------+---------------------+----------------+ | fa7fc00000 |NaN |NaNs not allowed| +--------------------------+---------------------+----------------+ | f97e01 |NaN |NaNs not allowed| +--------------------------+---------------------+----------------+ | f97e00 |NaN |NaNs not allowed| +--------------------------+---------------------+----------------+ | 5f4101420203ff |(_ h'01', h'0203') |Indefinite | | | |length object | +--------------------------+---------------------+----------------+ | fc | |Reserved | +--------------------------+---------------------+----------------+ | f818 | |Invalid simple | | | |value | +--------------------------+---------------------+----------------+Caballero & Berjon Expires 9 May 2026 [Page 18]Internet-Draft CBOR42 November 2025 | 5b0010000000000000 | |Extremely large | | | |bstr length | | | |indicator: | | | |4503599627370496| +--------------------------+---------------------+----------------+ Table 6Appendix C. Configuration and ALDRs Someone familiar with the long history of deterministic or canonical CBOR will note that the above specification mixes and matches properties from that history of profiling. This creates three major issues for CBOR parsers that are not highly configurable: 1. The drastically reduced set of types and tags, as well as the requirement that map keys be typed as strings, usually require enforcement at the application layer, i.e. as "ALDR"s. 2. Configuring a generic library to _encode_ CBOR according to this profile's map-sorting requirement, when that library does not support [RFC7049] Canonical-CBOR sort mode (sometimes called "legacy" or "lengthfirst"), can be a substantial burden, and may require implementing that sorting algorithm at the application layer if the parser allows preserving map order in input. 3. Issues around float reduction are harder to triage at the application layer, although many ALDRs and applications that use this encoding (such as that of the Bluesky social network and the data model of its underlying "Authenticated Transfer Protocol") completely sidestep the issue by simply disallowing floats at the CBOR level, or transcoding floats to a "virtual type" at the application layer, e.g. by retyping floats as strings.Appendix D. Decoding Strictness When decoding CBOR data encoded without observing the rules defined above, it recommended that validity rules around allowed types and tags, integer reduction, float reduction, and map sorting follow the looser norms set out in [RFC8949]. A CBOR-42 application or encoder has no obligation to support re-encoding of such non-profile data according to these looser rules, however, and roundtrip-translation is unlikely to be guaranteed as this was a non-goal of the original design.Caballero & Berjon Expires 9 May 2026 [Page 19]Internet-Draft CBOR42 November 2025Acknowledgments The authors would like to thank for their guidance over a long period on this and related projects: * Carsten Bormann * David Buchanan * Cole Capilongo * Paul Hoffman * Dirk Kutscher * Volker Mische * Wolf McNally * Bryan Newbold * Marcin Rataj * Anders Rundgren * Rod VaggAuthors' Addresses Juan Caballero IPFS Foundation Email: bumblefudge@learningproof.xyz Robin Berjon IPFS Foundation Email: robin@berjon.comCaballero & Berjon Expires 9 May 2026 [Page 20]