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

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

Henk, No worries for QCBOR users. There has been a warning in the documentation since its early beginnings.

Don’t want to make this about QCBOR, but a comment. QCBOR has explicit support to make maps easier to work with. It automatically decodes into one item with label and value and you can search a decoded map by label. Would be hard to have a clean/small design and support arbitrarily complex labels. Never a complaint.

It also has a mode that can handle arbitrary labels at the cost of the nicer map handling features.

LL


> On Mar 17, 2024, at 5:35 PM, Henk Birkholz <[e-mail]> wrote:
> 
> Hi Laurence,
> 
> Why are map labels special here?
> Or does your comment imply that dCBOR relies on a "symmetric" dJSON?
> 
> More comments in-line.
> 
> On 17.03.24 19:41, lgl island-resort.com wrote:
>> A CBOR map label (aka map key) can be any data type including perverse things like an array or a map. Here’s a sample I made for dCBOR testing:
> 
> "perverse"
> 
>>     {[]: 7, 1(88): 2, "text": 3, 1: 1, {}: 4, h'7878': 5, true: 6, 8.77: 7}
>> It has a map label of each major data type.
>> Probably dCBOR should disallow map labels that are not strings or numbers because they don’t translate to JSON. Same reason simple type undef is disallowed.
>> Probably we should state a general CBOR preference that map labels only be strings and integers.  QCBOR only supports text/byte strings and integers for map labels.
> 
> It is not an implementation of RFC9254 then. Maybe that should be noted somewhere.
> 
>> It’s been like this for years now and I’ve had no comment or request. Probably any use case that considers unusual labels can be redesigned to avoid them.  We only state a preference, not a prohibition, just like with indefinite lengths.
> 
> For a while, arrays where (considered and tested) as map keys in suit-manifests. Again, if you do not want to implement RFC9254, please set up some warning signs.
> 
>> LL
> 
> Viele Grüße,
> 
> Henk
> 
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor