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

[Wolf McNally <[e-mail]>]

Anders,

I don’t hear anyone here agreeing with you.

Not this time, or the last ten times you’ve repeated yourself.

You might want to consider the reasons for that.

(And I definitely call on anyone else here who does agree with you to speak up.)

There are no “breaking changes” in dCBOR.

dCBOR can be decoded with any CBOR (or CDE) decoder.

dCBOR can be encoded with any CBOR (or CDE) encoder.

It won’t be super easy, but you can do it.

That means that dCBOR is interoperable *enough*.

But interoperability is *not the point.*

If CBOR were all about “interoperability” then you could use a CBOR decoder to read a JPEG.

But you can’t do that. Does that mean CBOR is “broken”?

No.

Because the purpose of CBOR is not to be interoperable with everything, or indeed *anything* except CBOR.

And it is not the purpose of dCBOR to be interoperable with anything except dCBOR.

“All dCBOR is CBOR, but not all CBOR is dCBOR.”

“All JPEGs are binary files, but not all binary files are JPEGs.”

See the pattern?

CBOR floating point '2.0' is *not* dCBOR and never will be.

So if you encode CBOR '2.0' and send it to a dCBOR decoder, it *will* be rejected.

That’s not a “breaking change”.

And if you present ‘2.0’ to a dCBOR encoder, then it will be encoded as an integer '2'.

You simply *can’t* encode '2.0' with a strict dCBOR encoder.

But that is *also* not a “breaking change”.

Not what you want? Don’t use dCBOR.

Interoperability is great. But it's *not* the be-all-and-end-all of standards.

dCBOR is not *about* interoperability.

It’s about *takes deep breath*…

…DETERMINISM.

~ Wolf

> On Jul 28, 2024, at 10:47 PM, Anders Rundgren <[e-mail]> wrote:
> 
> 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.
>