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

[Anders Rundgren <[e-mail]>]

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

Does that mean that CDE permits duplicate keys?  Since sorting is mandatory in CDE, duplicate key detection should be more or less for free.


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

So do I as well.

BTW, how about NaN payloads in QCBOR?


> 
> LL
> 
> 
> 
>