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

[Wolf McNally <[e-mail]>]

Our view is that it’s good to be opinionated, and enforce good practices in APIs. Determinism is one such good practice when it comes to creating cryptographically enhanced documents.

Generally the size of encoded numeric values should not be semantically meaningful, so our codec does the work of selecting an unambiguous size for serialization.

If you haven’t seen it yet, I recommend the video we just published on our dCBOR implementations, which goes into a number of our design choices:

https://youtu.be/NlJE8oF1B5M" dir="ltr" width="300">

https://youtu.be/NlJE8oF1B5M">dCBOR (Deterministic CBOR) Library from Blockchain Commons https://youtu.be/NlJE8oF1B5M">youtu.be

~Wolf

On Mar 5, 2023, at 4:48 AM, Carsten Bormann <[e-mail]> wrote:



On 5. Mar 2023, at 12:29, Wolf McNally <[e-mail]> wrote:

Anders,

Actually the main point of serializing floating point values that have lossless integer representations as integers is to remove ambiguity when dealing with numerous possible encodings of the same value, e.g.: 0.0, -0.0, and 0 (integer). This is basically the same rationale as the other minimal encoding reductions; the primary goal not being space savings per se but deterministic encoding.

This, again, is an application layer view.  In IEEE 754, 0.0 and -0.0 are distinct.  If they are the same in your application, deterministic representation requires *the application* to turn one into the other, before a fully generic encoder gets to handle this number.  Practically speaking, delegation of this work to the encoder works, which then can only be used for applications that do not make that distinction.

Grüße, Carsten