RFC Errata
RFC 7049, "Concise Binary Object Representation (CBOR)", October 2013
Note: This RFC has been obsoleted by RFC 8949
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
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.