RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

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

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3764

Status: Verified
Type: Editorial

Reported By: Peter Occil
Date Reported: 2013-10-24
Verifier Name: Barry Leiba
Date Verified: 2013-10-25

Section 2.4.2 says:

   C2                        -- Tag 2
      29                     -- Byte string of length 9
         010000000000000000  -- Bytes content

It should say:

   C2                        -- Tag 2
      49                     -- Byte string of length 9
         010000000000000000  -- Bytes content

Notes:

Major type 2, length 9 is encoded as 0x49, not 0x29.

Errata ID: 3770

Status: Verified
Type: Editorial

Reported By: Peter Klavins
Date Reported: 2013-10-29
Verifier Name: Barry Leiba
Date Verified: 2013-10-31

Section 3.6 says:

   ...
   needed encoding (such as encoding "0" as 0b000_11101 followed by two
   bytes of 0x00) as long as the application can decode an integer of
   ...

It should say:

   ...
   needed encoding (such as encoding "0" as 0b000_11001 followed by two
   bytes of 0x00) as long as the application can decode an integer of
   ...

Notes:

Additional information value for 2-byte unsigned integer is 25, which encodes as 0b11001.

Status: Reported (3)

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

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4409

Status: Reported
Type: Technical

Reported By: Jim Schaad
Date Reported: 2015-07-06

Section 3.9 says:

  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.

It should say:

  The sorting rules are:

      *  If the major types are different, the one with the lower value
          in numerical order sorts earlier.

      *  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.

Notes:

As the rules are currently written, The integer -257 would be sorted after the integer 16 because has a length of 2 rather than a length of 1. First rule says shorter keys sort first. However the text above says the sorting is based on the byte representation of the key.

Errata ID: 4963

Status: Reported
Type: Technical

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

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.

Errata ID: 4964

Status: Reported
Type: Technical

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

Section 3.9 says:

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

It should say:

<removed>

Notes:

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.

Status: Held for Document Update (1)

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

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4294

Status: Held for Document Update
Type: Editorial

Reported By: Eric Myhre
Date Reported: 2015-03-07
Held for Document Update by: Barry Leiba
Date Held: 2015-03-07

Section 2.2.1 says:

   BF           -- Start indefinite-length map
      63        -- First key, UTF-8 string length 3
         46756e --   "Fun"
      F5        -- First value, true
      63        -- Second key, UTF-8 string length 3
         416d74 --   "Amt"
      21        -- -2
      FF        -- "break"

It should say:

   BF           -- Start indefinite-length map
      63        -- First key, UTF-8 string length 3
         46756e --   "Fun"
      F5        -- First value, true
      63        -- Second key, UTF-8 string length 3
         416d74 --   "Amt"
      21        -- Second value, -2
      FF        -- "break"

Notes:

This is only a break in phrasing consistency. There is no technical error.

Report New Errata



Search RFCs
Advanced Search
×