Re: [Cbor] Decoding numbers and compliance verification in dCBOR

[Wolf McNally <[e-mail]>]

Anders,

> On Mar 11, 2023, at 10:09 PM, Anders Rundgren <[e-mail]> wrote:
> 
> AFAICT, properly defined deterministic encoding rules can actually *simplify* decoders.

I don’t think my decoder implementations are more than fractionally larger or slower for the validation they do.

> Map sorting gets trivial, you just keep a copy of the preceding key and verify that the new key is bigger.

In fact, this is exactly how my implementations do it.

> However, not sticking to Rule 2 in section 4.2.2 of RFC 8949 is asking for trouble.  Really constrained systems probably do not even use floating point, making the space argument seems pretty weak.
> 
> Although not an IETF document the following specification holds a condensed description of what I consider a "reasonable" dCBOR scheme:
> https://cyberphone.github.io/javaapi/org/webpki/cbor/package-summary.html#deterministic-serialization

I’m still not sure why we should cling to the idea that floating point 0.0, -0.0, and integer 0 need distinct encodings when we’re specifically discussing *deterministic* CBOR. This is essentially burdening developers with an implementation detail, and isn’t even true in practice for JSON, where “0” is treated as truly equal to “0.0” in both type and value. This is especially true when we’re considering JSON canonicalization practices that exist, such as https://www.rfc-editor.org/rfc/rfc8785

In fact, Giving a site such as https://codebeautify.org/jsonviewer the JSON `[10, 10.0, 0, -0.0, 0.0]` and telling it to “minify” produces `[10,10,0,0,0]`. I conclude that having more than one canonical representation for the same numeric values seems like a step backwards for anything wishing to call itself “deterministic CBOR”. I’m trying to to *better* than JSON here, not worse.

Please, let me know if you think I’m missing some important benefit of having redundant encodings.

~ Wolf