Re: [Cbor] Map keys?

Here’s two examples of places where the types of map keys are restricted.

COSE
Section 1.4 has this CDDL limiting labels to integers and text strings:

   label = int / tstr

JSON
JSON “names” (“keys" in CBOR) can only be strings so any CBOR that translates has to limit keys.

I didn’t see any discussion of this in Appendix E in draft-ietf-cbor-cddl-08.txt. This seems important, at least to me for the EAT/RATS work where we want to use CDDL to describe both CBOR and JSON encodings. In particular we’d like to use integer keys in the CBOR encoding and need to resolve how that gets expressed in JSON.

It would be helpful to me to see more compelling real world examples of keys as arrays or maps. It seems like a cool thing to do in some ways, but in others it seems like a jump in complexity that should only be used if really necessary.

LL

> On Apr 29, 2019, at 7:02 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On Apr 29, 2019, at 15:39, 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. 
> 
> Well, it doesn’t say “and nothing else” :-)
> RFC 8392 is not intended to update RFC 7049, anyway.
> 
>> 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?
> 
> There is no such intention.
> 
> Indeed, major types 0/1 and 3 are the most often used map keys (probably followed by 2).  But there is nothing wrong with 7 (false, true, …), 6 (tagged data), or the containers (4, 5) etc. as map keys.
> 
> This may be elucidated a bit more by draft-ietf-cbor-cddl-08.txt (in RFC editor queue), section 2, which distinguishes two kinds of map usage: “structs” (where indeed 0/1 and 3 are usually most convenient), and “tables”, where the ability to use any CBOR data item as a map key is vital.
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor