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

[Michael Jones <[e-mail]>]

> What would be the right size then? 250 million?  220 million?

A typical draft allocating tags allocates a number that you can count on one hand.  Each such tag has a human-readable description of its purpose in the registry so people know what to use them for.

I'd suggest that a reasonable maximum number of tags for a draft to allocate for its purposes is on the order of ten.

If that's not possible for this draft to achieve that, then I suspect that the draft is somehow abusing the tag mechanism to achieve something other than the normal purpose of tags.

				-- Mike

-----Original Message-----
From: Carsten Bormann <[e-mail]> 
Sent: Tuesday, December 10, 2024 9:40 PM
To: Joe Hildebrand <[e-mail]>
Cc: CBOR <[e-mail]>
Subject: [Cbor] Re: Early allocation for packed CBOR (Re: Reminder: CBOR WG Virtual Meeting on 2024-12-11)

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

_______________________________________________
CBOR mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]