Re: [Cbor] Map keys?
Laurence Lundblade <email@example.com> Tue, 07 May 2019 17:28 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039AA12022A for <firstname.lastname@example.org>; Tue, 7 May 2019 10:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([184.108.40.206]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9qbgLLr69Mp for <email@example.com>; Tue, 7 May 2019 10:28:09 -0700 (PDT)
Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [220.127.116.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CA6120255 for <firstname.lastname@example.org>; Tue, 7 May 2019 10:28:08 -0700 (PDT)
Received: from [192.168.1.82] ([18.104.22.168]) by :SMTPAUTH: with ESMTPSA id O3srh6Mtev3PHO3sshBBWs; Tue, 07 May 2019 10:28:06 -0700
From: Laurence Lundblade <email@example.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_58C2AEB8-709C-416B-9118-8C2AB94CE181"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 7 May 2019 10:28:04 -0700
Cc: Felipe Gasper <firstname.lastname@example.org>, email@example.com
To: Carsten Bormann <firstname.lastname@example.org>
References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> <A30D4B40-875C-4119-8BEC-E7038E22CDA5@tzi.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfIxo6gXfTZzjrn8peuD+sCy/7sbnE8kVtUm6FLZddjWulTaIbi5tzGn7KQZ3AjunIzChzNzrGBqUAN7x3PIv2uBUXML6b0d+y4SBkwZsB4AvDAig3sUb rl56VP7Pcq1JgGPPwdIc/M2iQJHvS5OHruxQrn4T2aUiX7HDp//WCE5YI6cE0qnhwolXp704VkyEvgs1jilzWbn/7exp+Gzx+1C+qxmvqTlBtLfVDHFhiT9h
Subject: Re: [Cbor] Map keys?
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 17:28:18 -0000
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@example.com> wrote: > > On Apr 29, 2019, at 15:39, Felipe Gasper <firstname.lastname@example.org> 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