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

[Michael Richardson <[e-mail]>]

{why haven't we adopted this document yet?}

Hi, I've reviewed section 9 of notable-tags-06.
I raised a minor PR: https://github.com/cabo/notable-tags/pull/1
because I had to stare at the [uint,value] part really hard before I
understood things.  Part of the issue is that the "value" in the previous two
cases was just "obvious", and then I couldn't understand what it meant in the
third case.

I understood from the meeting this morning that tag 101 'e', is not actually
available.  But, actually it looks like it is according to IANA.org.
Or was it that another draft wanted it?
How about 'x' (NOPE) 'X' YES. 'u' YES.
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#cbor-tags

I think that the document might explain why we optimize the first 7 (0..6),
rather than the first 3 or 5 or 9.  Are the next 128 worth it?
I wonder if there are more than 7, are there typically more 100s?
If it turns out that 9 is the sweet spot, I'd be okay with more 1+1
and no 1+2.  I don't have any data on this.
I wonder if Michael, Duncan, Jared or Alexander do?

I agree with the discussion that tag 101 could just encode 0..x
rather than uint+128.  I think that the simpler encoder might be worth it
here.  Particularly in some cases where I suspect which ones are the lower
numbered onces might not be known until later, and some code wants to come
back and fill in the alternatives afterwards, having left 1+4 for the uint or
something like that.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide