[MichaelGG]

Can anyone enlighten me on why number equivalency is a good idea? The spec says that even if you're expecting an integer like 0, encoders can decide to use floating point, and things should just work. One of the first statements is that "7" should be able to be represented in multiple ways. That doesn't seem concise.

[arh68]

Hmm, that's not the impression I got. I don't think they're arguing you should use multiple encodings willy nilly. Rather, they're avoiding the limit of exactly 1 encoding for every input (maximum flexibility in the spec).

Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array whose first value is a UTF-8 string, second value is an integer, and subsequent values are zero or more floating-point numbers" or "the item is a map that has byte strings for keys and contains at least one pair whose key is 0xab01".

7 is 7 whether it's uint_8 or uint_32, right?

[arh68]

Also, there's actually a much more relevant section later on in the spec (just got to p18):

   For constrained
   applications, where there is a choice between representing a specific
   number as an integer and as a decimal fraction or bigfloat (such as
   when the exponent is small and non-negative), there is a quality-of-
   implementation expectation that the integer representation is used
   directly.