Subject: Re: [Cbor] Map keys?

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 May 2019 10:28:04 -0700

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 <[email-masked]> wrote:
> 
> On Apr 29, 2019, at 15:39, Felipe Gasper <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 May 2019 07:08:56 +0200

Hi Laurence,

> On May 7, 2019, at 19:28, Laurence Lundblade <[email-masked]> wrote:
> 

Please have a look at RFC 8428 for an example how CDDL can be used for such a protocol (apart from switching the labels, we also had to solve encoding SenML byte string data values in base64url text strings for JSON and byte strings for CBOR).

I think CDDL 2.0 should have some common conventions for specifications that serialize both to JSON and CBOR; in RFC 8428 the “switching in” of the relevant part was done in English.
Ultimately, tools such as https://github.com/core-wg/senml-spec/blob/master/senml-json2cbor.rb should be fully generatable from such a specification (the current tool does make use of the salient part of the CDDL — see lines 65 to 72 — but still needs manual programming to apply it in the right places).

> 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…

Containers as map keys make sense exactly where the application semantics call for it.
The use of containers as keys in what CDDL calls “struct” usage (Section 2) is probably rare, but does exist: I have seen specifications that use arrays (in “record” usage) to represent XML qualified names, which are perfectly usable map keys.  For “table” usage, containers as keys are quite natural.

Grüße, Carsten