Re: [Cbor] Unusual map labels, dCBOR and interop

[Wolf McNally <[e-mail]>]

All,

> On Mar 24, 2024, at 5:42 PM, Carsten Bormann <[e-mail]> wrote:
> 
> (2) Do we need dCBOR?
> 
> Depends on “we” and “need”.
> 
> As I mentioned, it is good to have at least one example of an application profile.
> CDE can be used without one (defining no further equivalence sets), or, one could say, with a null application profile.
> But it is much easier to validate the architecture by defining at least one useful application profile.
> So do we “need" dCBOR?  It is definitely useful for the work leading up to CDE at least in the sense of providing validation for the two-layer approach.
> 
> We differ in our perception how useful dCBOR is as an application profile — clearly there are different areas of application of CBOR, and dCBOR is not for all of them; different WG members naturally have a different perspective here (providing different “we”s).

When “we” is Blockchain Commons and our supporters, the “need” is a stack of protocols and tools that make determinism a more tractable goal. We also believe that others, when determinism is their goal, will find dCBOR attractive.

Obviously none of these sets of “we” is the same, so while there will be some overlap, it was never our goal to make dCBOR something that would replace CBOR or even be widely adopted relative to CBOR in general. Certainly the dCBOR approach has certain costs that may be worth it to some and not worth it to others. I would hope that implementers of CBOR codecs will find it useful to support dCBOR, but this has always been an option and not a requirement for dCBOR’s use and adoption.

> I believe we also need to acknowledge that the change control for this specific application profile better rests with the group that has that application area in focus.  Clearly, there are further aspects of deterministic representation at the application level that dCBOR does not discuss (for an obvious example: do you use tag 0, 1, or 1001, and what specific configuration [e.g., the use of timezones on tag 0 RFC3339 content], for representing timestamps?).  Not all of these need to be part of an application profile, and it would hinder evolution of applications that use the application profile if they did.

Correct. dCBOR is not a panacea for determinism, as it is manifestly obvious that no amount of specification or software tooling will stop a determined (or unskilled) practitioner from creating a non-deterministic encoding of identical semantics. More fundamentally, the dCBOR spec was designed to address issues around determinism raised in the core CBOR spec, and not all other extensions of CBOR.

> So, as the CBOR WG, we haven’t worked on deciding which form of publication the dCBOR application profile should take.
> I believe having an RFC would be good so it is easier to use CDE with dCBOR as an example.
> (There are several ways to get this RFC published: From ISE to IETF WG informational or experimental or standards-track.)

We would prefer a standards-track RFC, but remain open to advice and counsel from the WG and the IETF at large as to how to proceed in this.

~ Wolf