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

Joe Hildebrand <hildjj@cursive.net> Thu, 18 February 2021 16:59 UTC

Return-Path: <hildjj@cursive.net>
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 71C413A13E6 for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 08:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=cursive.net
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 LgfBq3_ke80b for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 08:59:24 -0800 (PST)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF643A144B for <cbor@ietf.org>; Thu, 18 Feb 2021 08:59:24 -0800 (PST)
Received: by mail-oi1-x229.google.com with SMTP id q186so2655300oig.12 for <cbor@ietf.org>; Thu, 18 Feb 2021 08:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2TXOrj+IHISdptF9k8YupEqC070CYP0BDTmZDikUad4=; b=dz6vE7X2PUI6vpdQ2yxqnMrQZ1b/6O97WX+aHtD8vL08z1QZU5guklB37+TFEaUsGR FDKAEzRrlhvSdj7jLhRhoVFoAqggX88WUZdiqfOZhAX68YxdAveKe9DPpOsdOzxSSJoB WtEefB+o4YM6NhRmfQMiPMTHJFd+sclEvlLcg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2TXOrj+IHISdptF9k8YupEqC070CYP0BDTmZDikUad4=; b=D0KHZtDVBWI3JaFGj6tkcQANWcsT6wG058xtFUvZkh+XraEPUNaZYHZu6ttia2Pjic wRP50jxOJgicGPCSMiIOOqC7vSdI0EwTgsgLakQlXRbOs467TAjtJxrpPIu2Ji7lTuH5 WhVVJyw6gAL8jgAgxGd0VqronDMZFUWoqTbsQ1UrVzIvalr4+jHHCeTXcJLDUWCN0WhO 9knqGL+YWDspAWHMTK5vnoEIhPGH8AutcX1y4jPk3hOM+JZbywbgLa/jG6wfZL0FQcmN gKmfY1pMtjQRairR5olaq2VW04aveSowkZxwjp+Y6ASinPS2JRj7hDK+2lV/i+OH624f BXmA==
X-Gm-Message-State: AOAM532SGMr4mPW24+4zKx20R/f410E1j9vlSy3i365NTnnXhfbw85mW yikqZIX/nxNiW7TNB4VwwDSNLw==
X-Google-Smtp-Source: ABdhPJx6qu8PCpbYLuo5cQuUVu+d6NQusGTo9enondlGrZOysGptVWrxty3QPACoNNvs7FxbBTXsOg==
X-Received: by 2002:aca:6701:: with SMTP id z1mr3238005oix.93.1613667563950; Thu, 18 Feb 2021 08:59:23 -0800 (PST)
Received: from ?IPv6:2601:282:200:3758:7479:b77e:8b77:b5d5? ([2601:282:200:3758:7479:b77e:8b77:b5d5]) by smtp.gmail.com with ESMTPSA id d1sm1131201otc.57.2021.02.18.08.59.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 08:59:23 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joe Hildebrand <hildjj@cursive.net>
In-Reply-To: <72053102-1BA1-4281-9F17-CF7A65EEA907@island-resort.com>
Date: Thu, 18 Feb 2021 09:59:22 -0700
Cc: Kio Smallwood <kio@mothers-arms.co.uk>, cbor@ietf.org, Carsten Bormann <cabo@tzi.org>, "Dale R. Worley" <worley@ariadne.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4C8AB33-C906-465B-BA2C-25E1E82408B5@cursive.net>
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.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/z7YhPZVip_LpQ5hPfwl7RL_A868>
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:34:53 -0000

I agree that exotic map keys (with exactly your definition of exotic) are almost-always bad protocol design.  There are other uses of CBOR than wire protocols, however.

— 
Joe Hildebrand

> On Feb 18, 2021, at 9:48 AM, 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. This is nye impossible to write general map handling code for — code like lookup up by label and duplicate detection. They will not translate to other map data structures in other languages and serialization formats. Further, this seems like an exotic feature of little practical use (though I’m sure someone could do something very cool and clever with it for entertainment purposes).
> 
> What to do?
> 
> - Don’t standardize any IETF protocols that use exotic map keys?
> - Add text to Kio’s proposal to restrict map keys to text string, byte string and integer?
> - Write some warning against this somewhere?
> 
> LL
> 
> 
> 
>> On Feb 18, 2021, at 9:15 AM, Kio Smallwood <kio@mothers-arms.co.uk> wrote:
>> 
>> Thanks Joe!
>> 
>> I really appreciate the additional input since I wasn't aware of other languages with a similar datatype.
>> 
>> I've accepted your PR and updated my README and repo commentary to reflect the TBD status of the tag.
>> 
>> Cheers,
>> 
>> Kio
>> 
>> On 2021-02-18 15:19, Joe Hildebrand wrote:
>> 
>>> PR's sent for both your repo and mine.
>>> 
>>> — 
>>> Joe Hildebrand
>>> 
>>>> On Feb 18, 2021, at 8:00 AM, Joe Hildebrand <hildjj@cursive.net> wrote:
>>>> 
>>>> Kio, I'm happy to defer to your document, since you published first.  Sorry I didn't know about it.  If you are amenable, I'll replace my doc with a pointer to yours, and send you a PR with some suggestions for JS examples.
>>>> 
>>>> — 
>>>> Joe Hildebrand
>>>> 
>>>>> On Feb 18, 2021, at 7:42 AM, Kio Smallwood <kio@mothers-arms.co.uk> wrote:
>>>>> 
>>>>> I'll modify it to remove the claim until it moves further.
>>>>> 
>>>>> I definitely want to avoid confusion!
>>>>> 
>>>>> Kio
>>>>> 
>>>>> On 18 February 2021 14:15:39 GMT, Carsten Bormann <cabo@tzi.org> wrote:
>>>>> 
>>>>> 
>>>>> On 2021-02-18, at 14:57, Kio Smallwood <kio@mothers-arms.co.uk> wrote:
>>>>> 
>>>>> Hi Dale,
>>>>> 
>>>>> I have made a similar proposal here: https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md
>>>>> 
>>>>> ... and here we see the danger of just "claiming" a number...
>>>>> 
>>>>> (272 is Non-UTF-8 CESU-8 string).
>>>>> 
>>>>> I've tried to explain the rationale that it is adding a straightforward option for serializing a native data-type in Python 3 and other languages that support order-preserving key-value maps.
>>>>> 
>>>>> Yes.  And I agree with Dale that we should look a bit closer, but that is not a reason not to allocate a tag.
>>>>> 
>>>>> Grüße, Carsten
>>>>> CBOR mailing list
>>>>> CBOR@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/cbor
>>>>> 
>>>>> -- 
>>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>>> _______________________________________________
>>>>> CBOR mailing list
>>>>> CBOR@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/cbor
>> 
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
>