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

Carsten Bormann <cabo@tzi.org> Thu, 15 August 2019 15:25 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA21200BA for <cbor@ietfa.amsl.com>; Thu, 15 Aug 2019 08:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GwPdbTF9ZOi for <cbor@ietfa.amsl.com>; Thu, 15 Aug 2019 08:25:09 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE03120090 for <cbor@ietf.org>; Thu, 15 Aug 2019 08:25:09 -0700 (PDT)
Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 468Vcz5Nfrz10BM; Thu, 15 Aug 2019 17:25:07 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2845175.7IlyYNWCq8@tjmaciei-mobl1>
Date: Thu, 15 Aug 2019 17:25:07 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 587575505.492113-dd67b05139e6bf62a3f45bdf8cb03956
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A28AD58-E2CB-46EC-921C-F35A5F0BBF2D@tzi.org>
References: <156587646384.15832.10776769526244223381.idtracker@ietfa.amsl.com> <2845175.7IlyYNWCq8@tjmaciei-mobl1>
To: Thiago Macieira <thiago.macieira@intel.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/d2zk1d_KHzE37ThE8_FvsECsz3w>
Subject: Re: [Cbor] Publication has been requested for draft-ietf-cbor-array-tags-06
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2019 15:25:12 -0000

On Aug 15, 2019, at 16:56, Thiago Macieira <thiago.macieira@intel.com>; wrote:
> 
> 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?

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