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

Joe Hildebrand <hildjj@cursive.net> Mon, 15 March 2021 20:21 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 A96D23A07C8 for <cbor@ietfa.amsl.com>; Mon, 15 Mar 2021 13:21:18 -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 QyCuiW9CYXaz for <cbor@ietfa.amsl.com>; Mon, 15 Mar 2021 13:21:17 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 ABB453A0744 for <cbor@ietf.org>; Mon, 15 Mar 2021 13:21:17 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id u62so19979345oib.6 for <cbor@ietf.org>; Mon, 15 Mar 2021 13:21:17 -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=0vz4VMLseAwfPJNoQB7WrxyVYet5A0TwY4NEToMs5Tc=; b=Nig9cvHV0hDyMmEwcsL7OFxIq3l8QtMBlF3rykm6OGfzHpLR/1PRKpzZu+l+exKd01 VzeYJF8HIs+OtRU6B2fJ4n/PFBllmDnTDhACclMqEWoSHCb1qQK373K0Q5C8bN3hxvNG qpeLs5eTH5y5Fve90LMCLTrHsBkK702sZ07m0=
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=0vz4VMLseAwfPJNoQB7WrxyVYet5A0TwY4NEToMs5Tc=; b=EBiQ6YqQ3qC48OkjAAiXDgFDzSzKCZ1ToBE6cSMkzJmrWsNJHWSOmtYqaVM9zEQhaE LE1spKjK30lAAMCDS3ieCOq9jyuF7+vBDuvT7ecbUIYSAN1yprB76fysmmM7OSm80mms GC7S0VjeKGjhqPhODsXFnwnr3ssLm86OIfYgL+iTXcLnNnV5m6sATXTl5XAlYjKNofgZ iiJ4JQ2eElBiyYONC9EFLyeI4g0qdd0iuY6UEYoKNXDep1UGEiUqv2Vbfk54Vlx71dhT k++fa1n/LUAcJeKQz1gSm0kYxR+Xt4uccHPzWZWqW6/kGlZ23sK2WgNhz2yZ2r8ZnEM3 J0cQ==
X-Gm-Message-State: AOAM532QvCFxPizyaavMhMGm+rhCCFTChBm2Zk2AaYgPSONUfV4NHspo EF5ujYhTrf6oyiti776kxXCCMA==
X-Google-Smtp-Source: ABdhPJwLHPpb9/GQsC73dKZ8GkNlJ12s7RHs9M4isLq9f55Q9M/hO9DbciHKL2PFVwqRdu7DnXtJ4A==
X-Received: by 2002:aca:482:: with SMTP id 124mr642270oie.21.1615839676181; Mon, 15 Mar 2021 13:21:16 -0700 (PDT)
Received: from ?IPv6:2601:282:200:3758:b10e:3847:34b3:46d6? ([2601:282:200:3758:b10e:3847:34b3:46d6]) by smtp.gmail.com with ESMTPSA id c9sm6924795ooq.31.2021.03.15.13.21.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 13:21:15 -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: <CAM70yxC3px4U_aVv0yNNL8t-m+Vt3ftLKvUfhsCNHS2sqzM5Fg@mail.gmail.com>
Date: Mon, 15 Mar 2021 14:21:14 -0600
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1629FF2E-05D6-456E-AF3C-913F8CB3E55C@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>
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/g1nKeIdEIm4cA0FgvztXmZqqnY4>
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 20:21:19 -0000

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