Re: [Cbor] Decoding numbers and compliance verification in dCBOR

Carsten Bormann <cabo@tzi.org> Fri, 10 March 2023 19:14 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 41161C151711 for <cbor@ietfa.amsl.com>; Fri, 10 Mar 2023 11:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRq46bbLO_MY for <cbor@ietfa.amsl.com>; Fri, 10 Mar 2023 11:14:50 -0800 (PST)
Received: from smtp.uni-bremen.de (mail.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98907C151709 for <cbor@ietf.org>; Fri, 10 Mar 2023 11:14:49 -0800 (PST)
Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4PYG2Z6scpzDCbQ; Fri, 10 Mar 2023 20:14:46 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <83BF059D-BEF2-4C5F-9DE8-7A99A529833F@island-resort.com>
Date: Fri, 10 Mar 2023 20:14:46 +0100
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 700168486.51843-591800b755c879cc06b22a80263a579f
Content-Transfer-Encoding: quoted-printable
Message-Id: <8999DCEA-6572-4A69-85EC-AA7AD0170837@tzi.org>
References: <83BF059D-BEF2-4C5F-9DE8-7A99A529833F@island-resort.com>
To: Laurence Lundblade <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/SgqkhFkov83opdlLUOyvwU2xjyk>
Subject: Re: [Cbor] Decoding numbers and compliance verification in dCBOR
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 10 Mar 2023 19:14:56 -0000

Hi Laurence,

I think your arguments are important.
But for a receiver of information, there are also benefits from knowing what to expect.
In particular map processing can be simpler if only a specific sequence of the entries needs to be accepted.

Whether floating point values are important for an application may also influence whether it is worth to expend some additional processing.  The simplest devices often get by without any floating point operations.  Once floating point becomes important for the functioning of a device, processors such as those of ARM’s Cortex M4 series can help reduce the power-hungry on-time of the device by efficiently performing the floating point computations.  With these processors (and certainly with processors of the smartphone, laptop, and server classes), the requirements of dCBOR become almost trivial.

I don’t want to take a particular side here, just point out that not all applications are the same.  Having a go-to profile of CBOR that covers an interesting subset of applications appears to be a net win to me.

Additional CDDL support such as that provided in draft-bormann-cbor-cddl-more-control with .cbordet and .cborseqdet may be desirable.  There is currently no way in CDDL to express the rules about number representation that dCBOR has adopted; that may be one interesting gap.

Little aside: When I started to think about this, I started to wonder: What is the dCBOR way to represent 65536000000.0?

5 bytes:
>> 65536000000.0.to_cbor.hexs
=> "fa 51 74 24 00"

9 bytes:
>> 65536000000.to_cbor.hexs
=> "1b 00 00 00 0f 42 40 00 00”

Here, the floating point representation is shorter…
But wait, even if float32 cannot be exact (e.g., for 65536000001), try:

7 bytes:
>> CBOR.decode("c2 45 0f 42 40 00 01".xeh)
=> 65536000001

9 bytes:
>> CBOR.decode("c2 45 0f 42 40 00 01".xeh).to_cbor.hexs
=> "1b 00 00 00 0f 42 40 00 01”

(Number systems are always an unwieldy part of representation formats.)

Grüße, Carsten