Re: [Cbor] Record proposal

Carsten Bormann <cabo@tzi.org> Wed, 17 November 2021 20:52 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 784883A0542 for <cbor@ietfa.amsl.com>; Wed, 17 Nov 2021 12:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge8mK-qufHKr for <cbor@ietfa.amsl.com>; Wed, 17 Nov 2021 12:52:07 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.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 4A3B53A05A0 for <cbor@ietf.org>; Wed, 17 Nov 2021 12:52:06 -0800 (PST)
Received: from [192.168.217.118] (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 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.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAEs2a6tY02haauD4OL18fp15Zet2bqkq+xVzEvAEiK5cvTpy2w@mail.gmail.com>
Date: Wed, 17 Nov 2021 21:52:03 +0100
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 658875123.895861-82f173e75f180eee381017fb49e0d06d
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C7719D8-8DCB-41BE-9111-882A02D43506@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> <8CA1A63D-70B5-4109-ABE7-9CF9197F0375@tzi.org> <CAEs2a6uTKJ1DOTjREjKaRSY6kNAHSof97OoRAZbjDWOazLQC+A@mail.gmail.com> <CAEs2a6tY02haauD4OL18fp15Zet2bqkq+xVzEvAEiK5cvTpy2w@mail.gmail.com>
To: Kris Zyp <kriszyp@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/pWpu_IV2lg9F-Z0Xv8EXxDM6TLc>
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: 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 <kriszyp@gmail.com> wrote:
> 
> I have updated my tag registration proposal/submission at
> https://github.com/kriszyp/cbor-records 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 <kriszyp@gmail.com> 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:
>> https://gist.github.com/kriszyp/b623b85d2dc25ac9e3b07d8f39df9307
>> 
>> 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
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor