Re: [Cbor] Map keys?

Laurence Lundblade <lgl@island-resort.com> Mon, 29 April 2019 13:59 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FF120329 for <cbor@ietfa.amsl.com>; Mon, 29 Apr 2019 06:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2h78PcC6yZt for <cbor@ietfa.amsl.com>; Mon, 29 Apr 2019 06:58:59 -0700 (PDT)
Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (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 D477D1200C7 for <cbor@ietf.org>; Mon, 29 Apr 2019 06:58:58 -0700 (PDT)
Received: from [192.168.1.108] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id L6o5hyf9IpwnzL6o6hAoqe; Mon, 29 Apr 2019 06:58:58 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <E38A5EDE-31A7-4070-A5C6-58A656E1340F@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8089DBEB-A073-42CC-9C15-DF2FDA0AA766"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 29 Apr 2019 06:58:57 -0700
In-Reply-To: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com>
Cc: cbor@ietf.org
To: Felipe Gasper <felipe@felipegasper.com>
References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfHerxK+79T2wpg3e+fsOVvFDVxdd7nBiqe5DB6nmiFijxI9RgvVWlp5JcA2U6/tqd1agpeRFzj/7uSOdZhUnDq2OHWTvpySZEPD0dbohElOyLHhhpcxA QnOIC29YDnMSGx2cLcQc+d1kyfYBKVsyLjAn2sbFKSN2ZFFJN+QB+OPwL/kgr561ibVl3GwBo/iID5sx+4yxmOYLSapZRr8tn5o=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Fcp5ogkhVyXmm1RvAcTV59Rw4ro>
Subject: Re: [Cbor] Map keys?
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 13:59:01 -0000

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