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

[Joe Hildebrand <[e-mail]>]

Agree.  RFC 8746 is I think the previous record-holder, I think, at 27, and I still think it should have been handled with at most 4 tags.

Short arrays are really cheap in CBOR.

— 
Joe Hildebrand

> On Dec 10, 2024, at 10:57 PM, Michael Jones <[e-mail]> wrote:
> 
>> 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]