RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (2)

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

Note: This RFC has been obsoleted by RFC 8949

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

Errata ID: 3764
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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: Held for Document Update (4)

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

Note: This RFC has been obsoleted by RFC 8949

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

Errata ID: 5434
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: LAMBERT David
Date Reported: 2018-07-22
Held for Document Update by: Barry Leiba
Date Held: 2020-07-17

Section E.6 says:

   |               |                         |                         |
   | UBJSON        | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 |
   |               | 42 03                   | 42 03 45                |
   |               |                         |                         |

It should say:

   |               |                         |                         |
   | UBJSON        | 5B 23 55 02 55 01 5B 23 | 5B 55 01 5B 55 02 55 03 |
   |               | 55 02 55 02 55 03       | 5D 5D                   |
   |               |                         |                         |

Notes:

According to UBJSON type specification available at
http://ubjson.org/type-reference/ arrays are encoded with square-brackets '[' and ']', or with '[' followed by '#' to specify the element count.

Errata ID: 5763
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: John Visosky
Date Reported: 2019-06-26
Held for Document Update by: Barry Leiba
Date Held: 2020-07-17

Section 2.4 says:

A tag always applies to the item that is directly followed by it.

It should say:

A tag always applies to the item that directly follows it.

Notes:

The 'it' in the original text refers to the tag, so the sentence reads that the tag follows the item. In fact, the item follows the tag.

Errata ID: 5917
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Faye Amacker
Date Reported: 2019-11-24
Held for Document Update by: Barry Leiba
Date Held: 2019-11-24

Section Appendix A says:

simple(24)                   | 0xf818  

Notes:

This example violates RFC 7049 section 2.3 Floating-Point Numbers and Values with No Content.

The incorrect example in Appendix A clearly uses a value <32 which is not allowed.

First, RFC 7049 section 2.3 has a table that shows:
| 24 | Simple value (value 32..255 in following byte) |

Next, RFC 7049 section 2.3 says:
As with all other major types, the 5-bit value 24 signifies a single-
byte extension: it is followed by an additional byte to represent the
simple value. (To minimize confusion, only the values 32 to 255 are
used.)

Wikipedia is also currently incorrect by having an interpretation based on the incorrect example from RFC 7049 Appendix A instead of the text from RFC 7049 Section 2.3.

Credits: This problem was first reported at https://github.com/fxamacker/cbor/issues/46

Errata ID: 4294
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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.

Status: Rejected (3)

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

Note: This RFC has been obsoleted by RFC 8949

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

Errata ID: 4409
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Jim Schaad
Date Reported: 2015-07-06
Rejected by: Barry Leiba
Date Rejected: 2020-07-17

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

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.

Errata ID: 4964
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:

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



Advanced Search