Re: [Cbor] Map keys?

Carsten Bormann <cabo@tzi.org> Wed, 08 May 2019 05:09 UTC

Return-Path: <cabo@tzi.org>
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 5186D120134 for <cbor@ietfa.amsl.com>; Tue, 7 May 2019 22:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 m7PDAwIY61Fe for <cbor@ietfa.amsl.com>; Tue, 7 May 2019 22:08:59 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD55120125 for <cbor@ietf.org>; Tue, 7 May 2019 22:08:59 -0700 (PDT)
Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44zPdj1BcVzyZn; Wed, 8 May 2019 07:08:57 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CD8B73F2-ACB0-4D0C-96D7-A8A541090360@island-resort.com>
Date: Wed, 08 May 2019 07:08:56 +0200
Cc: Felipe Gasper <felipe@felipegasper.com>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 578984934.596411-379f47026fad60865654f8e815f8839a
Content-Transfer-Encoding: quoted-printable
Message-Id: <09F591CD-F472-47B7-A3A7-F3B2D6A50846@tzi.org>
References: <8269CD1C-B024-4961-A889-C8543502596A@felipegasper.com> <A30D4B40-875C-4119-8BEC-E7038E22CDA5@tzi.org> <CD8B73F2-ACB0-4D0C-96D7-A8A541090360@island-resort.com>
To: Laurence Lundblade <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/hIbtsW7fXmVbBcNcrpOZlHiboG0>
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: Wed, 08 May 2019 05:09:01 -0000

Hi Laurence,

> On May 7, 2019, at 19:28, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> 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.

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 should only be used if really necessary.

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