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

[Rohan Mahy <[e-mail]>]

I agree with Joe on this one.

> What would be the right size then? 250 million?  220 million?
How many 1+1 tags and 1+2 tags should you be able to consume?  *FIVE* per
RFC seems like a reasonable limit. I have no objection to allocating as
many 1+4 or 1+8 tags as you'd like.

Thanks,
-rohan

On Tue, Dec 10, 2024 at 9:40 PM Carsten Bormann <[e-mail]> wrote:

> 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]
>