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

[Carsten Bormann <[e-mail]>]

On 25. Mar 2024, at 04:11, Orie Steele <[e-mail]> wrote:
> 
> Why do we need both CDE and dCBOR?

I’d like to answer to different questions?

(1) Do we need CDE?

RFC 8949 (and before it RFC 7049) left a number of decisions about deterministic encoding to the application.
(a) At the time, we simply didn’t have as many applications for deterministic encoding to guide a more nailed-down definition of the Core Deterministic Encoding Requirements (Section 4.2);
(b) there *are* application-level decisions that need to be made in mapping an application data model to the CBOR generic data model;
(c) we didn’t understand that this problem could be made more tractable by proper layering.

The approach to leave decisions to the application made it hard to write generic encoders for Core Deterministic Encoding Requirements.

During the discussion of dCBOR, we found that we can layer the problem:
(i) define a single common deterministic encoding profile that should cover the vast majority of application requirements (CDE),
(ii) introduce the concept of defining of Application Profiles on top of CDE, which encapsulate the application specific requirements (e.g., dCBOR).

So we can have our cake (get to work with generic encoders in the deterministic encoding space) and eat it too (get to define application-specific rules about data equivalence and the deterministic encoding of potential sets of equivalent data, effectively taking out the other data items in the equivalence set from the generic data model).

CDE is intended as a complement to RFC 8949 that provides the so far undecided details for writing common generic encoders for deterministic serialization, so it should have the same standards track status as RFC 8949 itself.

(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).

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.

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.)

Grüße, Carsten