Re: [Cbor] Record proposal

[Carsten Bormann <[e-mail]>]

On 2022-04-01, at 23:36, Kris Zyp <[e-mail]> wrote:
> 
> I just wanted to check again on the status of the requested CBOR
> records (https://github.com/kriszyp/cbor-records) registration in the
> registration table. Now that it is just using tags > 32767, according
> to the registry, it shouldn't even require a specification, just a
> "first come first serve" request?

Indeed.  Thank you for the most recent update of the specification.

I believe this can now be submitted to IANA, which you can do by mail to [e-mail] or more formally correct by filling in the form at https://www.iana.org/form/protocol-assignment, in both cases pointing to https://github.com/kriszyp/cbor-records#readme as the specification.

Grüße, Carsten


> Thanks,
> Kris
> 
> On Thu, Dec 2, 2021 at 2:49 AM Emile Cormier <[e-mail]> wrote:
>> 
>> On Thu, Dec 2, 2021 at 3:35 AM Carsten Bormann <[e-mail]> wrote:
>> 
>>> 
>>>> Without the semantic meaning, there isn't data loss; raw CBOR structures could always be transcoded to JSON or anything else (with conventions for tags and such)
>>> 
>>> That doesn’t work in general: An array with two elements could be a valid data item as well, so you get ambiguity.
>>> Tags provide with a clean way to extend the data model.
>> 
>> 
>> For the record, the "Without the semantic meaning, there isn't data loss..." remark was by Kris, not me.
>> 
>> I think it would have been cleaner for extensions to the data model to be done purely in terms of the core data model. All tags should do is *identify* the new data type and not provide a few extra bytes of storage to that new data type.
>> 
>> Well it seems the genie is out of the bottle in terms of tag ranges being used to "cheaply" store a few bytes of extra information and I'm not going to convince you of putting the genie back in. :-)