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

Emile Cormier <emile.cormier.jr@gmail.com> Mon, 15 March 2021 21:15 UTC

Return-Path: <emile.cormier.jr@gmail.com>
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 86A663A0EF4 for <cbor@ietfa.amsl.com>; Mon, 15 Mar 2021 14:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pCjSwgYkRGrt for <cbor@ietfa.amsl.com>; Mon, 15 Mar 2021 14:15:22 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 B087E3A0EF3 for <cbor@ietf.org>; Mon, 15 Mar 2021 14:15:22 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id q5so8561971pgk.5 for <cbor@ietf.org>; Mon, 15 Mar 2021 14:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ARmwvLWolSVlHnk0UBYw/KZdYGrh0KGIh6EHklUiWnw=; b=Ua+D+pxLJLAXEgylpk4Lt0aMQ5FeNm4Tv/4G9ux5GJYrVitSYRBCI6v6q++3CkPzdw 7KBEU8zmVSBulreT/8DhhjzpDFhR1RLInIjXu2cXOAtydl9G0KRDyvDHrY3oNGqVceh8 dKH/CKi4LiNNWAlL19o6/uGzA+gMlXdAtnJW0sFa0u2e7DQv4sg4HI0pj5QTLPs1OlKP dO7OFDYdJGPyGTPSSt1LpPmYFllNYriYgB6s2QGZsWoDSKMFCPt4bUVMDOtyJOKNmZEi /1GFMNAe+JkbmrvNLnTBVRf0ujJeXGgzwhCo5yFw057zwk1Ci+RqD/3qwz9cSPAnr7UA 6b7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ARmwvLWolSVlHnk0UBYw/KZdYGrh0KGIh6EHklUiWnw=; b=VR3CjMvK2N6HmPmzk7qcHgGmgq8/FKV8BHC04JG6CHt7hCIUKTvZBfo/7vDKtm9vnp a1t2L7bShfhT0na+sQXMqFNJPmZAN4veGZ5e++rfQYOKo/wSiY70mkpg7GlxZkx89y1F C+dKBS21yaui4rqm6woh/F6C++ygq38arhOnR3uWXPX9U6soClxZz8tt230WwTJUzkxt kmoO1Tq6L9nT70RPRaguVLpjvhyqM6b6zITtgf0R7TZlS3R5TsRl94SeaoeT7FUDbD9z v8gIgtQCe83XWFAGIjxv/7NHkurxamVZUdIA+gPXTx5+XYKNi4dY+2DQwRI6/rKITYzR 7teA==
X-Gm-Message-State: AOAM533K5+14BvcDGACy6khD2mVg492u9Sx8xOHKsfKTZCLjI3Q8Wr+V hiMlH/StCgGe1h9sKmC0ZHN5CfXmHPs2CeXjQTo=
X-Google-Smtp-Source: ABdhPJwLWNDVyEG32le3Hhf3+SVMFWqDJQhrf7dzbly/Zt8gxUW2PxR46uOhJPdkA8Vz46Zu4W4VfWm7bqbMODRiWco=
X-Received: by 2002:a63:b12:: with SMTP id 18mr882594pgl.45.1615842922245; Mon, 15 Mar 2021 14:15:22 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <1629FF2E-05D6-456E-AF3C-913F8CB3E55C@cursive.net>
From: Emile Cormier <emile.cormier.jr@gmail.com>
Date: Mon, 15 Mar 2021 18:15:11 -0300
Message-ID: <CAM70yxBv5JwSCUML1mJdDssQwUhTOy2QJKFOsEQ+DppOsXbmyg@mail.gmail.com>
To: Joe Hildebrand <hildjj@cursive.net>
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org
Content-Type: multipart/alternative; boundary="00000000000064b3ea05bd99bf79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/R7kXkL3O7BEhcqB6pCaGVo6uxcc>
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: Mon, 15 Mar 2021 21:15:25 -0000

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
>
>