Re: [Cbor] Consolidated set of tags for map-like entities

Joe Hildebrand <hildjj@cursive.net> Tue, 16 March 2021 17:20 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 0751A3A14B0 for <cbor@ietfa.amsl.com>; Tue, 16 Mar 2021 10:20:30 -0700 (PDT)
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 e5YDsB7L7Uth for <cbor@ietfa.amsl.com>; Tue, 16 Mar 2021 10:20:28 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 A054E3A14AD for <cbor@ietf.org>; Tue, 16 Mar 2021 10:20:28 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id s1so13372792ilh.12 for <cbor@ietf.org>; Tue, 16 Mar 2021 10:20:28 -0700 (PDT)
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=GV2MUN/JO4a8x0f51wRB5wD1FBwxT3xdK1cGjJwdWdI=; b=YQjzk36FG0YwTsK9YGhW0X1xeBwZUIXoz3H1weDIc5HgZFtvMo/RolZJNxCx8nSdXq mvjDL+R7+EX81/uL3gk6Tc3SdC1117ylscNkqiZISxRlAkQTnjWopJVPNABO+u4kcEvZ fi2t+d+IPF63H+Pp79IMlocbDEuxDebNYM4QQ=
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=GV2MUN/JO4a8x0f51wRB5wD1FBwxT3xdK1cGjJwdWdI=; b=oW7iUkvKVGVvf6nTu7OeYIFzcBrXB0A5pVsm0LyDvk2n11ILuAMg4MxnTNsOlbXRyZ shhns/EWvRNvj+X4QS9Fh0SBKEuRmsXxUyaxshXnj7gEjgU6e9lC/vFuKIxXk7bxG7Ij jDonM5ZWnNSXHg/YC1Agree6LtIy+rR6Ajnvrm3lAajUh2M+7yZBVx6mI82MMD0sEPXc h22xX2ocfFiVkFZZpGEKNkK7ONcWtL/pwN7s+mzClCVc4MwoDDqBZtWGuiZE9nt3uMzU Ws8B2wWQylxtkhtSzUZMS3EkWmHf/02RX3jZV2VgZ1L4WuqYNA+QzpMHeaIRn7Hd5sit 2WaQ==
X-Gm-Message-State: AOAM533y0EO+aJXmWr6xmNqVg2rb4PcARy1HfaZFG9V8eLGwwh5FQBZQ kBK/j5qE7MMezLK5KAtGsQhufw==
X-Google-Smtp-Source: ABdhPJxf3jbkb4IOkUcLpNPVPpPr7UdnZ57Kp1XKSRnoVGkMyDSNcV/3Ilhj5wNHkaQNAf69+2AReg==
X-Received: by 2002:a92:c04b:: with SMTP id o11mr4409241ilf.42.1615915227311; Tue, 16 Mar 2021 10:20:27 -0700 (PDT)
Received: from ?IPv6:2601:282:200:d1:3543:8df2:4aac:6ff? ([2601:282:200:d1:3543:8df2:4aac:6ff]) by smtp.gmail.com with ESMTPSA id l16sm9754528ils.11.2021.03.16.10.20.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Mar 2021 10:20:26 -0700 (PDT)
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: <CAM70yxBv5JwSCUML1mJdDssQwUhTOy2QJKFOsEQ+DppOsXbmyg@mail.gmail.com>
Date: Tue, 16 Mar 2021 11:20:26 -0600
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D855B6A2-573D-4F8D-8666-55BA5A7F4DA1@cursive.net>
References: <CAM70yxC7o3CNz67Yx3-yLt3tPQaTRaezOO99Ssa-3ppu-NwD=Q@mail.gmail.com> <C2B0934A-2AAB-4A45-A354-407782B4CA0B@cursive.net> <FA5E389C-C577-4D42-A19E-A3A50F14F730@tzi.org> <16642498-C82F-41CE-A06D-6C762AEEB6F9@cursive.net> <CAM70yxC3px4U_aVv0yNNL8t-m+Vt3ftLKvUfhsCNHS2sqzM5Fg@mail.gmail.com> <1629FF2E-05D6-456E-AF3C-913F8CB3E55C@cursive.net> <CAM70yxBv5JwSCUML1mJdDssQwUhTOy2QJKFOsEQ+DppOsXbmyg@mail.gmail.com>
To: Emile Cormier <emile.cormier.jr@gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Fs1NMOHdFS8qmJdnYUNtAGiajHU>
Subject: Re: [Cbor] Consolidated set of tags for map-like entities
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: Tue, 16 Mar 2021 17:20:30 -0000

Your approach makes sense to me.

Is there any benefit to using map over array for your approach?  They're roughly the same on the wire.

— 
Joe Hildebrand

> On Mar 15, 2021, at 3:15 PM, Emile Cormier <emile.cormier.jr@gmail.com> wrote:
> 
> Indeed, I try to feed bytes from the wire into its resulting data structure as directly as humanly possible in my C++ implementation, while not having to write decoders by hand for every possible data structure. While CBOR itself is schema-less, our applications use CBOR (and JSON) to transfer entities with known schemas at the application level. I can therefore skip generating intermediate "document" trees and store the CBOR directly into the intended data structure (this is the idea behind https://github.com/OneNoteDev/GoldFish, which is partly inspiring my work-in-progress C++ serialization library).
> 
> I know I could use Flat Buffers with fixed schemas, but I'd end up having to copy everything to standard library containers unless I'm willing to have Flat Buffers "infect" my entire application instead of remaining at the boundary. I also like the self-describing nature of CBOR for diagnostic purposes, plus it's easier to transcode it into JSON for web browser clients.
> 
> 
> On Mon, Mar 15, 2021 at 5:21 PM Joe Hildebrand <hildjj@cursive.net> wrote:
> Ah, I think I see the difference in implementation that others must have.  I always generically decode the data item first, *then* apply the tag transformation.  This allows me to return a generic Tag implementation if I don't support the tag, or a more-specific type or error-check if I do support the tag.
> 
> Others must do special-case decoding of the data item for each tag they support.
> 
> — 
> Joe Hildebrand
> 
> > On Mar 15, 2021, at 2:09 PM, Emile Cormier <emile.cormier.jr@gmail.com> wrote:
> > 
> > I don't know anything about "mt5", but with my proposed tag set, you could check for the presence of tag 132 (homegenous key) and you would know after decoding the first key if all the key-value pairs can be safely decoded into a JS Object. Of course, this requires that the sender "play along" and actually bothers to use the tags.
> > 
> > On Mon, Mar 15, 2021 at 4:44 PM Joe Hildebrand <hildjj@cursive.net> wrote:
> > > On Mar 15, 2021, at 12:51 PM, Carsten Bormann <cabo@tzi.org> wrote:
> > > 
> > > On 2021-03-15, at 19:50, Joe Hildebrand <hildjj@cursive.net> wrote:
> > >> 
> > >> Data Item being major type 5 should really only be used if the keys are homogeneously strings, in my opinion.
> > > 
> > > We are using a lot of integer labels with mt5, so why would we make that restriction?
> > 
> > This is a consequence of my implementation that others probably don't have.  When decoding mt5, I always keep a set of [key,value] tuples until all of the items have been decoded.  Then, if the keys are all strings, I convert the tuples to a JS Object, otherwise I convert them to a Map.  If I've already converted to a Map in mt5 processing, it's too late to (for example) throw an error if there is an unexpected duplicate key.
> > 
> > — 
> > Joe Hildebrand
>