Re: [Cbor] Deterministic CBOR as a possible DISPATCH item

[Carsten Bormann <[e-mail]>]

> Summary:
> 1. Subset of floating point values.  No "signaling" in NaN.  I fully support that.

This is essentially an application layer restriction, which certainly works fine for many applications.

> 2. Floating point values that can be represented as integers MUST be represented as integers.  

This in essence also is an application layer restriction: It means that the application doesn’t get to distinguish between integer and floating point numbers.
This is close to what we had in mind when we wrote RFC 7049, but what we have found creates headaches for some applications.
But it is certainly something an application can choose to do.

In other words, if the application already converts integral numbers into integers, you can use an RFC8949-compliant deterministic encoder.
The fact that the application delegates this work to the CBOR encoder is just an implementation approach, which I consider valid.
Of course, it doesn’t work with protocols that use the distinction for some semantic purpose — which is an acceptable design limitation.
(I.e., it probably is a good idea not to design things that way…)

Note that an application that wants to see float16 or float32 for all or the majority of its numbers can conceptually truncate the precision before handing the numbers over to a generic deterministic encoder, which will do the right thing then.  Again, some delegation may be possible here.

> I'm not too thrilled of this, it seems like a quirk to change fundamental number type in order to save 2 bytes for values like 0.0, 10, etc.

If you come from a JSON base, where all numbers are floating point, recognizing integral numbers and representing them as integers can make a lot of sense.
So I do have a lot of sympathy with this approach.
But you cannot do this without the application’s consent: The application then cannot use the distinction between major type 0/1/tag 2/3 and major type 7(ai 25/26/27) as a semantic indicator.  Again, this is fine for very many applications.

> The rest is (presumably) 100% compliant with my dCBOR implementation.
> 
> QCBOR does not comply with RFC8949 for floating point data:
> https://github.com/laurencelundblade/QCBOR/issues/131

This certainly can be fixed (code is in the RFC).

Grüße, Carsten