Re: [Cbor] hildjj/cbor-map-entries: Explicit Map datatype for CBOR, in array format

Carsten Bormann <cabo@tzi.org> Thu, 18 February 2021 17:52 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 C8D153A14EA for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 09:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ss9NO8z1qF2Z for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 09:52:35 -0800 (PST)
Received: from gabriel-vm-2.zfn.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 C34953A14E9 for <cbor@ietf.org>; Thu, 18 Feb 2021 09:52:35 -0800 (PST)
Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DhMjs44HPzyWv; Thu, 18 Feb 2021 18:52:33 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <72053102-1BA1-4281-9F17-CF7A65EEA907@island-resort.com>
Date: Thu, 18 Feb 2021 18:52:33 +0100
Cc: Kio Smallwood <kio@mothers-arms.co.uk>, Joe Hildebrand <hildjj@cursive.net>, cbor@ietf.org, "Dale R. Worley" <worley@ariadne.com>
X-Mao-Original-Outgoing-Id: 635363552.874568-324211d36b5de50260b19e3588c1eb23
Content-Transfer-Encoding: quoted-printable
Message-Id: <05798259-49C4-4442-84A3-9FD13D0BDB5B@tzi.org>
References: <87zh02kpf5.fsf@hobgoblin.ariadne.com> <0faeb37c36d5b1f40c37f82e62be1be9@mothers-arms.co.uk> <ED6F6174-2643-4B7F-8ED7-414DD5FD9C39@tzi.org> <F6BDBA57-34F4-46FE-9806-6A227AC214EA@mothers-arms.co.uk> <DC0D444C-3231-4029-B0BB-5EC02863B72A@cursive.net> <999B078D-C4B2-4B04-8487-7ECEFEB953DF@cursive.net> <94bbc990fcf388ae5fd01c06274ed58a@mothers-arms.co.uk> <72053102-1BA1-4281-9F17-CF7A65EEA907@island-resort.com>
To: Laurence Lundblade <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/dkvVS1akarUxjz-jEzqH3SXRfqc>
Subject: Re: [Cbor] hildjj/cbor-map-entries: Explicit Map datatype for CBOR, in array format
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: Thu, 18 Feb 2021 17:52:40 -0000


> On 2021-02-18, at 17:48, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> This is semi-related and maybe something I’m a little confused about.
> 
> My understanding is that map keys/labels can be anything in CBOR including a map or array.

Yes.  

Or a Tag!

> What to do?
> 
> - Don’t standardize any IETF protocols that use exotic map keys?

Yes.

(I don’t know what’s exotic, but on the implementation side generally any data structure that is mutable is a bit ugly as a map key.  E.g., languages where strings are mutable already need to jump through extra hoops here.  But, e.g., C++ handles maps with non-trivial keys just fine; these are certainly not exotic at all to a C++ programmer.)

> - Add text to Kio’s proposal to restrict map keys to text string, byte string and integer?

No.

(E.g., think what https://tools.ietf.org/id/draft-ietf-cbor-tags-oid-02.html#name-distinguished-name-in-cbor- would look like without tag factoring.)

> - Write some warning against this somewhere?

Should be obvious to anyone skilled in the art :-)

(The reason CBOR can do this is that many platforms can do it — so not supporting it in the format would have made CBOR less useful for native code/protocols for specific platforms.)

Grüße, Carsten