Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deficient architecture of 256 tags and unclear spec w/o examples #38

Open
nuclight opened this issue Dec 14, 2024 · 0 comments
Open

Deficient architecture of 256 tags and unclear spec w/o examples #38

nuclight opened this issue Dec 14, 2024 · 0 comments

Comments

@nuclight
Copy link

Specification uses range of 256 CBOR tags, a very large interval, together with scheme when this range is not enough and "varint" is needed. However, there is not clear from the spec neither if such complex scheme is justified nor what exactly "varint" is (so at the very minimum this is what should be fixed). Moreover, spec lacks any examples at all, either in CBOR diagnostic notation and/or binary (hex) representation.

For example, it is not clear if map tagged with that tag range appears once per document or multiple times. But in either case, allocating a whole 256 tags in 2-byte range from IANA is not justified:

  1. if it's once, then only ONE tag is enough, always tagging array whose first member is exact Varint or even just CBOR integer - it's compact enough.
  2. if it may be used multiple times, then for 3 bytes of tag another 2 bytes, for array start and bytestring start (also, why string? integer 0-23 could be more compact here), are waste, before actual value continuation starts. Observe that CBOR value can have MULTIPLE tags prepended to it, so here possibilities are:
    • combine several tags of same range, just multiplying their values
    • or better, use already registered "alternatives" CBOR tag set, which, for large values with array[uint, any] has shorter tag 101, for six values 1 byte of tag and for 127 values already registered range 1280-1400. This tag definition perfectly fits with CBOR-LD use, and requires registering just one top-container tag inside which spec says "alternatives are to be interpreted as Registry Id".

In any case, I will vote against allocating such a wasteful range of tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant