Re: [Cbor] Record proposal

[Carsten Bormann <[e-mail]>]

On 11. Nov 2021, at 16:35, Kris Zyp <[e-mail]> 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