Re: [Cbor] Record proposal

Carsten Bormann <cabo@tzi.org> Thu, 11 November 2021 17:00 UTC

Return-Path: <cabo@tzi.org>
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 AF9623A0CD6 for <cbor@ietfa.amsl.com>; Thu, 11 Nov 2021 09:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcfNT7GH_O2E for <cbor@ietfa.amsl.com>; Thu, 11 Nov 2021 09:00:29 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFD13A0CD2 for <cbor@ietf.org>; Thu, 11 Nov 2021 09:00:29 -0800 (PST)
Received: from smtpclient.apple (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (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.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAEs2a6sZd4s-DJ3R_M4BLwO12s8i2AGfv0yXCaWdy+baOuAEqw@mail.gmail.com>
Date: Thu, 11 Nov 2021 18:00:22 +0100
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CA1A63D-70B5-4109-ABE7-9CF9197F0375@tzi.org>
References: <CAEs2a6vNhrHhaiPUNtbJ68WYfbrprETPr+kmWNJgNXMSawyBig@mail.gmail.com> <E3F121DA-95EE-43C6-BC72-E3763C034944@tzi.org> <CAEs2a6uZrT9FFP6qa+hPV2sYO0y+xJJmLaF-pPoynE2vqspfBg@mail.gmail.com> <CAEs2a6uHyvvghAMCN=UmhpJMoiES7zoPmGi-bATZWXgjA068Mg@mail.gmail.com> <YY0B4YxuMuw20umu@hephaistos.amsuess.com> <CAEs2a6utA=GQSx2Ln=5wnoNdS6z+0ExdCcfNXG6cAg=1MxnT=w@mail.gmail.com> <901541DC-A520-44CD-AA8D-F2CE77F03FA0@tzi.org> <CAEs2a6sZd4s-DJ3R_M4BLwO12s8i2AGfv0yXCaWdy+baOuAEqw@mail.gmail.com>
To: Kris Zyp <kriszyp@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/U1WZlqXngtq0hmSQBwiNUVoN_Bc>
Subject: Re: [Cbor] Record proposal
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: Thu, 11 Nov 2021 17:00:33 -0000

On 11. Nov 2021, at 16:35, Kris Zyp <kriszyp@gmail.com> 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