Re: [Cbor] Record proposal

Carsten Bormann <> Wed, 17 November 2021 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 784883A0542 for <>; Wed, 17 Nov 2021 12:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ge8mK-qufHKr for <>; Wed, 17 Nov 2021 12:52:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A3B53A05A0 for <>; Wed, 17 Nov 2021 12:52:06 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4HvZqS1p9gz2xNW; Wed, 17 Nov 2021 21:52:04 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 17 Nov 2021 21:52:03 +0100
Cc: Christian Amsüss <>,
X-Mao-Original-Outgoing-Id: 658875123.895861-82f173e75f180eee381017fb49e0d06d
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Kris Zyp <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Record proposal
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Nov 2021 20:52:12 -0000

Hi Kris,

thank you for the update.
I still need to take a closer look, but I have one immediate reaction:
You probably shouldn’t induce implementations to “hijack” a tag number.
The handling of a tag number that has actually been allocated for something else may be deeply embedded into the CBOR decoder; a record implementation then would only see gobbledygook.
So I think we should allocate some space for tag-allocated tags — I don’t see a big problem with allocating a chunk above 32768 just for the record proposal.

Grüße, Carsten

> On 2021-11-17, at 16:16, Kris Zyp <> wrote:
> I have updated my tag registration proposal/submission at
> to use 1+2 tag entries, which
> hopefully makes this a much less intrusive registry entry. I have also
> updated the proposed tag definitions to also support up-front
> declaration of a set of record structure definitions for a data item
> ("around" that data item, like the packed approach, as you suggested),
> in addition to the current inline record definitions (which can be
> scoped with record definitions and should follow a well-specified
> order for when they can be referenced by subsequent references). I
> hope this offers flexibility for encoders that have all structures
> known a-priori and streaming encoders (that do not), while still
> maintaining nearly the same mechanics for decoders. Let me know if you
> think this looks reasonable.
> Thank you!
> Kris
> On Thu, Nov 11, 2021 at 9:15 PM Kris Zyp <> wrote:
>>> Actually, stats would be very interesting.
>>> I was assuming that the 1+1 setup comes with a number of 1+2 referencing records, the hit from going to 1+2 there as well would be relatively insignificant.
>>> Number are better than assumptions!
>> You are definitely right, using 1+2 tag for defining records is pretty
>> insignificant (around a quarter of percent in my tests). Anyway, I put
>> together some tests comparing CBOR packed, record structures, and
>> combinations with a couple test data structures, with my library, for
>> the sake of further comparisons:
>> Anyway, seeing this, I am happy to go ahead and update my proposal to
>> use a 1+2 tag for defining records. And thinking about this, I don't
>> think my proposal necessarily even needs to mandate the tag ids used
>> for referencing records since those are dynamically assigned and
>> explicitly specified by the encoder itself (encoder obviously must not
>> conflict and use tag ids that will be used for other purposes), albeit
>> can encourage a certain range (presumably from the first-come
>> first-serve range).
>> Do you have any preference for a tag id to use? It looks like 279 is
>> the next in the contiguous block, but sounds like choosing aesthetic
>> characters is the new preference (29299/"rs" perhaps).
>> Anyway, thanks again for the helpful feedback, really appreciate it!
>> Thanks,
>> Kris
> _______________________________________________
> CBOR mailing list