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

[Henk Birkholz <[e-mail]>]

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