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

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

> On Jun 16, 2024, at 8:31 PM, Anders Rundgren <[e-mail]> wrote:
> 
> 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.

I don’t think so. That would be a very big change from RFC 8949 where CDE is already pretty much defined and because dup detection is one of the more complex and expensive things to in a CBOR decoder in programming environments without a map concept.


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

I hope not too, but I still don’t mind that dCBOR has this restriction. I don’t feel strongly either way.

I also find the whole notion of CBOR application profiles introduced in the CDE document excessive.

LL