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

Hi Michael,

> I'm not sure what the status of this proposal is. It seems like there's broad agreement that this is desirable, but we don't have consensus on the exact tags to use. How can we reach consensus here? Would it be useful to provide a summary of alternatives and vote?

We don’t vote in the IETF…

The last communication from Christian was that he could live with the allocation as proposed in draft-bormann-cbor-notable-tags-06.  (We are only 5 1+1 tags apart, so it’s not such a big different anyway.)

(There is one PR that adds text and that will be in -07; that has no bearing on the registration.  I finally fixed the CI that was stuck, so you can see the diff from the link “Compare Editor's Copy to Individual Draft” in the README at https://github.com/cabo/notable-tags .)

To push this forward, you could send in the registration request to IANA pointing to https://datatracker.ietf.org/doc/html/draft-bormann-cbor-notable-tags-06.txt#section-9.1

Please use the form at:

https://www.iana.org/form/protocol-assignment

You can just point to the section 9.1 as an answer to all questions (except your name :-).

We’ll then see whether IANA sees me as an author of this spec (which I’m not really, but my name is on the draft), in which case the other designated expert (Christian) has to make the determination.

Christian is on vacation right now, so his approval could take a couple of weeks.

Grüße, Carsten

> 
> Best wishes,
> Michael
> 
> On Wed, 20 Apr 2022 at 16:18, Christian Amsüss <christian@amsuess.com> wrote:
> Hello Michael, Carsten,
> 
> On Thu, Feb 24, 2022 at 02:12:43PM +0000, Michael Peyton Jones wrote:
> > If you'll permit me a toy example, suppose we have a balanced
> > binary tree of numbers. In Haskell, the data type definition would look
> > like this:
> 
> Right, multiply tagged items are something I did not consider
> originally. (My mental model for these was shaped by Rust where there is
> often type information available, so that an Option<Option<Option<u8>>>
> has all the information available to still fit in 16 bit, but that's of
> course only available on types that are just repetitive and not
> recursive).
> 
> I'd still be slightly happier if this would take less of the 1+1 space
> (121 and 122, maybe? That would suffice for the deep parts of the tree),
> but given it also has Carsten's support (who is the other expert for the
> registry), I'd be OK with it.
> 
> The policy for registering these are "specification required", so it all
> doesn't have to wait for notable-tags to be full and done -- and I'm
> just about to send out another mail suggesting to use this. What's your
> plan for progressing with this?
> 
> BR
> Christian
> 
> -- 
> There's always a more constrained fish.
>   -- Qui-Gon Jinn
> 
> 
> -- 
> 
> Michael Peyton Jones
> Software Engineering Lead | London, UK
> 
> Website: www.iohk.io
> Skype: michael.s.pj
> Twitter: @mpeytonjones
> PGP Key ID: 29F64616
> 
>  
> 
>    
> 
> 
> This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor