Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

["Manger, James H" <[e-mail]>]

draft-bormann-cbor-04 adds text about handling maps with multiple identical keys., but it is contradictory. Section 3.4. "Specifying Keys for Maps" says:

   A CBOR-based protocol should make an intentional decision about what
   to do when a receiving application sees multiple identical keys in a
   map.  A protocol might have a rule that it is not an error to have
   identical keys in a map, and that the receiving application will
   discard all but the last key/value pair for a given key in a map.

   ...

   The CBOR data model for maps does not allow ascribing semantics to
   the order of the key/value pairs in the map representation.  A CBOR-
   based protocol MUST NOT be defined in such a way that changing the
   key/value pair order in a map would change the semantics, apart from
   trivial aspects (cache usage etc.).


A protocol that says "discard all but the last key/value pair for a given key" does change semantics if the key/value pair order is changed so it violates the text saying this "MUST NOT" happen.

Given there is no legacy CBOR data to maintain backward compatibility with, the spec should be clearer that a map with multiple identical keys is always an error. Discarding all but the last pair for a given key is NOT acceptable behaviour for a parser. A note that a streaming parser might not be able to detect duplicates is ok, accompanied by a warning that an application using such a parser will need its own checks for multiple identical keys to avoid unambiguous messages.

Suggestion:

Delete the whole paragraph starting "A CBOR-based protocol should make an intentional decision".

After the sentence "The CBOR data model for maps allows zero or one entries in the map for each specific key", add the following sentences:

   Consequently, a map in which a specific key appears multiple times is not
   a valid CBOR value. A parser MUST NOT accept such a map by keeping just
   one entry for an offending key.


Typo: s/for each a specific key/for each specific key/

--
James Manger