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

[Anders Rundgren <[e-mail]>]

Hello WG,

You may think I'm repeating myself and to some extent I do.  However, this posting is about INTEROPERABILITY which is one of the pillars of standards.


Since dCBOR introduces a BREAKING change [1] with respect to its parent profile (CDE), I felt inclined commenting a bit on the actual draft.

IMO, a revised draft should be fitted with an *Interoperability Section*, giving potential application developers a "heads up" on what to expect: CDE and dCBOR are incompatible at the application level [2].

The primary source of the incompatibility is the reliance on numeric reduction.  According to the draft the integer value 2 and the floating point value 2.0 are "semantically equivalent".  This seems like a stretch since floating point numbers and integers have quite different characteristics with respect to math and value ranges, which also make them having pretty distinct use cases.  In addition, the draft alludes that numeric reduction better matches the requirements for deterministic representation of numbers.

Anders

1] Although the draft claims that dCBOR is not a "fork" since it maintains compatibility with CBOR [RFC 8949], the reality (the only thing that matters for application developers), is that the referenced decoder implementations [rightfully] reject 2.0 if encoded as CDE.  In the other direction, CDE-compliant decoder implementations and associated applications like https://github.com/cyberphone/CBOR.js/blob/main/test/xyz-decoder.js#L20 would equally rightfully balk at 2.0 encoded according to dCBOR.

2] Assuming that you don't move encoding rules up in the application layer, something only novice developers would ever consider.