Re: [Cbor] Record proposal

Carsten Bormann <> Thu, 11 November 2021 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF9623A0CD6 for <>; Thu, 11 Nov 2021 09:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JcfNT7GH_O2E for <>; Thu, 11 Nov 2021 09:00:29 -0800 (PST)
Received: from ( [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFFD13A0CD2 for <>; Thu, 11 Nov 2021 09:00:29 -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 4Hqnyt4KX5z2xJh; Thu, 11 Nov 2021 18:00:22 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 11 Nov 2021 18:00:22 +0100
Cc: Christian Amsüss <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Kris Zyp <>
X-Mailer: Apple Mail (2.3654.
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: Thu, 11 Nov 2021 17:00:33 -0000

On 11. Nov 2021, at 16:35, Kris Zyp <> wrote:
> Thank you for the explanation of your allocation strategy, really
> appreciate it, that makes sense. It does seem a little surprising to
> me that some of the 1+1 tags that are explicitly for very specific
> technologies (Perl,

We were young when we did this…
Seven years later, RFC 8949 has adjusted the RFC 8126 policies only slightly, but with an understanding that 1+1 will be guarded more tightly.

> YANG, Internet of Data things, etc.) would be
> considered more "common" than a record structure designation, a
> concept that I think is broadly used across many/most programming
> languages. And it seems like many of these registrations would not
> have a greater need for being short than a tag that specifically
> yields significant and broad opportunities for dramatically improving
> encoding efficiency/compactness (I don't know if you are interested in
> some stats on that?).

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!

> I would certainly argue that the broad semantic
> application and the significant encoding efficiency benefits would
> justify a 1+1 tag for a tag record. But if only 1+2 tags are being
> permitted or strongly preferred, I can certainly adjust to that
> criteria. If I resubmit with a 1+2 tag would that be easier for
> registration, and would it be possible to have it submitted with
> possible future consideration for upgrade to a 1+1 tag?
>> ...requiring data in the first record that also usually sets the base configuration...
>> (In cbor-packed, we put the setup *around* the data — another variant that you might want to look at.)
> It seems like the significant problem with using an "around" type of
> structure is that it requires an a priori knowledge of the structure
> of the data that will be encoding prior to beginning encoding.

That is a very valid argument.
(We may want to revisit cbor-packed as well with respect whether the sender or the receiver pays that tax.)

> […]
> I had actually also been meaning to ask how this type of streaming of
> data might work with the combination of cbor-packed and
> cbor-sequences. It seems like a particularly valuable use case for
> packed CBOR is in being able to create a socket for sending a sequence
> of CBOR messages (between two remote hosts, for example), and sending
> a packing table with values that are/will be frequently used in the
> stream/sequence of CBOR messages.

Yes, table setup that transcends a single CBOR data item in a sequence has been brought up before.
Maybe it’s time to flesh out that design.

> And if you believe that resubmitting
> this tag registration with a 1+2 tag (probably 29299 based on your
> ascii suggestion) would be the best course for getting registered, I
> can proceed with that.

Let’s see the numbers, but I do believe this would streamline the registration.

Grüße, Carsten