Re: [Cbor] Record proposal

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