Re: [apps-discuss] Concise Binary Object Representation (CBOR)

[Carsten Bormann <[e-mail]>]

On May 22, 2013, at 19:40, Dave Cridland <[e-mail]> wrote:

>  - I'm instantly put on guard by the notion that there are multiple representations for the number 7.

Indeed, the lack of the "unique encoding" property creates heartburn for at least one author of the specification.
(We have gone to considerable length in getting unique encodings in CoAP options.  Even there, we didn't quite succeed.)

One good way to ensure unique encoding for unsigned integers is the o256 encoding documented in Appendix A.4 of http://tools.ietf.org/html/draft-bormann-coap-misc-25

This is just not the right way for CBOR.

> I would in general much prefer to see only one. I admit this may not be possible, or simple - maps, for instance, have no intrinsic ordering, enforcing an integer use the most compact representation is awkward, and so on. But having a canonical representation might well be missed later.

There is a tradeoff between the complexity of the serializer and that of the deserializer.
Complete canonicalization puts the onus on the serializer; e.g., you have to sort the keys of a map before encoding it.
On the other hand, the deserializer knows exactly what to expect when -- if you have seen "b", you know there won't be an "a".

(There is also the use of c14n for signature.  I don't want to go there...)

I think we have the right balance between serializer and deserializer here -- if you have a very constrained serializer, it may be expedient to leave out code for always choosing the shortest representation.  The deserializer already has to have the ability to handle longer representations, so the net value of this design decision is positive.

Grüße, Carsten