Re: [Cbor] A CBOR tag for alternatives/unions, request for comments

[Christian Amsüss <[e-mail]>]

Hello Michael, Carsten,

putting my designated-expert hat on because this will sooner or later
reach me through the review that'll be asked for the 24-32767 range.

On Wed, Feb 23, 2022 at 02:16:14PM +0100, Carsten Bormann wrote:
> Current state of tag allocation:
> range  used     %                 free                total
> 0 1+0    12 50.00                   12                   24
> 1 1+1    62 26.72                  170                  232
> 2 1+2    45  0.07                65235                65280
> 3 1+4     3  0.00           4294901757           4294901760
> 4 1+8     2  0.00 18446744069414584318 18446744069414584320

this is asking 6 (in discussion with Michael, 8) out of the ~170
remaining short tags. Chunk allocations are not unheard of, and it's not
a particularly large chunk, but given that this is not a case coming
from the constrained or high-volume applications that CBOR was designed
for, I'd like to confirm:

Does it, for the applications expecting to use this, make a noticable
difference whether a 1+1 or a 1+2 tag is used?

(The difference is likely most pronounced on alternatives without actual
payload; expressing the two values of `Either () ()` (if I'm getting this
right; in Rust I might say `Result<(), ()>`) would take 4 byte each vs.
3 byte each for the full value including the tagged nil / empty-tuple).

If not, I'd suggest that, say, 128 tags could be requested from 1+2,
leaving the 1+1+1+(2..) version for the unbounded range.

If so, please provide some note about how this does make a difference,
which I can refer to when eventually reviewing the entry.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom