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

[Anders Rundgren <[e-mail]>]

On 2024-06-16 19:57, lgl island-resort.com wrote:
> 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).

Wouldn't that better belong to CDE?  Duplicate keys are already invalid CBOR.


> 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.

Assume you have an application that is rather using CDE and it outlaws all simple types except for true, false and null.  Would the authors be encouraged writing a specific profile document and run it trough the IETF?  I hope not.


> 
> 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
>