draft-ietf-cbor-7049bis-02.txt   draft-ietf-cbor-7049bis-03.txt 
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track P. Hoffman Intended status: Standards Track P. Hoffman
Expires: September 3, 2018 ICANN Expires: March 24, 2019 ICANN
March 02, 2018 September 20, 2018
Concise Binary Object Representation (CBOR) Concise Binary Object Representation (CBOR)
draft-ietf-cbor-7049bis-02 draft-ietf-cbor-7049bis-03
Abstract Abstract
The Concise Binary Object Representation (CBOR) is a data format The Concise Binary Object Representation (CBOR) is a data format
whose design goals include the possibility of extremely small code whose design goals include the possibility of extremely small code
size, fairly small message size, and extensibility without the need size, fairly small message size, and extensibility without the need
for version negotiation. These design goals make it different from for version negotiation. These design goals make it different from
earlier binary serializations such as ASN.1 and MessagePack. earlier binary serializations such as ASN.1 and MessagePack.
Contributing Contributing
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2018. This Internet-Draft will expire on March 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. CBOR Data Models . . . . . . . . . . . . . . . . . . . . . . 7 2. CBOR Data Models . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Extended Generic Data Models . . . . . . . . . . . . . . 7 2.1. Extended Generic Data Models . . . . . . . . . . . . . . 7
2.2. Specific Data Models . . . . . . . . . . . . . . . . . . 8 2.2. Specific Data Models . . . . . . . . . . . . . . . . . . 8
3. Specification of the CBOR Encoding . . . . . . . . . . . . . 9 3. Specification of the CBOR Encoding . . . . . . . . . . . . . 8
3.1. Major Types . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Major Types . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Indefinite Lengths for Some Major Types . . . . . . . . . 11 3.2. Indefinite Lengths for Some Major Types . . . . . . . . . 11
3.2.1. Indefinite-Length Arrays and Maps . . . . . . . . . . 11 3.2.1. Indefinite-Length Arrays and Maps . . . . . . . . . . 11
3.2.2. Indefinite-Length Byte Strings and Text Strings . . . 14 3.2.2. Indefinite-Length Byte Strings and Text Strings . . . 13
3.3. Floating-Point Numbers and Values with No Content . . . . 14 3.3. Floating-Point Numbers and Values with No Content . . . . 14
3.4. Optional Tagging of Items . . . . . . . . . . . . . . . . 16 3.4. Optional Tagging of Items . . . . . . . . . . . . . . . . 16
3.4.1. Date and Time . . . . . . . . . . . . . . . . . . . . 18 3.4.1. Date and Time . . . . . . . . . . . . . . . . . . . . 18
3.4.2. Bignums . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.2. Bignums . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Decimal Fractions and Bigfloats . . . . . . . . . . . 19 3.4.3. Decimal Fractions and Bigfloats . . . . . . . . . . . 19
3.4.4. Content Hints . . . . . . . . . . . . . . . . . . . . 21 3.4.4. Content Hints . . . . . . . . . . . . . . . . . . . . 20
3.4.4.1. Encoded CBOR Data Item . . . . . . . . . . . . . 21 3.4.4.1. Encoded CBOR Data Item . . . . . . . . . . . . . 20
3.4.4.2. Expected Later Encoding for CBOR-to-JSON 3.4.4.2. Expected Later Encoding for CBOR-to-JSON
Converters . . . . . . . . . . . . . . . . . . . 21 Converters . . . . . . . . . . . . . . . . . . . 20
3.4.4.3. Encoded Text . . . . . . . . . . . . . . . . . . 21 3.4.4.3. Encoded Text . . . . . . . . . . . . . . . . . . 21
3.4.5. Self-Describe CBOR . . . . . . . . . . . . . . . . . 22 3.4.5. Self-Describe CBOR . . . . . . . . . . . . . . . . . 21
3.5. CBOR Data Models . . . . . . . . . . . . . . . . . . . . 22 4. Creating CBOR-Based Protocols . . . . . . . . . . . . . . . . 22
4. Creating CBOR-Based Protocols . . . . . . . . . . . . . . . . 24 4.1. CBOR in Streaming Applications . . . . . . . . . . . . . 23
4.1. CBOR in Streaming Applications . . . . . . . . . . . . . 25 4.2. Generic Encoders and Decoders . . . . . . . . . . . . . . 23
4.2. Generic Encoders and Decoders . . . . . . . . . . . . . . 25 4.3. Syntax Errors . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Syntax Errors . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. Incomplete CBOR Data Items . . . . . . . . . . . . . 24
4.3.1. Incomplete CBOR Data Items . . . . . . . . . . . . . 26 4.3.2. Malformed Indefinite-Length Items . . . . . . . . . . 24
4.3.2. Malformed Indefinite-Length Items . . . . . . . . . . 27 4.3.3. Unknown Additional Information Values . . . . . . . . 25
4.3.3. Unknown Additional Information Values . . . . . . . . 27 4.4. Other Decoding Errors . . . . . . . . . . . . . . . . . . 25
4.4. Other Decoding Errors . . . . . . . . . . . . . . . . . . 27 4.5. Handling Unknown Simple Values and Tags . . . . . . . . . 26
4.5. Handling Unknown Simple Values and Tags . . . . . . . . . 28 4.6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.7. Specifying Keys for Maps . . . . . . . . . . . . . . . . 27
4.7. Specifying Keys for Maps . . . . . . . . . . . . . . . . 29 4.7.1. Equivalence of Keys . . . . . . . . . . . . . . . . . 28
4.7.1. Equivalence of Keys . . . . . . . . . . . . . . . . . 30 4.8. Undefined Values . . . . . . . . . . . . . . . . . . . . 29
4.8. Undefined Values . . . . . . . . . . . . . . . . . . . . 31 4.9. Canonical CBOR . . . . . . . . . . . . . . . . . . . . . 29
4.9. Canonical CBOR . . . . . . . . . . . . . . . . . . . . . 31 4.9.1. Length-first map key ordering . . . . . . . . . . . . 31
4.9.1. Length-first map key ordering . . . . . . . . . . . . 33 4.10. Strict Mode . . . . . . . . . . . . . . . . . . . . . . . 32
4.10. Strict Mode . . . . . . . . . . . . . . . . . . . . . . . 34 5. Converting Data between CBOR and JSON . . . . . . . . . . . . 33
5. Converting Data between CBOR and JSON . . . . . . . . . . . . 36 5.1. Converting from CBOR to JSON . . . . . . . . . . . . . . 33
5.1. Converting from CBOR to JSON . . . . . . . . . . . . . . 36 5.2. Converting from JSON to CBOR . . . . . . . . . . . . . . 35
5.2. Converting from JSON to CBOR . . . . . . . . . . . . . . 37 6. Future Evolution of CBOR . . . . . . . . . . . . . . . . . . 36
6. Future Evolution of CBOR . . . . . . . . . . . . . . . . . . 38 6.1. Extension Points . . . . . . . . . . . . . . . . . . . . 36
6.1. Extension Points . . . . . . . . . . . . . . . . . . . . 38 6.2. Curating the Additional Information Space . . . . . . . . 37
6.2. Curating the Additional Information Space . . . . . . . . 39 7. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 37
7. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 40 7.1. Encoding Indicators . . . . . . . . . . . . . . . . . . . 38
7.1. Encoding Indicators . . . . . . . . . . . . . . . . . . . 41 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8.1. Simple Values Registry . . . . . . . . . . . . . . . . . 39
8.1. Simple Values Registry . . . . . . . . . . . . . . . . . 41 8.2. Tags Registry . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Tags Registry . . . . . . . . . . . . . . . . . . . . . . 42 8.3. Media Type ("MIME Type") . . . . . . . . . . . . . . . . 40
8.3. Media Type ("MIME Type") . . . . . . . . . . . . . . . . 42 8.4. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 41
8.4. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 43 8.5. The +cbor Structured Syntax Suffix Registration . . . . . 41
8.5. The +cbor Structured Syntax Suffix Registration . . . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . 44
11.2. Informative References . . . . . . . . . . . . . . . . . 46 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Jump Table . . . . . . . . . . . . . . . . . . . . . 50
Appendix B. Jump Table . . . . . . . . . . . . . . . . . . . . . 52 Appendix C. Pseudocode . . . . . . . . . . . . . . . . . . . . . 53
Appendix C. Pseudocode . . . . . . . . . . . . . . . . . . . . . 55 Appendix D. Half-Precision . . . . . . . . . . . . . . . . . . . 55
Appendix D. Half-Precision . . . . . . . . . . . . . . . . . . . 57
Appendix E. Comparison of Other Binary Formats to CBOR's Design Appendix E. Comparison of Other Binary Formats to CBOR's Design
Objectives . . . . . . . . . . . . . . . . . . . . . 58 Objectives . . . . . . . . . . . . . . . . . . . . . 56
E.1. ASN.1 DER, BER, and PER . . . . . . . . . . . . . . . . . 59 E.1. ASN.1 DER, BER, and PER . . . . . . . . . . . . . . . . . 57
E.2. MessagePack . . . . . . . . . . . . . . . . . . . . . . . 59 E.2. MessagePack . . . . . . . . . . . . . . . . . . . . . . . 57
E.3. BSON . . . . . . . . . . . . . . . . . . . . . . . . . . 60 E.3. BSON . . . . . . . . . . . . . . . . . . . . . . . . . . 58
E.4. UBJSON . . . . . . . . . . . . . . . . . . . . . . . . . 60 E.4. UBJSON . . . . . . . . . . . . . . . . . . . . . . . . . 58
E.5. MSDTP: RFC 713 . . . . . . . . . . . . . . . . . . . . . 60 E.5. MSDTP: RFC 713 . . . . . . . . . . . . . . . . . . . . . 58
E.6. Conciseness on the Wire . . . . . . . . . . . . . . . . . 60 E.6. Conciseness on the Wire . . . . . . . . . . . . . . . . . 58
Appendix F. Changes from RFC 7049 . . . . . . . . . . . . . . . 61 Appendix F. Changes from RFC 7049 . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
There are hundreds of standardized formats for binary representation There are hundreds of standardized formats for binary representation
of structured data (also known as binary serialization formats). Of of structured data (also known as binary serialization formats). Of
those, some are for specific domains of information, while others are those, some are for specific domains of information, while others are
generalized for arbitrary data. In the IETF, probably the best-known generalized for arbitrary data. In the IETF, probably the best-known
formats in the latter category are ASN.1's BER and DER [ASN.1]. formats in the latter category are ASN.1's BER and DER [ASN.1].
The format defined here follows some specific design goals that are The format defined here follows some specific design goals that are
not well met by current formats. The underlying data model is an not well met by current formats. The underlying data model is an
extended version of the JSON data model [RFC7159]. It is important extended version of the JSON data model [RFC8259]. It is important
to note that this is not a proposal that the grammar in RFC 7159 be to note that this is not a proposal that the grammar in RFC 8259 be
extended in general, since doing so would cause a significant extended in general, since doing so would cause a significant
backwards incompatibility with already deployed JSON documents. backwards incompatibility with already deployed JSON documents.
Instead, this document simply defines its own data model that starts Instead, this document simply defines its own data model that starts
from JSON. from JSON.
Appendix E lists some existing binary formats and discusses how well Appendix E lists some existing binary formats and discusses how well
they do or do not fit the design objectives of the Concise Binary they do or do not fit the design objectives of the Concise Binary
Object Representation (CBOR). Object Representation (CBOR).
1.1. Objectives 1.1. Objectives
skipping to change at page 8, line 11 skipping to change at page 8, line 5
This basic generic data model comes pre-extended by the registration This basic generic data model comes pre-extended by the registration
of a number of simple values and tags right in this document, such of a number of simple values and tags right in this document, such
as: as:
o "false", "true", "null", and "undefined" (simple values identified o "false", "true", "null", and "undefined" (simple values identified
by 20..23) by 20..23)
o integer and floating point values with a larger range and o integer and floating point values with a larger range and
precision than the above (tags 2 to 5) precision than the above (tags 2 to 5)
o application data types such as a point in time (tags 1, 0) o application data types such as a point in time or an RFC 3339
date/time string (tags 1, 0)
Further elements of the extended generic data model can be (and have Further elements of the extended generic data model can be (and have
been) defined via the IANA registries created for CBOR. Even if such been) defined via the IANA registries created for CBOR. Even if such
an extension is unknown to a generic encoder or decoder, data items an extension is unknown to a generic encoder or decoder, data items
using that extension can be passed to or from the application by using that extension can be passed to or from the application by
representing them at the interface to the application within the representing them at the interface to the application within the
basic generic data model, i.e., as generic values of a simple type or basic generic data model, i.e., as generic values of a simple type or
generic tagged items. generic tagged items.
In other words, the basic generic data model is stable as defined in In other words, the basic generic data model is stable as defined in
this document, while the extended generic data model expands by the this document, while the extended generic data model expands by the
registration of new simple values or tags, but never shrinks. registration of new simple values or tags, but never shrinks.
While there is a strong expectation that generic encoders and While there is a strong expectation that generic encoders and
decoders can represent "false", "true", and "null" in the form decoders can represent "false", "true", and "null" ("undefined" is
appropriate for their programming environment, implementation of the intentionally omitted) in the form appropriate for their programming
data model extensions created by tags is truly optional and a matter environment, implementation of the data model extensions created by
of implementation quality. tags is truly optional and a matter of implementation quality.
2.2. Specific Data Models 2.2. Specific Data Models
The specific data model for a CBOR-based protocol usually subsets the The specific data model for a CBOR-based protocol usually subsets the
extended generic data model and assigns application semantics to the extended generic data model and assigns application semantics to the
data items within this subset and its components. When documenting data items within this subset and its components. When documenting
such specific data models, where it is desired to specify the types such specific data models, where it is desired to specify the types
of data items, it is preferred to identify the types by their names of data items, it is preferred to identify the types by their names
in the generic data model ("negative integer", "array") instead of by in the generic data model ("negative integer", "array") instead of by
referring to aspects of their CBOR representation ("major type 1", referring to aspects of their CBOR representation ("major type 1",
skipping to change at page 9, line 11 skipping to change at page 9, line 5
duplicates and so invalid, and an encoder could encode integral- duplicates and so invalid, and an encoder could encode integral-
valued floats as integers or vice versa, perhaps to save encoded valued floats as integers or vice versa, perhaps to save encoded
bytes. bytes.
3. Specification of the CBOR Encoding 3. Specification of the CBOR Encoding
A CBOR data item (Section 2) is encoded to or decoded from a byte A CBOR data item (Section 2) is encoded to or decoded from a byte
string as described in this section. The encoding is summarized in string as described in this section. The encoding is summarized in
Table 5. Table 5.
The initial byte of each data item contains both information about The initial byte of each encoded data item contains both information
the major type (the high-order 3 bits, described in Section 3.1) and about the major type (the high-order 3 bits, described in
additional information (the low-order 5 bits). When the value of the Section 3.1) and additional information (the low-order 5 bits).
additional information is less than 24, it is directly used as a Additional information value 31 is used for indefinite-length items,
small unsigned integer. When it is 24 to 27, the additional bytes described in Section 3.2. Additional information values 28 to 30 are
for a variable-length integer immediately follow; the values 24 to 27 reserved for future expansion.
of the additional information specify that its length is a 1-, 2-,
4-, or 8-byte unsigned integer, respectively. Additional information
value 31 is used for indefinite-length items, described in
Section 3.2. Additional information values 28 to 30 are reserved for
future expansion.
In all additional information values, the resulting integer is Additional information values from 0 to 27 describes how to construct
interpreted depending on the major type. It may represent the actual an "argument", possibly consuming additional bytes. For major type 7
data: for example, in integer types, the resulting integer is used and additional information 25 to 27 (floating point numbers), there
for the value itself. It may instead supply length information: for is a special case; in all other cases the additional information
example, in byte strings it gives the length of the byte string data value, possibly combined with following bytes, the argument
that follows. constructed is an unsigned integer.
When the value of the additional information is less than 24, it is
directly used as the argument's value. When it is 24 to 27, the
argument's value is held in the following 1, 2, 4, or 8,
respectively, bytes, in network byte order.
The meaning of this argument depends on the major type. For example,
in major type 0, the argument is the value of the data item itself
(and in major type 1 the value of the data item is computed from the
argument); in major type 2 and 3 it gives the length of the string
data in bytes that follows; and in major types 4 and 5 it is used to
determine the number of data items enclosed.
If the encoded sequence of bytes ends before the end of a data item
would be reached, that encoding is not well-formed. If the encoded
sequence of bytes still has bytes remaining after the outermost
encoded item is parsed, that encoding is not a single well-formed
CBOR item.
A CBOR decoder implementation can be based on a jump table with all A CBOR decoder implementation can be based on a jump table with all
256 defined values for the initial byte (Table 5). A decoder in a 256 defined values for the initial byte (Table 5). A decoder in a
constrained implementation can instead use the structure of the constrained implementation can instead use the structure of the
initial byte and following bytes for more compact code (see initial byte and following bytes for more compact code (see
Appendix C for a rough impression of how this could look). Appendix C for a rough impression of how this could look).
3.1. Major Types 3.1. Major Types
The following lists the major types and the additional information The following lists the major types and the additional information
and other bytes associated with the type. and other bytes associated with the type.
Major type 0: an unsigned integer. The 5-bit additional information Major type 0: an integer in the range 0..2**64-1 inclusive. The
is either the integer itself (for additional information values 0 value of the encoded item is the argument itself. For example,
through 23) or the length of additional data. Additional the integer 10 is denoted as the one byte 0b000_01010 (major type
information 24 means the value is represented in an additional 0, additional information 10). The integer 500 would be
uint8_t, 25 means a uint16_t, 26 means a uint32_t, and 27 means a 0b000_11001 (major type 0, additional information 25) followed by
uint64_t. For example, the integer 10 is denoted as the one byte the two bytes 0x01f4, which is 500 in decimal.
0b000_01010 (major type 0, additional information 10). The
integer 500 would be 0b000_11001 (major type 0, additional
information 25) followed by the two bytes 0x01f4, which is 500 in
decimal.
Major type 1: a negative integer. The encoding follows the rules Major type 1: a negative integer in the range -2**64..-1 inclusive.
for unsigned integers (major type 0), except that the value is The value of the item is -1 minus the argument. For example, the
then -1 minus the encoded unsigned integer. For example, the
integer -500 would be 0b001_11001 (major type 1, additional integer -500 would be 0b001_11001 (major type 1, additional
information 25) followed by the two bytes 0x01f3, which is 499 in information 25) followed by the two bytes 0x01f3, which is 499 in
decimal. decimal.
Major type 2: a byte string. The string's length in bytes is Major type 2: a byte string. The number of bytes in the string is
represented following the rules for positive integers (major type equal to the argument. For example, a byte string whose length is
0). For example, a byte string whose length is 5 would have an 5 would have an initial byte of 0b010_00101 (major type 2,
initial byte of 0b010_00101 (major type 2, additional information additional information 5 for the length), followed by 5 bytes of
5 for the length), followed by 5 bytes of binary content. A byte binary content. A byte string whose length is 500 would have 3
string whose length is 500 would have 3 initial bytes of initial bytes of 0b010_11001 (major type 2, additional information
0b010_11001 (major type 2, additional information 25 to indicate a 25 to indicate a two-byte length) followed by the two bytes 0x01f4
two-byte length) followed by the two bytes 0x01f4 for a length of for a length of 500, followed by 500 bytes of binary content.
500, followed by 500 bytes of binary content.
Major type 3: a text string, specifically a string of Unicode Major type 3: a text string (Section 2), encoded as UTF-8
characters that is encoded as UTF-8 [RFC3629]. The format of this ([RFC3629]). The number of bytes in the string is equal to the
type is identical to that of byte strings (major type 2), that is, argument. A string containing an invalid UTF-8 sequence is well-
as with major type 2, the length gives the number of bytes. This formed but invalid. This type is provided for systems that need
type is provided for systems that need to interpret or display to interpret or display human-readable text, and allows the
human-readable text, and allows the differentiation between differentiation between unstructured bytes and text that has a
unstructured bytes and text that has a specified repertoire and specified repertoire and encoding. In contrast to formats such as
encoding. In contrast to formats such as JSON, the Unicode JSON, the Unicode characters in this type are never escaped.
characters in this type are never escaped. Thus, a newline Thus, a newline character (U+000A) is always represented in a
character (U+000A) is always represented in a string as the byte string as the byte 0x0a, and never as the bytes 0x5c6e (the
0x0a, and never as the bytes 0x5c6e (the characters "\" and "n") characters "\" and "n") or as 0x5c7530303061 (the characters "\",
or as 0x5c7530303061 (the characters "\", "u", "0", "0", "0", and "u", "0", "0", "0", and "a").
"a").
Major type 4: an array of data items. Arrays are also called lists, Major type 4: an array of data items. Arrays are also called lists,
sequences, or tuples. The array's length follows the rules for sequences, or tuples. The argument is the number of data items in
byte strings (major type 2), except that the length denotes the the array. Items in an array do not need to all be of the same
number of data items, not the length in bytes that the array takes type. For example, an array that contains 10 items of any type
up. Items in an array do not need to all be of the same type. would have an initial byte of 0b100_01010 (major type of 4,
For example, an array that contains 10 items of any type would additional information of 10 for the length) followed by the 10
have an initial byte of 0b100_01010 (major type of 4, additional remaining items.
information of 10 for the length) followed by the 10 remaining
items.
Major type 5: a map of pairs of data items. Maps are also called Major type 5: a map of pairs of data items. Maps are also called
tables, dictionaries, hashes, or objects (in JSON). A map is tables, dictionaries, hashes, or objects (in JSON). A map is
comprised of pairs of data items, each pair consisting of a key comprised of pairs of data items, each pair consisting of a key
that is immediately followed by a value. The map's length follows that is immediately followed by a value. The argument is the
the rules for byte strings (major type 2), except that the length number of _pairs_ of data items in the map. For example, a map
denotes the number of pairs, not the length in bytes that the map that contains 9 pairs would have an initial byte of 0b101_01001
takes up. For example, a map that contains 9 pairs would have an (major type of 5, additional information of 9 for the number of
initial byte of 0b101_01001 (major type of 5, additional pairs) followed by the 18 remaining items. The first item is the
information of 9 for the number of pairs) followed by the 18 first key, the second item is the first value, the third item is
remaining items. The first item is the first key, the second item the second key, and so on. A map that has duplicate keys may be
is the first value, the third item is the second key, and so on. well-formed, but it is not valid, and thus it causes indeterminate
A map that has duplicate keys may be well-formed, but it is not decoding; see also Section 4.7.
valid, and thus it causes indeterminate decoding; see also
Section 4.7.
Major type 6: optional semantic tagging of other major types. See Major type 6: a tagged data item whose tag is the argument and whose
Section 3.4. value is the single following encoded item. See Section 3.4.
Major type 7: floating-point numbers and simple data types that need Major type 7: floating-point numbers and simple values, as well as
no content, as well as the "break" stop code. See Section 3.3. the "break" stop code. See Section 3.3.
These eight major types lead to a simple table showing which of the These eight major types lead to a simple table showing which of the
256 possible values for the initial byte of a data item are used 256 possible values for the initial byte of a data item are used
(Table 5). (Table 5).
In major types 6 and 7, many of the possible values are reserved for In major types 6 and 7, many of the possible values are reserved for
future specification. See Section 8 for more information on these future specification. See Section 8 for more information on these
values. values.
3.2. Indefinite Lengths for Some Major Types 3.2. Indefinite Lengths for Some Major Types
skipping to change at page 16, line 42 skipping to change at page 16, line 22
encode Null as the two-byte sequence of 0xf816, and MUST NOT encode encode Null as the two-byte sequence of 0xf816, and MUST NOT encode
Undefined value as the two-byte sequence of 0xf817. A decoder MUST Undefined value as the two-byte sequence of 0xf817. A decoder MUST
treat these two-byte sequences as an error. Similar prohibitions treat these two-byte sequences as an error. Similar prohibitions
apply to the unassigned simple values as well. apply to the unassigned simple values as well.
3.4. Optional Tagging of Items 3.4. Optional Tagging of Items
In CBOR, a data item can optionally be preceded by a tag to give it In CBOR, a data item can optionally be preceded by a tag to give it
additional semantics while retaining its structure. The tag is major additional semantics while retaining its structure. The tag is major
type 6, and represents an integer number as indicated by the tag's type 6, and represents an integer number as indicated by the tag's
integer value; the (sole) data item is carried as content data. If a argument (Section 3); the (sole) data item is carried as content
tag requires structured data, this structure is encoded into the data. If a tag requires structured data, this structure is encoded
nested data item. The definition of a tag usually restricts what into the nested data item. The definition of a tag usually restricts
kinds of nested data item or items can be carried by a tag. what kinds of nested data item or items are valid.
The initial bytes of the tag follow the rules for positive integers The initial bytes of the tag follow the rules for positive integers
(major type 0). The tag is followed by a single data item of any (major type 0). The tag is followed by a single data item of any
type. For example, assume that a byte string of length 12 is marked type. For example, assume that a byte string of length 12 is marked
with a tag to indicate it is a positive bignum (Section 3.4.2). This with a tag to indicate it is a positive bignum (Section 3.4.2). This
would be marked as 0b110_00010 (major type 6, additional information would be marked as 0b110_00010 (major type 6, additional information
2 for the tag) followed by 0b010_01100 (major type 2, additional 2 for the tag) followed by 0b010_01100 (major type 2, additional
information of 12 for the length) followed by the 12 bytes of the information of 12 for the length) followed by the 12 bytes of the
bignum. bignum.
skipping to change at page 22, line 4 skipping to change at page 21, line 27
other ways to encode binary data in strings. other ways to encode binary data in strings.
3.4.4.3. Encoded Text 3.4.4.3. Encoded Text
Some text strings hold data that have formats widely used on the Some text strings hold data that have formats widely used on the
Internet, and sometimes those formats can be validated and presented Internet, and sometimes those formats can be validated and presented
to the application in appropriate form by the decoder. There are to the application in appropriate form by the decoder. There are
tags for some of these formats. tags for some of these formats.
o Tag 32 is for URIs, as defined in [RFC3986]; o Tag 32 is for URIs, as defined in [RFC3986];
o Tags 33 and 34 are for base64url- and base64-encoded text strings, o Tags 33 and 34 are for base64url- and base64-encoded text strings,
as defined in [RFC4648]; as defined in [RFC4648];
o Tag 35 is for regular expressions in Perl Compatible Regular o Tag 35 is for regular expressions that are roughly in Perl
Expressions (PCRE) / JavaScript syntax [ECMA262]. Compatible Regular Expressions (PCRE/PCRE2) form [PCRE] or a
version of the JavaScript regular expression syntax [ECMA262].
(Note that more specific identification may be necessary if the
actual version of the specification underlying the regular
expression, or more than just the text of the regular expression
itself, need to be conveyed.)
o Tag 36 is for MIME messages (including all headers), as defined in o Tag 36 is for MIME messages (including all headers), as defined in
[RFC2045]; [RFC2045];
Note that tags 33 and 34 differ from 21 and 22 in that the data is Note that tags 33 and 34 differ from 21 and 22 in that the data is
transported in base-encoded form for the former and in raw byte transported in base-encoded form for the former and in raw byte
string form for the latter. string form for the latter.
3.4.5. Self-Describe CBOR 3.4.5. Self-Describe CBOR
skipping to change at page 22, line 44 skipping to change at page 22, line 25
use as a distinguishing mark for frequently used file types. In use as a distinguishing mark for frequently used file types. In
particular, it is not a valid start of a Unicode text in any Unicode particular, it is not a valid start of a Unicode text in any Unicode
encoding if followed by a valid CBOR data item. encoding if followed by a valid CBOR data item.
For instance, a decoder might be able to parse both CBOR and JSON. For instance, a decoder might be able to parse both CBOR and JSON.
Such a decoder would need to mechanically distinguish the two Such a decoder would need to mechanically distinguish the two
formats. An easy way for an encoder to help the decoder would be to formats. An easy way for an encoder to help the decoder would be to
tag the entire CBOR item with tag 55799, the serialization of which tag the entire CBOR item with tag 55799, the serialization of which
will never be found at the beginning of a JSON text. will never be found at the beginning of a JSON text.
3.5. CBOR Data Models
CBOR is explicit about its generic data model, which defines the set
of all data items that can be represented in CBOR. Its basic generic
data model is extensible by the registration of simple type values
and tags. Applications can then subset the resulting extended
generic data model to build their specific data models.
Within environments that can represent the data items in the generic
data model, generic CBOR encoders and decoders can be implemented
(which usually involves defining additional implementation data types
for those data items that do not already have a natural
representation in the environment). The ability to provide generic
encoders and decoders is an explicit design goal of CBOR; however
many applications will provide their own application-specific
encoders and/or decoders.
In the basic (un-extended) generic data model, a data item is one of:
o an integer in the range -2**64..2**64-1 inclusive
o a simple value, identified by a number between 0 and 255, but
distinct from that number
o a floating point value, distinct from an integer, out of the set
representable by IEEE 754 binary64 (including non-finites)
o a sequence of zero or more bytes ("byte string")
o a sequence of zero or more Unicode code points ("text string")
o a sequence of zero or more data items ("array")
o a mapping (mathematical function) from zero or more data items
("keys") each to a data item ("values"), ("map")
o a tagged data item, comprising a tag (an integer in the range
0..2**64-1) and a value (a data item)
Note that integer and floating-point values are distinct in this
model, even if they have the same numeric value.
This basic generic data model comes pre-extended by the registration
of a number of simple values and tags right in this document, such
as:
o "false", "true", "null", and "undefined" (simple values identified
by 20..23)
o integer and floating point values with a larger range and
precision than the above (tags 2 to 5)
o application data types such as a point in time or an RFC 3339
date/time string (tags 1, 0)
Further elements of the extended generic data model can be (and have
been) defined via the IANA registries created for CBOR. Even if such
an extension is unknown to a generic encoder or decoder, data items
using that extension can be passed to or from the application by
representing them at the interface to the application within the
basic generic data model, i.e., as generic values of a simple type or
generic tagged items.
In other words, the basic generic data model is stable as defined in
this document, while the extended generic data model expands by the
registration of new simple values or tags, but never shrinks.
While there is a strong expectation that generic encoders and
decoders can represent "false", "true", and "null" ("undefined" is
intentionally omitted) in the form appropriate for their programming
environment, implementation of the data model extensions created by
tags is truly optional and a matter of implementation quality.
A specific data model usually subsets the extended generic data model
and assigns application semantics to the data items within this
subset and its components. When documenting such specific data
models, where it is desired to specify the types of data items, it is
preferred to identify the types by their names in the generic data
model ("negative integer", "array") instead of by referring to
aspects of their CBOR representation ("major type 1", "major type
4").
4. Creating CBOR-Based Protocols 4. Creating CBOR-Based Protocols
Data formats such as CBOR are often used in environments where there Data formats such as CBOR are often used in environments where there
is no format negotiation. A specific design goal of CBOR is to not is no format negotiation. A specific design goal of CBOR is to not
need any included or assumed schema: a decoder can take a CBOR item need any included or assumed schema: a decoder can take a CBOR item
and decode it with no other knowledge. and decode it with no other knowledge.
Of course, in real-world implementations, the encoder and the decoder Of course, in real-world implementations, the encoder and the decoder
will have a shared view of what should be in a CBOR data item. For will have a shared view of what should be in a CBOR data item. For
example, an agreed-to format might be "the item is an array whose example, an agreed-to format might be "the item is an array whose
skipping to change at page 29, line 37 skipping to change at page 27, line 26
interwork with JSON-based applications, keys probably should be interwork with JSON-based applications, keys probably should be
limited to UTF-8 strings only; otherwise, there has to be a specified limited to UTF-8 strings only; otherwise, there has to be a specified
mapping from the other CBOR types to Unicode characters, and this mapping from the other CBOR types to Unicode characters, and this
often leads to implementation errors. In applications where keys are often leads to implementation errors. In applications where keys are
numeric in nature and numeric ordering of keys is important to the numeric in nature and numeric ordering of keys is important to the
application, directly using the numbers for the keys is useful. application, directly using the numbers for the keys is useful.
If multiple types of keys are to be used, consideration should be If multiple types of keys are to be used, consideration should be
given to how these types would be represented in the specific given to how these types would be represented in the specific
programming environments that are to be used. For example, in programming environments that are to be used. For example, in
JavaScript objects, a key of integer 1 cannot be distinguished from a JavaScript Maps [ECMA262], a key of integer 1 cannot be distinguished
key of string "1". This means that, if integer keys are used, the from a key of floating point 1.0. This means that, if integer keys
simultaneous use of string keys that look like numbers needs to be are used, the protocol needs to avoid use of floating-point keys the
avoided. Again, this leads to the conclusion that keys should be of values of which happen to be integer numbers in the same map.
a single CBOR type.
Decoders that deliver data items nested within a CBOR data item Decoders that deliver data items nested within a CBOR data item
immediately on decoding them ("streaming decoders") often do not keep immediately on decoding them ("streaming decoders") often do not keep
the state that is necessary to ascertain uniqueness of a key in a the state that is necessary to ascertain uniqueness of a key in a
map. Similarly, an encoder that can start encoding data items before map. Similarly, an encoder that can start encoding data items before
the enclosing data item is completely available ("streaming encoder") the enclosing data item is completely available ("streaming encoder")
may want to reduce its overhead significantly by relying on its data may want to reduce its overhead significantly by relying on its data
source to maintain uniqueness. source to maintain uniqueness.
A CBOR-based protocol should make an intentional decision about what A CBOR-based protocol should make an intentional decision about what
to do when a receiving application does see multiple identical keys to do when a receiving application does see multiple identical keys
in a map. The resulting rule in the protocol should respect the CBOR in a map. The resulting rule in the protocol should respect the CBOR
data model: it cannot prescribe a specific handling of the entries data model: it cannot prescribe a specific handling of the entries
with the identical keys, except that it might have a rule that having with the identical keys, except that it might have a rule that having
identical keys in a map indicates a malformed map and that the identical keys in a map indicates a malformed map and that the
decoder has to stop with an error. Duplicate keys are also decoder has to stop with an error. Duplicate keys are also
prohibited by CBOR decoders that are using strict mode prohibited by CBOR decoders that are using strict mode
(Section 4.10). (Section 4.10).
The CBOR data model for maps does not allow ascribing semantics to The CBOR data model for maps does not allow ascribing semantics to
the order of the key/value pairs in the map representation. Thus, it the order of the key/value pairs in the map representation. Thus, a
would be a very bad practice to define a CBOR-based protocol in such CBOR-based protocol MUST NOT specify that changing the key/value pair
a way that changing the key/value pair order in a map would change order in a map would change the semantics, except to specify that
the semantics, apart from trivial aspects (cache usage, etc.). (A some, e.g. non-canonical, orders are disallowed. Timing, cache
CBOR-based protocol can prescribe a specific order of serialization, usage, and other side channels are not considered part of the
such as for canonicalization.) semantics.
Applications for constrained devices that have maps with 24 or fewer Applications for constrained devices that have maps with 24 or fewer
frequently used keys should consider using small integers (and those frequently used keys should consider using small integers (and those
with up to 48 frequently used keys should consider also using small with up to 48 frequently used keys should consider also using small
negative integers) because the keys can then be encoded in a single negative integers) because the keys can then be encoded in a single
byte. byte.
4.7.1. Equivalence of Keys 4.7.1. Equivalence of Keys
This notion of equivalence must be used to determine whether keys in This notion of equivalence must be used to determine whether keys in
skipping to change at page 32, line 32 skipping to change at page 30, line 17
4. "z", encoded as 0x617a. 4. "z", encoded as 0x617a.
5. "aa", encoded as 0x626161. 5. "aa", encoded as 0x626161.
6. [100], encoded as 0x811864. 6. [100], encoded as 0x811864.
7. [-1], encoded as 0x8120. 7. [-1], encoded as 0x8120.
8. false, encoded as 0xf4. 8. false, encoded as 0xf4.
o Indefinite-length items MUST not appear. They can be encoded as o Indefinite-length items MUST NOT appear. They can be encoded as
definite-length items instead. definite-length items instead.
If a protocol allows for IEEE floats, then additional If a protocol allows for IEEE floats, then additional
canonicalization rules might need to be added. One example rule canonicalization rules might need to be added. One example rule
might be to have all floats start as a 64-bit float, then do a test might be to have all floats start as a 64-bit float, then do a test
conversion to a 32-bit float; if the result is the same numeric conversion to a 32-bit float; if the result is the same numeric
value, use the shorter value and repeat the process with a test value, use the shorter value and repeat the process with a test
conversion to a 16-bit float. (This rule selects 16-bit float for conversion to a 16-bit float. (This rule selects 16-bit float for
positive and negative Infinity as well.) Also, there are many positive and negative Infinity as well.) Also, there are many
representations for NaN. If NaN is an allowed value, it must always representations for NaN. If NaN is an allowed value, it must always
skipping to change at page 36, line 30 skipping to change at page 34, line 10
advice deals with these by converting them to a single substitute advice deals with these by converting them to a single substitute
value, such as a JSON null. value, such as a JSON null.
o An integer (major type 0 or 1) becomes a JSON number. o An integer (major type 0 or 1) becomes a JSON number.
o A byte string (major type 2) that is not embedded in a tag that o A byte string (major type 2) that is not embedded in a tag that
specifies a proposed encoding is encoded in base64url without specifies a proposed encoding is encoded in base64url without
padding and becomes a JSON string. padding and becomes a JSON string.
o A UTF-8 string (major type 3) becomes a JSON string. Note that o A UTF-8 string (major type 3) becomes a JSON string. Note that
JSON requires escaping certain characters (RFC 7159, Section 7): JSON requires escaping certain characters ([RFC8259], Section 7):
quotation mark (U+0022), reverse solidus (U+005C), and the "C0 quotation mark (U+0022), reverse solidus (U+005C), and the "C0
control characters" (U+0000 through U+001F). All other characters control characters" (U+0000 through U+001F). All other characters
are copied unchanged into the JSON UTF-8 string. are copied unchanged into the JSON UTF-8 string.
o An array (major type 4) becomes a JSON array. o An array (major type 4) becomes a JSON array.
o A map (major type 5) becomes a JSON object. This is possible o A map (major type 5) becomes a JSON object. This is possible
directly only if all keys are UTF-8 strings. A converter might directly only if all keys are UTF-8 strings. A converter might
also convert other keys into UTF-8 strings (such as by converting also convert other keys into UTF-8 strings (such as by converting
integers into strings containing their decimal representation); integers into strings containing their decimal representation);
skipping to change at page 40, line 20 skipping to change at page 37, line 51
human-readable diagnostic notation. All actual interchange always human-readable diagnostic notation. All actual interchange always
happens in the binary format. happens in the binary format.
Note that this truly is a diagnostic format; it is not meant to be Note that this truly is a diagnostic format; it is not meant to be
parsed. Therefore, no formal definition (as in ABNF) is given in parsed. Therefore, no formal definition (as in ABNF) is given in
this document. (Implementers looking for a text-based format for this document. (Implementers looking for a text-based format for
representing CBOR data items in configuration files may also want to representing CBOR data items in configuration files may also want to
consider YAML [YAML].) consider YAML [YAML].)
The diagnostic notation is loosely based on JSON as it is defined in The diagnostic notation is loosely based on JSON as it is defined in
RFC 7159, extending it where needed. RFC 8259, extending it where needed.
The notation borrows the JSON syntax for numbers (integer and The notation borrows the JSON syntax for numbers (integer and
floating point), True (>true<), False (>false<), Null (>null<), UTF-8 floating point), True (>true<), False (>false<), Null (>null<), UTF-8
strings, arrays, and maps (maps are called objects in JSON; the strings, arrays, and maps (maps are called objects in JSON; the
diagnostic notation extends JSON here by allowing any data item in diagnostic notation extends JSON here by allowing any data item in
the key position). Undefined is written >undefined< as in the key position). Undefined is written >undefined< as in
JavaScript. The non-finite floating-point numbers Infinity, JavaScript. The non-finite floating-point numbers Infinity,
-Infinity, and NaN are written exactly as in this sentence (this is -Infinity, and NaN are written exactly as in this sentence (this is
also a way they can be written in JavaScript, although JSON does not also a way they can be written in JavaScript, although JSON does not
allow them). A tagged item is written as an integer number for the allow them). A tagged item is written as an integer number for the
skipping to change at page 41, line 40 skipping to change at page 39, line 21
encoding indicator "_" is thus an abbreviation of the full form "_7", encoding indicator "_" is thus an abbreviation of the full form "_7",
which is not used.) which is not used.)
As a special case, byte and text strings of indefinite length can be As a special case, byte and text strings of indefinite length can be
notated in the form (_ h'0123', h'4567') and (_ "foo", "bar"). notated in the form (_ h'0123', h'4567') and (_ "foo", "bar").
8. IANA Considerations 8. IANA Considerations
IANA has created two registries for new CBOR values. The registries IANA has created two registries for new CBOR values. The registries
are separate, that is, not under an umbrella registry, and follow the are separate, that is, not under an umbrella registry, and follow the
rules in [RFC5226]. IANA has also assigned a new MIME media type and rules in [RFC8126]. IANA has also assigned a new MIME media type and
an associated Constrained Application Protocol (CoAP) Content-Format an associated Constrained Application Protocol (CoAP) Content-Format
entry. entry.
8.1. Simple Values Registry 8.1. Simple Values Registry
IANA has created the "Concise Binary Object Representation (CBOR) IANA has created the "Concise Binary Object Representation (CBOR)
Simple Values" registry. The initial values are shown in Table 2. Simple Values" registry. The initial values are shown in Table 2.
New entries in the range 0 to 19 are assigned by Standards Action. New entries in the range 0 to 19 are assigned by Standards Action.
It is suggested that these Standards Actions allocate values starting It is suggested that these Standards Actions allocate values starting
skipping to change at page 45, line 42 skipping to change at page 43, line 21
This document also incorporates suggestions made by many people, This document also incorporates suggestions made by many people,
notably Dan Frost, James Manger, Joe Hildebrand, Keith Moore, Matthew notably Dan Frost, James Manger, Joe Hildebrand, Keith Moore, Matthew
Lepinski, Nico Williams, Phillip Hallam-Baker, Ray Polk, Tim Bray, Lepinski, Nico Williams, Phillip Hallam-Baker, Ray Polk, Tim Bray,
Tony Finch, Tony Hansen, and Yaron Sheffer. Tony Finch, Tony Hansen, and Yaron Sheffer.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ECMA262] European Computer Manufacturers Association, "ECMAScript [ECMA262] Ecma International, "ECMAScript 2018 Language
Language Specification 5.1 Edition", ECMA Standard ECMA- Specification", ECMA Standard ECMA-262, 9th Edition, June
262, June 2011, <http://www.ecma- 2018, <https://www.ecma-
international.org/publications/files/ecma-st/ international.org/publications/files/ECMA-ST/
ECMA-262.pdf>. Ecma-262.pdf>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 46, line 31 skipping to change at page 44, line 13
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <https://www.rfc-editor.org/info/rfc4287>. December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
IANA Considerations Section in RFCs", RFC 5226, Writing an IANA Considerations Section in RFCs", BCP 26,
DOI 10.17487/RFC5226, May 2008, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc8126>.
[TIME_T] The Open Group Base Specifications, "Vol. 1: Base [TIME_T] The Open Group Base Specifications, "Vol. 1: Base
Definitions, Issue 7", Section 4.15 'Seconds Since the Definitions, Issue 7", Section 4.15 'Seconds Since the
Epoch', IEEE Std 1003.1, 2013 Edition, 2013, Epoch', IEEE Std 1003.1, 2013 Edition, 2013,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
V1_chap04.html#tag_04_15>. V1_chap04.html#tag_04_15>.
11.2. Informative References 11.2. Informative References
[ASN.1] International Telecommunication Union, "Information [ASN.1] International Telecommunication Union, "Information
skipping to change at page 47, line 8 skipping to change at page 44, line 38
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[BSON] Various, "BSON - Binary JSON", 2013, [BSON] Various, "BSON - Binary JSON", 2013,
<http://bsonspec.org/>. <http://bsonspec.org/>.
[MessagePack] [MessagePack]
Furuhashi, S., "MessagePack", 2013, <http://msgpack.org/>. Furuhashi, S., "MessagePack", 2013, <http://msgpack.org/>.
[PCRE] Hazel, P., "PCRE - Perl Compatible Regular Expressions",
2018, <http://www.pcre.org/>.
[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission [RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission
Protocol", RFC 713, DOI 10.17487/RFC0713, April 1976, Protocol", RFC 713, DOI 10.17487/RFC0713, April 1976,
<https://www.rfc-editor.org/info/rfc713>. <https://www.rfc-editor.org/info/rfc713>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[UBJSON] The Buzz Media, "Universal Binary JSON Specification", [UBJSON] The Buzz Media, "Universal Binary JSON Specification",
2013, <http://ubjson.org/>. 2013, <http://ubjson.org/>.
[YAML] Ben-Kiki, O., Evans, C., and I. Net, "YAML Ain't Markup [YAML] Ben-Kiki, O., Evans, C., and I. Net, "YAML Ain't Markup
Language (YAML[TM]) Version 1.2", 3rd Edition, October Language (YAML[TM]) Version 1.2", 3rd Edition, October
2009, <http://www.yaml.org/spec/1.2/spec.html>. 2009, <http://www.yaml.org/spec/1.2/spec.html>.
Appendix A. Examples Appendix A. Examples
The following table provides some CBOR-encoded values in hexadecimal The following table provides some CBOR-encoded values in hexadecimal
skipping to change at page 61, line 35 skipping to change at page 59, line 35
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
Table 6: Examples for Different Levels of Conciseness Table 6: Examples for Different Levels of Conciseness
Appendix F. Changes from RFC 7049 Appendix F. Changes from RFC 7049
The following is a list of known changes from RFC 7049. This list is The following is a list of known changes from RFC 7049. This list is
non-authoritative. It is meant to help reviewers see the significant non-authoritative. It is meant to help reviewers see the significant
differences. differences.
o Updated reference for [RFC4267] to [RFC7159] in many places o Updated reference for [RFC4267] to [RFC8259] in many places
o Updated reference for [CNN-TERMS] to [RFC7228] o Updated reference for [CNN-TERMS] to [RFC7228]
o Added a comment to the last example in Section 2.2.1 (added o Added a comment to the last example in Section 2.2.1 (added
"Second value") "Second value")
o Fixed a bug in the example in Section 2.4.2 ("29" -> "49") o Fixed a bug in the example in Section 2.4.2 ("29" -> "49")
o Fixed a bug in the last paragraph of Section 3.6 ("0b000_11101" -> o Fixed a bug in the last paragraph of Section 3.6 ("0b000_11101" ->
"0b000_11001") "0b000_11001")
 End of changes. 40 change blocks. 
260 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/