Re: [Cbor] Record proposal

[Carsten Bormann <[e-mail]>]

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