RFC 7049, "Concise Binary Object Representation (CBOR)", October 2013
Note: This RFC has been obsoleted by RFC 8949Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app
Errata ID: 4964
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:
* If two keys have different lengths, the shorter one sorts earlier;
It should say:
I would recommend this rule be struck for the following reasons, and a simple binary comparison regardless of length is used
1. It does not affect sorting order of single type entries, if the other rules around using minimal size are followed. This is because the ranges for representable values based on the 5-bit additional information are consistently increasing. In particular, minimal sized non-negative integers will sort in numerical order in either case
2. It does not affect text sorting. A block of text is length-prefixed already, which means that the bytes representing length will already sort shorter strings ahead of all longer strings
3. Using a simple binary comparison will group a mixed-type map by major type. All string keys will be together, for instance. As an example, a 1-6 character string value today could sort in the middle of a group of integer keys (for sufficiently large integers)
4. For keys which are arrays of items, the shortest length breaks the ability for sorted order to mean anything. For example, an [int x, int y] key will sort by x value then y value if straight binary comparison is used, but will sort in a different manner if length-based sorting is involved due to the potential for large `y`.
This is the use case which I personally am hitting, as my keys are composed of an array with the first element as epoch time.
5. It is not necessary to deal with mixed-length values. Due to several factors including termination of indefinite length items, it is not possible to append binary data to a well-formed CBOR value to get a different well-formed CBOR value. Thus all well-formed keys, if compared byte-for-byte, *will* differ without the need to zero-pad the data.
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.