Subject: [Cbor] Publication has been requested for draft-ietf-cbor-array-tags-06

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Thu, 15 Aug 2019 06:41:03 -0700

Francesca Palombini has requested publication of draft-ietf-cbor-array-tags-06 as Informational on behalf of the CBOR working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/

---

From: Thiago Macieira <[email-masked]>
Date: Thu, 15 Aug 2019 07:56:23 -0700

On Thursday, 15 August 2019 06:41:03 PDT Francesca Palombini via Datatracker 
wrote:
> Francesca Palombini has requested publication of
> draft-ietf-cbor-array-tags-06 as Informational on behalf of the CBOR
> working group.
> 
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/

What's the correct procedure to request that bfloat16 be considered before the 
RFC is published?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Aug 2019 17:25:07 +0200

> What's the correct procedure to request that bfloat16 be considered before the 

Make a comment in the working group last call that ended on March 20 :-)

But seriously speaking, there is a larger variety of 16-bit floating point formats than for the longer sizes, probably because it matters more how exactly you spend the bits if you have so few.  Bfloat16 (*) is one of the more prominent ones (ARM’s modified finite-only binary16 comes up as another one).

Not sure handling these would fit this draft, as it really tries to follow JavaScript typed arrays [1] and round those out at the corners by taking the next sizes defined in the referenced standards.

I think that writing a brief new document that allocates a tag or two for be/le bfloat16 typed arrays would be the obvious next step (and I sure can help you with generating that document next month, if you want).  If you think this should go into the existing specification instead, making a comment to this mailing list is a good first step (which you did); you could also make a more formal comment at the IETF last call that is likely to be next after AD review.

In the long run, we’d also have to consider hybrid formats such as RGBE (which is approximately the 3-dimensional, unsigned version of bfloat16), so maybe it’s worth casting a wider net and see what requirements are out there first.

Whether the CBOR WG is interested in picking this up or it simply goes the specification required route is another question; this is probably best discussed when we know what else is needed.

Grüße, Carsten

(*) binary32 truncated to 16 bits.  
(How do I get my system not to autocorrect bfloat16 into bloat16?)
[1] https://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects

---

From: Thiago Macieira <[email-masked]>
Date: Thu, 15 Aug 2019 09:03:33 -0700

On Thursday, 15 August 2019 08:25:07 PDT Carsten Bormann wrote:
> I think that writing a brief new document that allocates a tag or two for
> be/le bfloat16 typed arrays would be the obvious next step (and I sure can
> help you with generating that document next month, if you want).  If you
> think this should go into the existing specification instead, making a
> comment to this mailing list is a good first step (which you did); you
> could also make a more formal comment at the IETF last call that is likely
> to be next after AD review.

Can you at least reserve the full 32 tag range that would be allocated if the 
sign bit were used, then? That is, from tags 64 to 95, instead of just 64 to 
87.

Of course, bfloat16 doesn't need to be in that range, but it makes as much 
sense to use it as the little-endian 8-bit trick you used there.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Aug 2019 18:39:37 +0200

> sign bit were used, then? That is, from tags 64 to 95, instead of just 64 to 

The CBOR tags registry does not have any mechanics defined for reserving ranges.
Of course, we could reserve 88 to 95 like we reserved 76.  Then we’d need to make RFCs to unreserve those numbers when we need them.

(88 and 92 would be the obvious candidates for be/le bfloat16 for me, if the objective is to keep implementations of the entire gamut simple.)

Grüße, Carsten