[Cbor] Re: Early allocation for packed CBOR (Re: Reminder: CBOR WG Virtual Meeting on 2024-12-11)

[Carsten Bormann <[e-mail]>]

On 11. Dec 2024, at 02:57, Joe Hildebrand <[e-mail]> wrote:
> 
> I do not agree that 335 million tags, including most of the remaining 1+1 tags is worth the functionality here.

The functionality would indeed stay the same with fewer tags allocated.
What would be the right size then? 250 million?  220 million?

We are allocating a large number (1/13 of the space) of 1+4 tags (which are cheap) to ensure this mechanism doesn’t run into arbitrary limitations.  This is well worth it, so I don’t see how the absolute number of tags is important here.

The 1+1 space is much more critical, indeed.
But I don’t know why you are saying we are using up “most of the remaining 1+1 tags”.
As I wrote, there are 159 1+1 tags remaining, and the proposed allocation is one fourth of that (sorry for my slightly off math in the previous message), commensurate with the foundational importance of this mechanism.

I think we don’t have the same perception on how important the CBOR-packed mechanism is for data items that both need to limit their encoding space and stay efficiently implementable on constrained nodes (which rules out data compression like brotli or zstd).

To give just one example how CBOR-packed can be changing the landscape, look at JSON-LD, which has elevated a form of compression into the application data model by using CURIEs.  CBOR-packed is obviating the need for that.  Clipping the wings of CBOR-packed is not going to help here.

Grüße, Carsten