Search RFCs

RFC Editor

RFC 7049, "Concise Binary Object Representation (CBOR)", October 2013

Note: This RFC has been obsoleted byRFC 8949

Errata ID:4963
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: David Waite
Date Reported: 2017-03-12
Rejected by: Barry Leiba
Date Rejected: 2020-07-17

Section 3.9 says:

   same CBOR output, the following four rules would suffice:   o  Integers must be as small as possible.      *  0 to 23 and -1 to -24 must be expressed in the same byte as the         major type;      *  24 to 255 and -25 to -256 must be expressed only with an         additional uint8_t;      *  256 to 65535 and -257 to -65536 must be expressed only with an         additional uint16_t;      *  65536 to 4294967295 and -65537 to -4294967296 must be expressed         only with an additional uint32_t.   o  The expression of lengths in major types 2 through 5 must be as      short as possible.  The rules for these lengths follow the above      rule for integers.   o  The keys in every map must be sorted lowest value to highest.      Sorting is performed on the bytes of the representation of the key      data items without paying attention to the 3/5 bit splitting for      major types.  (Note that this rule allows maps that have keys of      different types, even though that is probably a bad practice that      could lead to errors in some canonicalization implementations.)      The sorting rules are:      *  If two keys have different lengths, the shorter one sorts         earlier;      *  If two keys have the same length, the one with the lower value         in (byte-wise) lexical order sorts earlier.   o  Indefinite-length items must be made into definite-length items.

It should say:

   same CBOR output, the following four rules would suffice:   1.  Integers must be as small as possible.      *  0 to 23 and -1 to -24 must be expressed in the same byte as the         major type;      *  24 to 255 and -25 to -256 must be expressed only with an         additional uint8_t;      *  256 to 65535 and -257 to -65536 must be expressed only with an         additional uint16_t;      *  65536 to 4294967295 and -65537 to -4294967296 must be expressed         only with an additional uint32_t.   2. The expression of lengths in major types 2 through 5 must be as      short as possible.  The rules for these lengths follow the above      rule for integers.   3. The expression of the tag in major type 6 must be as short as       possible.  The rules for the tag value follow the above rule for      integers.   4. The expression of a simple type must be as short as possible. The       rules for simple types follow the above rules for integers.   5. Indefinite-length items must be made into definite-length items.   6. The keys in every map must be sorted lowest value to highest.      Sorting is performed byte-for-byte on the binary representation      of the key data items, without restrictions on keys having a       common major/minor type.      If two keys of differing binary lengths are compared, the item       with the shortest length sorts first.      Note that this rule allows maps to have keys of different major       types, even though that may be considered a bad practice that      could lead to errors in some canonicalization implementations.       For example, negative integers may binary sort out of order      with respect to positive integers.

Notes:

Several recommended changes, some editorial some technical:

- The items are numbered to indicate an appropriate order. This is recommended because converting items to minimal size and making indefinite-length items into definite length must be done before sorting map entries

- Rules were added for reducing the size of tags (major type 6) and simple types (major type 7).

- Within the sorting section for map entries:
- The original comment about 3/5 bit splitting was unclear, whether it was implying some transform was necessary before sorting the items. This was reworked to indicate that the keys were sorted by binary representation.
- The quoted note about mixed types is made a non-quoted comment. An example is given of negative and positive integers.
--VERIFIER NOTES--
This report has been rejected because this is a change in documented behavior
that would require working groupconsensus. That said, this was taken into account
by the working group during the production of the updated version of RFC 7049.

Report New Errata