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

[Anders Rundgren <[e-mail]>]

On 2024-07-29 15:49, Joe Hildebrand wrote:
Hey Joe,
> I don't understand the message you linked to.

I simply pointed to another project with very different goals compared to dCBOR to in some way provide an explanation to why we do not agree.


> - CBOR subset: this seems like same kind of "breaking change" you accuse dCBOR of

The enterprise application profile is a strict CDE subset, dCBOR is not.  Is the subset too limited? As a JSON replacement it should be more than sufficient.


> - Encoding profile: I don't know your use case, but if you're not getting decoding errors from incorrectly-formatted CDE that is still valid CBOR, you're likely either going to have a security issue or not need determinism.

Invalid CDE would indeed be rejected.  My PoC implementations did that even before CDE was published.


> - I'm still not sold on bidirectional diagnostic notation, and have not planned on writing a parser for it, but I'm still thinking about that.  However, I don't see what it has to do with this discussion.

It is a core part of the mentioned project.  Config file support is the main attraction.


> - draft-rundgren-cotx doesn't bother me, aside from the usage of "URL" instead "URI" and no pointer to RFC 4151.  Using URLs as identifiers is fine until people start dereferencing them at runtime, which they ALWAYS seem to do for some reason.

This is beyond my control.  A big and growing part of the world seems to be OK with URLs as identifiers.  WHATWG do not appear to make a distinction between URLs and URIs: https://url.spec.whatwg.org/


> Saying that everyone should do it your one true way seems... omniscient on your part.

I'm rather saying that the enterprise application profile avoids edge cases like Numeric Reduction, NaN Payloads, 0.0 / -0.0 Map Key Equivalence, and Unicode Normalization.


> Tool develeopers by necessity think about application developers that are going to use their tools, or there won't be any application developers that use their tools.

Claiming that CDE and bCBOR are compatible because you can build what's missing on top of the respective implementations, is not something you would say to application developers.


> You're arguing that my tools are bad.  Please file an issue on GitHub.  I think I fixed the last one you filed.

Your tools are not bad, they are just different to mine.  As long as tools produce what they should, all is cool.

Anders


> 
> —
> Joe Hildebrand
> 
>> On Jul 29, 2024, at 8:40 AM, Anders Rundgren <[e-mail]> wrote:
>>
>> On 2024-07-29 10:08, Wolf McNally wrote:
>>> Anders,
>>> I don’t hear anyone here agreeing with you.
>>
>> Hi Wolf,
>>
>> You are 100% correct but it might have an another explanation than you think: the "WG" (You, Carsten, Laurence, Joe, ?), is focusing on *Tool* developers*.
>>
>> I obviously do not: https://mailarchive.ietf.org/arch/msg/cbor/PFZXSxyvQ7zG6Cj6QmzHd-_K52g/
>>
>> However, targeting the bulk of *Application* developers, indeed makes interoperability the #1 concern.
>>
>> Anders
>>
>>
>>
>>> 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.
>>>>
>>
>