Re: [Cbor] Implementing float->int numeric reduction

[Anders Rundgren <[e-mail]>]

On 2023-08-16 10:08, Carsten Bormann wrote:
>>
>> Did I got this right, the "Common CBOR Deterministic Encoding Profile" is incompatible with "Gordian dCBOR"?
> 
> That, of course, depends on what your definition of incompatible is.
> 
> The Common CBOR Deterministic Encoding Profile essentially clarifies actually using the recommended handling of floating point values from Section 4.2.2 and leaving the other discussion items in that section to potential application profiles.  It also clarifies the equivalence (soft boundary) between Major Type 0/1 and Tag 2/3.
> 
> Gordian dCBOR applies a number of exclusions and reductions to the application data it processes.
> After this (conceptual) processing, when encoded in the Common CBOR Deterministic Encoding Profile, the result should be identical to what’s in Wolf’s dCBOR draft.  Score one for “compatible”.  Also, any generic decoder that implements Common CBOR Deterministic Encoding Profile in a checking mode will accept Gordian dCBOR processed (and, implied, Common CBOR Deterministic Encoding Profile encoded) data. Score two for “compatible”.
> 
> Any Common CBOR Deterministic Encoding Profile generic encoder can be used to perform the encoding of Gordian dCBOR processed data.  Score three for “compatible”.

 From a more practical point of view: AFAICT, both https://cbor.me (in its current incarnation NB) and https://cyberphone.github.io/CBOR.js/doc/playground.html generate deterministic CBOR that "bombs" in dCBOR.

Could you please explain for us mere mortals how a "Common CBOR Deterministic Encoding Profile" would fix that?

Anders

> 
> The place where you might want to use “incompatible”:  The Common CBOR Deterministic Encoding Profile does give you a wider selection of instances you can encode, not all of which are Gordian dCBOR instances (“incompatible”).  So it doesn’t magically give you Gordian dCBOR compatibility; you actually have to implement that compatibility: Either by implementing the reductions and exclusions inside the application, or by implementing the reductions in a shim layer or an integral component added to the generic encoder (and of course not using excluded values such as »undefined« in the application, because there is no reduction for them).
> 
> The advantage of having this clear separation is that it becomes easy to later extend the Gordian dCBOR profile (e.g., by i128/u128 values), without having to revisit the deterministic encoding of the extensions where they already are covered by the Common CBOR Deterministic Encoding Profile.
> (It also makes more obvious what a subprofile such as integer-only dCBOR might be.)
> 
> So what was your question about?
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor