[Cbor] Re: draft-ietf-cbor-serialization update

[Wolf McNally <[e-mail]>]

Anders,

> On Dec 7, 2025, at 9:32 PM, Anders Rundgren <[e-mail]> wrote:
> 
> Apparently CBOR::Core is as bad as it gets while dCBOR is pure gold although the implementations:
> - Outlaw legitimate floating point values

“Legitimate” is doing some heavy lifting here.

NaNs are, as their name states, not numbers. They are not floating-point numbers. They are not any kind of numbers at all. They are IEEE-754 *values*, and that is all they are. More precisely, they are bitfield *structures* with undefined semantics. We fully support the single obviously useful NaN value, and even previously proposed a method using tags that lets non-trivial NaNs be represented as bstrs for those rare applications that need them, in a way that is both semantically precise and interoperable.

If you’re referring to “outlawing” 2.0, we have the exact same semantic value 2, which we use instead. We’ve spent time explaining our reasons for this to you on-list, on in-person Zoom calls, and now in the draft appendices as well. If we did it the way you do it with CBOR::Core, then APIs, protocols, and engineers would all have to carry the additional cognitive burden of knowing which size bucket each typical numeric value must be carried around in (was that field i8 or i16?). If you enjoy hauling around that sort of representational trivia, you are welcome to it, but for someone who wishes to create a JSON killer, we don’t see how forcing that sort of burden on adopters helps your case.

> - Lack public API documentation

You say that like it’s a *bad* thing. There are several reference and third-party implementations of dCBOR now. Some of them are the dCBOR rules optionally added to existing implementations, and some of them are designed to specifically and exclusively support dCBOR. To try to impose a single API on every implementation of dCBOR regardless of platform would be a huge burden on implementers, especially when language idioms vary so widely. Our Swift dCBOR implementation feels natural to Swift programmers, and our Rust implementation feels natural to Rust programmers because we create APIs that are idiomatic for the language.

You might find it an interesting exercise to create an implementation of CBOR::Core for Rust, including your specific API. I suspect you’ll discover that what you’ve specified, which is what works well for you in JavaScript and Java, would leave you fighting with the Rust type system and idioms, and would be very uncomfortable for experienced Rust engineers to use.

> - Offer no backward compatibility mode

dCBOR has no “modes” at all. It is a package of narrowing rules you can adopt or not adopt, with the sole caveat that if you do not adopt all of them, then you do not actually support dCBOR. Of course, since all dCBOR is valid CBOR, any CBOR decoder, even a highly constrained one, can decode dCBOR. And if a constrained decoder trusts the source, it can decode dCBOR as CBOR without checking all the dCBOR rules and without needing to claim full dCBOR conformance.

~ Wolf