Re: [Cbor] Map keys?

Hi Felipe,

There is no restriction on map keys in CBOR.

But maybe there should be a CBOR protocol design guideline that strongly recommends this. Seems to me that the complexity of implementation of a generic decoder that handles keys that are maps and labels is pretty high. We already have trouble with equivalence and sorting of map keys with just the strings and integers, seems like a protocol using arrays and maps would make that much worse. 

It also seems like a very unusual thing to do and beyond what other protocols and languages do.

I chose to make my C implementation of CBOR <https://github.com/laurencelundblade/QCBOR> have built-in support for keys that are integer or strings, but not arrays or maps. (You can put it in a mode where it will handle any type of key, but you lose most of the the built-in support for maps, because they are just treated like arrays). 

With such a recommendation we’d probably consider the inclusion of binary strings and floating point numbers as keys. 

LL

> On Apr 29, 2019, at 6:39 AM, Felipe Gasper <felipe@felipegasper.com> wrote:
> 
> Hello,
> 
> I’m looking at RFC 8392, which says:
> 
> ——-
> In JSON, maps are called objects and only have one kind of map key: a string. CBOR uses strings, negative integers, and unsigned integers as map keys. The integers are used for compactness of encoding and easy comparison. The inclusion of strings allows for an additional range of short encoded values to be used.
> ——-
> 
> While this doesn’t directly say per se that CBOR _only_ uses strings and integers as map keys, the implication seems strong. I don’t see any such limitation in the CBOR RFC.
> 
> Does CBOR intend, then, to restrict map keys to only major types 0, 1, and 3?
> 
> Thank you!
> 
> -Felipe
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor