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

[Anders Rundgren <[e-mail]>]

Hi CBOR WG,

Quoting LL: "dCBOR use should be very very rare. Like 100 times more rare than CDE."
Right or wrong, the draft gives no clues to the characteristics of such esoteric applications. Here is an attempt to rectify this situation.

THE CORE ISSUE

2.3  Numeric Reduction
    The purpose of determinism is to ensure that semantically equivalent data items
    are encoded into identical byte streams. 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.

This text can be interpreted like: numeric reduction is more deterministic ("better") than its CDE counterpart.
However, if we stick to the *Encoding Format* only, the schemes should be comparable [*].

What's left are rather *External Factors* that may motivate numeric reduction.

Revised text proposal:

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.

In discussions on the mailing list other dCBOR features like support for advanced transformations have been mentioned as well.  However, they are unrelated to the dCBOR encoding scheme.

END OF UPDATE

This following section is just another view on the core issue.

Using CDE with JavaScript is not a major problem, as shown by this 300-line pretty full-featured CBOR encoder:
https://gist.github.com/cyberphone/d0f7a99da6afb397955645baad578bea#file-cde-js-L316

If wrapping floating point values feels too awkward, by using *Object Encapsulation*, application developers can get away from CBOR altogether. CBOR-related APIs would then be left for system and library developers to bother about:
https://github.com/cyberphone/CBOR.js/blob/main/test/xyz-encoder.js#L38
https://github.com/cyberphone/CBOR.js/blob/main/test/xyz-decoder.js#L42
In the examples, strict type checking ensures respectively verifies that the CBOR data conform to the "XYZ" specification.

Thanx,
Anders

*] Numeric reduction does though break the self-describing nature of CBOR (a serialized 2.0 ends up as 2).