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

["lgl island-resort.com" <[e-mail]>]

On Mar 27, 2024, at 6:25 PM, Wolf McNally <[e-mail]> wrote:

LL,

On Mar 24, 2024, at 12:21 PM, lgl island-resort.com <[e-mail]> wrote:

For dCBOR, I’d like to see map labels very restricted. I’m not a JSON user/expert, but it is a Jupiter-sized data point for me. It has massive use with only string labels.

I’ll propose integers and strings (major types 0-3) to start discussion. Maps and arrays seem too much. Only strings might be OK.

I’m not sure whether the issue you’re having is coming from a place of design advice, or implementation complexity. From a protocol design perspective, in the vast majority of cases I agree that using integers or strings for map keys makes the most sense. From an implementation perspective, our code simply incrementally manages maps by using the serialized CBOR of a key as the “real” key and keeps the map in sorted order, even though it hides this fact from the user. This lets us skip the sorting step during serialization, and facilitates the validation step during deserialization. It also lets us support arbitrary map keys per the CBOR spec. Obviously this isn’t the only approach that works to keeping the serialized map supported, its keys unique, and also support complex keys.

Wolf, thank you kindly for taking the time to write a clear explanation. Makes the discussion converge faster (for me anyway).

I don’t have an issue. Just thought it was something worth discussing. Here are some reasons.

Implementation complexity — To implement non-scalar map labels, you’d probably do so in an OO environment where the label is an object. That’s a little out of line with the embedded goals of CBOR. Also, implementing maps as map labels in my embedded-oriented QCBOR project wouldn’t really work (but QCBOR is just one data point).

Alignment with JSON — Seems like lots of CBOR protocols will get translated to/from JSON because so much of the world runs on JSON. For example, I pushed hard for EAT to be realizable in both CBOR and JSON because I thought the attestation ecosystem would benefit. I was supported by the RATS WG to complete this. CDDL has been evolved to support CBOR+JSON better.

Simplicity/adoption — I think JSON succeeded because it is so simple. CBOR is handicapped in comparison. Seems that maps as map labels is something you do to show how clever you are, not because it is good design or gives expressive power not otherwise available.


I can imagine many use cases other than the Gordian Envelope finding dCBOR highly desirable because it eliminates all the CBOR stuff that is variable and a lot of stuff that is hard to understand. Most people aren’t as smart or as into this stuff as we are. Simple map labels line up with this.

Again, the goal of dCBOR wasn’t “simple CBOR,” although it has some of that flavor, but “deterministic CBOR” as its name suggests, and I’ve kept that foremost in the design choices I made in its specification. I can see why someone might define an “sCBOR” protocol that further restricts dCBOR, but inasmuch as dCBOR meets its original goals, I don’t see the point of restricting it further.

I have a personal view that some sort of “simple CBOR” would be good for the CBOR ecosystem because I see smart IETFers often confused about serialization, determinism and other. If they’re confused, think about the masses of IT people.

dCBOR seems like it could serve both that and Gordian.

This is not something I personally want to put a lot of energy into especially if there isn’t big WG consensus and it is a push up hill. Just thought it was worth some discussion, clarification and consideration.

LL