Re: [Cbor] Tag 279 "Map entries for CBOR" in array format

Joe Hildebrand <hildjj@cursive.net> Thu, 18 February 2021 14:56 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 B1A553A1314 for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 06:56:09 -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 DI9cb7W5649p for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 06:56:08 -0800 (PST)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 F05A53A1313 for <cbor@ietf.org>; Thu, 18 Feb 2021 06:56:07 -0800 (PST)
Received: by mail-oi1-x233.google.com with SMTP id y199so2251863oia.4 for <cbor@ietf.org>; Thu, 18 Feb 2021 06:56:07 -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=pRGElBdhJ3t1VwbdtQ0X1ddZmMEoIjwBD8AekpP3PEM=; b=q8w0ASU2dss1s7QPAHsMbJsFZtD3EwTAzoxUDJWMrA04XFrvHzwfSACujv0eFhOwjE KEJCLxnXN3e7lSUyiUefG7nUTymMwtWZx47+peaiV5DjhWHgp1/5dj/VxkAjj0FBuVcZ QChcaYRvml4vSV6hiHObz8QieCaAB+C5gy9wE=
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=pRGElBdhJ3t1VwbdtQ0X1ddZmMEoIjwBD8AekpP3PEM=; b=NmjJRFWKK0xWm0ah/+uKZe5eNIQG75yQRpdtGClhW3kjC006GMSJElrt3YEfdHQqPB EFu65scpDJaU8etwQdISwCUsKoC3KbszD6YLd/3GbzQrE+pgS609SkZureMMFHUr5NYq aAaWrKOvwVaN2MXy46mZQd7ZFPSPtn3ylniitAnwMd1bzb2C/8qlUZY5K80RdO6+H44g 8o5ac56XbiVAC3D5D0iL1BHpn/Khv3KKfwM0yyNJI0qbJLrb8SHf/+MRIXg77RyyW3JX FaAMTwCePObR6CFhINoGcACMi3YC5+YyghrJMhMT6ZvxFiCHnzOvTZmaS6xOC/Yo/7KH 8vaQ==
X-Gm-Message-State: AOAM531pDfGUvwS2u/c7TIf1Tlq+oDe1KuurCU6+cJb3MfH/jXFgKzSG NDE+kdCZ19yhseFIdBDgKTxwosC56YxgDA==
X-Google-Smtp-Source: ABdhPJyowa1sNMWg6h2yIDKFdQv760eBXuPsgv6Ou4hqh3bSbwxdYE0GerSum8KgyhoHoa1s8bFQBw==
X-Received: by 2002:a05:6808:13c5:: with SMTP id d5mr2905097oiw.103.1613660166956; Thu, 18 Feb 2021 06:56:06 -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 w30sm1022357oow.48.2021.02.18.06.56.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 06:56:06 -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: <448DA93B-264D-4BC6-BCC3-22D2712CAFA6@cursive.net>
Date: Thu, 18 Feb 2021 07:56:05 -0700
Cc: cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AD7E189-0AFA-4CFA-8BD5-B08C77B1522B@cursive.net>
References: <87tuqakown.fsf@hobgoblin.ariadne.com> <448DA93B-264D-4BC6-BCC3-22D2712CAFA6@cursive.net>
To: "Dale R. Worley" <worley@ariadne.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/vTwsbxcrhKhw7Vxg9qRnJE5eRKQ>
Subject: Re: [Cbor] Tag 279 "Map entries 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:30 -0000

And, after a couple of hours of sleep, I realized that of course order matters for my use case. 

— 
Joe Hildebrand

> On Feb 18, 2021, at 12:13 AM, Joe Hildebrand <hildjj@cursive.net> wrote:
> 
> (Note that I just accepted a PR from Carsten, so the text has changed ever so slightly)
> 
> The main reason I want a type like this isn't to persevere order, but to round-trip Map instances from JavaScript, through CBOR, and back to JavaScript.  I want to ensure that they end up a Map again, even if they have all-string keys.  Node-cbor currently uses a JS Object if all of the keys are strings, and falls back to a Map if it detects anything other than a string.  Another choice would have been to always coerce CBOR map keys into strings, but that is a little difficult to do in a non-surprising way with structured keys.
> 
> That said, order doesn't hurt my use case, and if someone else wants that, great.
> 
> More comments, questions and pull requests welcome.
> 
> — 
> Joe Hildebrand
> 
>> On Feb 17, 2021, at 8:58 PM, Dale R. Worley <worley@ariadne.com> wrote:
>> 
>> A recent message pointed to:
>> 
>>> https://github.com/hildjj/cbor-map-entries 
>> 
>> I found it an odd read, as I couldn't figure out what the point is.  As
>> written, it's an alternative way to express maps, as a tag applied to an
>> array containing keys and values.  But what's the point?
>> 
>> The text starts off with "Although CBOR has support for generic Maps
>> (Major Type 5), some implementation languages (such as ECMAScript) have
>> two different types they might use to hold the information, depending on
>> whether all of the keys are strings or not."  And it makes sense that's
>> a problem to be solved.  But this document doesn't solve that, in that
>> neither tag-279-array nor CBOR map are constrained to have the keys be
>> strings, so both of them would have to be decoded into a more general
>> data type/structure.
>> 
>> Maybe I'm not read into CBOR enough to understand what is intended.  But
>> it seems to me that this document probably intended to specify that the
>> key values in a type-279-array must be strings.
>> 
>> Dale
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
>