Re: [Cbor] Record proposal

Carsten Bormann <cabo@tzi.org> Thu, 11 November 2021 14:22 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 A5EFB3A003F for <cbor@ietfa.amsl.com>; Thu, 11 Nov 2021 06:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gw3XTwI_L6Cf for <cbor@ietfa.amsl.com>; Thu, 11 Nov 2021 06:22:29 -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 5A1A13A005C for <cbor@ietf.org>; Thu, 11 Nov 2021 06:22: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 4HqkSf1m4dz2xLY; Thu, 11 Nov 2021 15:22:26 +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: <CAEs2a6utA=GQSx2Ln=5wnoNdS6z+0ExdCcfNXG6cAg=1MxnT=w@mail.gmail.com>
Date: Thu, 11 Nov 2021 15:22:25 +0100
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <901541DC-A520-44CD-AA8D-F2CE77F03FA0@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>
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/Esf5m7LLvriY3bqnViCrpMS3314>
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 14:22:34 -0000

Hi Kris,

I’ll come back to testing cbor-packed…

On your proposal:

This is an overview over the tags currently registered:

range  used     %                 free                total
0 1+0    12 50.00                   12                   24
1 1+1    62 26.72                  170                  232
2 1+2    45  0.07                65235                65280
3 1+4     3  0.00           4294901757           4294901760
4 1+8     1  0.00 18446744069414584319 18446744069414584320

In RFC 8949, we have said about the ranges

   New entries in the range 0 to 23 ("1+0") are assigned by Standards
   Action.  New entries in the ranges 24 to 255 ("1+1") and 256 to 32767
   (lower half of "1+2") are assigned by Specification Required.  New
   entries in the range 32768 to 18446744073709551615 (upper half of
   "1+2", "1+4", and "1+8") are assigned by First Come First Served.
   The template for registration requests is:

The idea with 24 to 255 is to be a bit frugal with those tags:  They have to last us a few decades, so we shouldn’t be spending more than a few percent per year.
We mostly want to use these for very common tags that actually can benefit from being very short.

The most recent registration was 25441, which — with respect to the expected usage probably has a larger tag-to-data ration than the record proposal (at least when looking the size over all records).
So I think I’d prefer going for a 1+2 tag — you may want to look for a nice ASCII pair like 25441 did.

With respect to the structure:
In SenML we made the mistake of requiring data in the first record that also usually sets the base configuration.
I’m not sure whether that is a mistake for the record proposal, but I think I would prefer to separate the record setup from the first data item.
That is of course your decision, make that change only if it appeals to you.
(In cbor-packed, we put the setup *around* the data — another variant that you might want to look at.)

Grüße, Carsten