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

[Wolf McNally <[e-mail]>]

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.

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

~ Wolf