[Cbor] Decoding numbers and compliance verification in dCBOR

[Laurence Lundblade <[e-mail]>]

I understand the reason to have only one possible representation of 0, 1 and such, but it seems like it will complicate the decode implementation a lot.

Typically in decoding you might ask for the next integer or the next float or the next big num. The decode of these is super simple and straight forward in regular CBOR. I imagine in dCBOR you’ll still ask for one of these in the API, but the underlying decoder will have to expect different CBOR types and convert.

For example your might ask to decode the next as a float. The serialized input might have an integer value of 999. The dCBOR decoder will have to expect it and convert to 999.000

Also, the dCBOR decoder will have to check for 0.0000, 1.0000, … (floating point representations of whole integers)  because it is supposed to error out on them. Same for bignums that must be represented as integers. Also, the dCBOR decoder has to check the map sort order.  These checks aren’t necessary for correct decoding of the data or to defend attacks. They’re just there for hygiene in the eco-system — being strict in what you decode.

To me this makes dCBOR somewhat unsuitable for highly constrained devices, though it will depend on the protocol and the device. Ordering variants of CBOR in suitability for highly constrained devices:
— dCBOR — least suitable — requires more processing for integers and compliance verification
— preferred serialization CBOR — suitable — a little more processing 
— non-preferred CBOR — most suitable — can tailor serialization to be the absolute minimum for the use case

Do you really want to require that every dCBOR decoder do the full compliance check? Seems better to just say that decoders SHOULD do all these checks when they are running on non-constrained devices.

LL