[Cbor] Re: I-D Action: draft-mcnally-deterministic-cbor-10.html

["lgl island-resort.com" <[e-mail]>]

On Jun 16, 2024, at 7:50 AM, Anders Rundgren <[e-mail]> wrote:

2.3 Numeric Reduction
   To provide deterministic encoding in platforms that do not separate integer
   and floating point values (like JavaScript), numbers must be canonicalized.
   Numeric reduction ensures that semantically equal numeric values (e.g. 2 and 2.0)
   are encoded into identical byte streams (e.g. 0x02) by encoding "Integral floating point values"
   (floating point values with a zero fractional part) as integers when possible.

Since this is the essence of dCBOR, I would drop all other parts of dCBOR, since similar restrictions and limitations can be found in just about any other CBOR-using application as well.

There’s only two other things:

1) requirement to validate (the requirement to validate dCBOR implies validation of CDE which implies the requirement to reject dup map keys).

2) restriction of simple types to true, false and null

Agreed that the numeric reduction is the center of dCBOR, but I don’t mind that these other things are part of it too.

If some protocol wants dCBOR numeric reduction plus the simple value undefined, they can just say so in a specification and it will be OK. Seems like the main problem is that they won’t be able to use the “.dcbor” CDDL control.

That kind of begs the question whether there should be a separate CDDL control  “.float-num_reduce” so someone can say all they want is dCBOR floating point number reduction in CDDL.

LL