RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

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

Area Assignment: app

Errata ID: 4964
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: David Waite
Date Reported: 2017-03-12

Section 3.9 says:

*  If two keys have different lengths, the shorter one sorts

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.

Report New Errata