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

[nuclight]

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.

[dlongley]

Thank you for your feedback! The specification now uses a single CBOR tag ("51997" / "0xcb1d"):

https://json-ld.github.io/cbor-ld-spec/#cbor-tag

Closing.