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

[Wolf McNally <[e-mail]>]

LL,

I think you make good points. And there is at least some precedent within the existing dCBOR I-D to specify restrictions that aren’t entirely based in its primary goal of determinism, for example limiting the range of negative integers that are valid, which was specified toward a secondary goal of compatibility with prevalent CPU architectures, and hence simpler implementation and use.

That said, there is currently one case where Blockchain Commons specifications not only allow for, but rely on, generally complex map keys: Gordian Envelope. Envelope is an enumerated type with several cases, each of which requires a unique discriminator. In the Gordian Envelope specification I-D, §3.4, we define the `assertion` case as a single-entry map, where the key-value pair corresponds to a semantic predicate-object pair, and where either field is itself an envelope, recursively. 

https://www.ietf.org/archive/id/draft-mcnally-envelope-06.html#section-3.4

The presence of this single-entry map is the discriminator for the `assertion` case, and this is part of Envelope’s design that facilitates arbitrarily deep metadata. Obviously, a single-entry map requires no sorting of keys— the deterministic ordering of assertions in an envelope is based on sorting digests of entire assertions, not map keys— so technically we did not need to use a map here. But the alternatives were either to register a special-purpose CBOR tag (low-numbered tag space is desirable but scarce), or to use a separate discriminator like an array with having a specified form like a leading constant integer (adding complexity in our implementation as we are already using CBOR arrays to distinguish our `node` case). Since dCBOR/CDE/CBOR admit complex map keys, we saw no reason not to use a single-entry map for this as a parsimonious solution.

~ Wolf

> On Mar 28, 2024, at 12:55 PM, lgl island-resort.com <[e-mail]> wrote:
> 
>> 
>> 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