From nobody Wed May 31 02:17:21 2023 Return-Path: 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 AF772C15108C for ; Wed, 31 May 2023 02:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.995 X-Spam-Level: X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qualcomm.com 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 HxpFQU73suas for ; Wed, 31 May 2023 02:17:15 -0700 (PDT) Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259E4C14F74E for ; Wed, 31 May 2023 02:17:15 -0700 (PDT) Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 34V4Ofsp007423; Wed, 31 May 2023 09:17:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=qcppdkim1; bh=Mwq2bZt09u9EYXQ0L+Bba5/vygis0PWgVT8Pyeys9EE=; b=LKgkuUeeVyE7/8zTbpgFkblvoq5uyqMwrjCj/DCeWOd9sdP+jCYoUxj3Gjc9QRwdfr/2 lyJ8OomRzwCSKD8d1grnIzWHuFNSGNl3inT9rROqV0YjzZUuc6wOsiwn4P1SDZocXk6w 0ujqaf2KphF9+T8heEkfjh12h3tTegwlcOdYQIZxpOr4/27UpMYwPMqpp0M24ShhwN2O Um/c9Qnwux5RdvIRZIOzoVb/bcmzvRkMXc+iom48sqc84IoNnIdO1pG3veIBxIs7uoCN Ym16E8e9enkvmeyJ4/NC09w1XmyQzCAnwuQIpgEs6XFN6TUr7GqlyJEIxo1YvliRN0Ul jg== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3qwx8q8nbm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 May 2023 09:17:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MdSpmRQTjXjH9b4OIjqRoi7dl/Ai4qr0RGyb6EXSFC5bGa6VbR3xHu8fNT8vKsmtk9JZflyuqA+j1OEFfKyrMgOWfafPV4nlLoAAr9R+KsCSUtI0/9s1B9oNSitq6WWSCoEYS6MlyXsUYb/4FAaO0s4dymqT7QlHZXGg6f7ahRPznfiOeNUC48ZwofqwojX5Xl0mb1VwY/xwSd3LhxKzTD1Vq2oOhrkD+cuuAGyc+TO6EBPtgBUfojcrO9pS17cq/B1+wn6no+WRIvHA31X3OkG0WmW3UVeInVgYdZPpURascIVk+znGCqtktVjgXNyLSI+DnOMnp3qRf1ipr/XbsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Mwq2bZt09u9EYXQ0L+Bba5/vygis0PWgVT8Pyeys9EE=; b=QVCcBlX7BaM1AG1po7WWvdbt7bB+tfH9V/E2pAnYcBltV9KGG06c4kYYx+uuEvKpTEYHb4KadBYpmgrjtX75azrIkez6I5Fb+wCt5NatuHBR9wXhav23045iYfFceQbZjo8yjdICE422cd/yfeng6pXLTfdSJlZkk60UIZwmp8j/u7oo0nJifdnbq6jeY18qBh9j+w5L/UvmhOVmi763fnGflyGBytaoGMbG69YKhNUHObURYlmmOTk0KYIpHdJ3F2UgomIGilVYKjMCx6zxOFkpI51ju5+ft449ZVsovhJpsCETcqHD/07j6rJRvpdfSQfGGQCCgarlINuK0fgw5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from PH0PR02MB7256.namprd02.prod.outlook.com (2603:10b6:510:1a::23) by SA1PR02MB9699.namprd02.prod.outlook.com (2603:10b6:806:38b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6433.22; Wed, 31 May 2023 09:16:56 +0000 Received: from PH0PR02MB7256.namprd02.prod.outlook.com ([fe80::7e7b:2479:960f:bfda]) by PH0PR02MB7256.namprd02.prod.outlook.com ([fe80::7e7b:2479:960f:bfda%5]) with mapi id 15.20.6433.022; Wed, 31 May 2023 09:16:56 +0000 From: Jeremy O'Donoghue To: Wolf McNally , Laurence Lundblade CC: Carsten Bormann , Christopher Allen , "cbor@ietf.org" , "Shannon.Appelcline@gmail.com" Thread-Topic: [Cbor] Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D & IANA Tag Registration Thread-Index: AQHZgdRNPhkjcjZYvECmUMDuSpwNF69Q1YOAgAAjdICAAGcOAIAB4mY5gACLEoCAIGD3gIAACc5P Date: Wed, 31 May 2023 09:16:56 +0000 Message-ID: References: <4EBE3640-5F7F-46B8-961A-D1872A6A0CA4@tzi.org> <463016EF-0DAB-45D4-AB30-53FB2B76F52B@wolfmcnally.com> <62FCDF82-9766-431F-A996-BF820D5564C5@island-resort.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR02MB7256:EE_|SA1PR02MB9699:EE_ x-ms-office365-filtering-correlation-id: f9bdb293-cb91-4d86-6eb9-08db61b7c7bb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1yrPoTVSgxMEee0jihbSzVbjaSIZbn0WoWETZE5Ux2L1dGjyYCFTQ6Wmf1N9ZJEYCm9THHU47a1b7Ke/wBSmuqh4Kyn8771zjBldwFLaj9+L0oB/h+/CO4DDogsQxAv+NZ8YQaGeIUT3DoqM4li7JFFIq+wBzHO2t4kcuN9ynlTYXJEt1zUcs57eq2MkBWFiN83/OoXyxdeP5CoVG7tuqC3je+r6QMQJALT56AfeKl/3p1RuhlTGH1//DJjJPcUpm4MkDztn1DQQoPHjwXwGcomgsuqbGq2WBNseJqbruOhYrh5KmZcxbH9lh8Khq1sLae/Alw7pWNAgUFeIgxwvgukAT3hil5N2ni6TLsBReFigGOqIREgRWrhpDQuy+6PK/ji7sCJSbAPm4e4gFn80LpTQXmoPT1xviiu64Gu0v3o68UMKLJy91H5Iu7pRL98xLDzdvhOkXLhHHaxMJfPty1MnnpjBtqwPi6AxwPTYrUajf1HfOnuo0ca4Gvp1VjEsI7sKPw9vJgqCW4koTWZCfT5fCffCj1FDV+1E5lt6GwVFnmZagJM6280fEkQ8Z2ZYN9Zwvic2Kf/ThNvxo7Zo9etpT95M7r/PxTJ9On78pGs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR02MB7256.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(346002)(136003)(376002)(39860400002)(396003)(366004)(451199021)(186003)(26005)(33656002)(9686003)(7696005)(53546011)(6506007)(316002)(71200400001)(2906002)(55016003)(5660300002)(52536014)(41300700001)(8936002)(966005)(8676002)(478600001)(122000001)(38100700002)(166002)(54906003)(4326008)(110136005)(38070700005)(86362001)(64756008)(66446008)(66946007)(91956017)(66476007)(66556008)(76116006)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?A9xeN3P0Re/tvG8ubnYFjKgvsI3GWlEmxptSiwDy195pE7ZVFpA9Ut2p?= =?Windows-1252?Q?h30T7CZ5Df85Fxi1cKgEAgC5DzGdX7M/Qm9psq+LPIrNJQoGhGSwlIp3?= =?Windows-1252?Q?w8n9/VqByTghALaC3ZlJ2WxaE32Y4u1OPWt9W32yLPDu+6KymzI8Uq8a?= =?Windows-1252?Q?oXRPxdjiwfmZT6p18Q6wnKhXLrkANOu3uCMnIXoFMTM7cNNG0uagdCgt?= =?Windows-1252?Q?NXD9F5wi+shknBfr9LnbLEWQuXts9WVxX3EH0MBntUyfDrgcII5EEAGv?= =?Windows-1252?Q?qOVzoqJq1FkOGvjnakRV/qe63JfW89EA2XvrJ8dvYIxXWLrLBNyWxq3A?= =?Windows-1252?Q?48pFBpZqBNohcbYjPGIygy+GCv0A8dO2SHUhsM96XmdbOpD9liEMHopM?= =?Windows-1252?Q?5AjhneatSqm+3oMoUCavB6eJhGnx9UJxzVG9lrt6omXXL/fFzsdbnNfF?= =?Windows-1252?Q?5XAzG0F8mGM3cqLRSdbSvxCvwi8aj3HIADwRstAkDi4Rumwe/EVOdZdx?= =?Windows-1252?Q?xqPKbzCpWWQcfhQq0q94Nt6L+2DbpoYGTq1vfs87S00nxcN7z7F/T2Tf?= =?Windows-1252?Q?Q1NN7LK71VTI5yVvNdQqnrci7B0LfcUlAkBUBpDb7pblPZLJE6JyL3wG?= =?Windows-1252?Q?xxi5lTijwfirv8Cg7qVIDDy9R+1i0UAZCXAtT+rCNKbdm9HTnx57gwLW?= =?Windows-1252?Q?XeKwklABQbze2wVEm09LVd8b7WluhDhVlIJlrM5DkrUahJtDEdDd/poP?= =?Windows-1252?Q?MzuKpWbqTBb5E2BfkbzJUQCU6UVVvn2qirPGSzyHnLk898P8wIF5CdR6?= =?Windows-1252?Q?oE/1J10Xgv/FgIvoEVTp7PknsKWbu4ozJyB7uRUWFmyR4LrMvfjfBR5U?= =?Windows-1252?Q?JbMYKFkuzKW0eNq86FrgN99ka56w05yMpuX4RpRPW9Iht9PMPCq3d/3S?= =?Windows-1252?Q?peE5C7M33/a+kXZjZyq0mmcodqxR32rRJGsyUE+9m/mlc1x4fLxwg3wC?= =?Windows-1252?Q?zhoIxAUrkLOsQ4ERo1BRVT6pww2p36eU5TMIeIZPJ3Mx6bTxmQQ6Dy7a?= =?Windows-1252?Q?q7VIWCxkORYiZJ9ShCkc3E5ek4WdwfFZvq05uPD0ZaWNMqa3/+XspvSK?= =?Windows-1252?Q?DFdItwYLMpfZ0R6ebx0x9OP6F44lmyHauBFAW6eGczgZA2Zzje0rY5Hm?= =?Windows-1252?Q?4bim55XWZOXo3t9HuxQms0L8Pm311qwNSpvmuz+dXWrxEgmgNvGmaMfl?= =?Windows-1252?Q?IxWd1Le9zPzVT+Fsbq3miVjJIgfkxVs+xZvIs7wmAwWhM0xQCMvzKcbQ?= =?Windows-1252?Q?N/DjWmXvg1qZYWt3d0pgZoqDoUD+g8sDIOcXepPwJ8YB05Frxr92aj5e?= =?Windows-1252?Q?lpNQrADnRa21j9N8qKuvf7hS3r1neHJq6HkuuXOTOd/2VLTLGrABiXPo?= =?Windows-1252?Q?dLXTEQJiIkXb9d5XYDdK/XzibiIAPQWZldVJLc18o26MgAxlRJ3pMCSP?= =?Windows-1252?Q?cTGw/sWgdHGDCcWTuUo5YJBD2t5Aku39BHEX0CAL2AkblTsXvERiAzjh?= =?Windows-1252?Q?Rnt1ggHcGxc+3e7Im1T6F3co1RWofijXuPxKoYok5Aqn/3xGuVRpyQE+?= =?Windows-1252?Q?O57/X7EZMDZN0vnwSxEx9kBnP3m4Na44Q0srQ7pgIshZpaf2eX3CFIGU?= =?Windows-1252?Q?CkGs9UJbC9Cf6PaSDWK9/EoIuh3oe1uj9znyMkKPAwUQ+159y1GCp3xh?= =?Windows-1252?Q?doo0fac9765eamhIziI=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR02MB725610ABE5F43D31EDBF7686F2489PH0PR02MB7256namp_" MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?Windows-1252?Q?fi49sVBwvLClwnhURKeDRwL97cu066xx6wopoYLG2nY9IfSRrSsc6n8O?= =?Windows-1252?Q?1j+GbEmeqb4wKNILimo8M6Yd/FkIl27UNgx9LMyLx5C9rPL13k7+7NLH?= =?Windows-1252?Q?Vgb56irio0RGhelyONEHeJdST4tlUPxL+og1ZoDHOzxskvefc8qoB6sR?= =?Windows-1252?Q?o+ip0fdv9V85ZqQw3HemCKRbwAGpuhmTUeHm4uUnGaBFrW9r2TbtDKDr?= =?Windows-1252?Q?9zcNZPipR302114LBQ03ommkaMS9wTzSTU3wynzbv5VU06v4EOCcn4tc?= =?Windows-1252?Q?x2e7KMkPWgu/MEwPWmcePCCejfgAkS4cMmH89XDGVYy4npPr6Hm5CF+q?= =?Windows-1252?Q?4wBSvE/EaTCoZHBn6glfyUhHYiorrzoA2szGtJ464LtMmOLaj4hV9L6J?= =?Windows-1252?Q?ywDPpOknmdHTvVMDG4QxpyvFhQeY7/sQit8X8V0XQ8xB1S0/dnpK+o7w?= =?Windows-1252?Q?yA+CCdYyVSOn9VmdL+GgEQ9tgwiRJLQk70xid2+lRCIXMERXqLKLSpXH?= =?Windows-1252?Q?UVCOZnCBX24dEqyFriMc43UdpTU/cy8AyLY0yGXJYHV+c+JtySxY5TOn?= =?Windows-1252?Q?SrxHsXxVHiN+Tvhx5vAFLtCtFZPhRSjdqQidz1U2stbMubVLgpMz1WC9?= =?Windows-1252?Q?ONrzq/lK4oZvlkqf3So1Fy/Pgd7ot0wm/0aN8rVBreVHFti4Q6o/B1w8?= =?Windows-1252?Q?XB7sYgb7V/Ft0fFuxhK6KQRWtfVI8Wk3A/loNALZ3k/YdDncpL447Kdy?= =?Windows-1252?Q?QeTY9plGrB215zRZriZE0zRsQt+QJGvTo22GC+wPord8T/ik7ZlJsm1k?= =?Windows-1252?Q?+bBHyScOqaC3tqjo/T0ilv4b2EvQEll80PLPmanb39noAlFUocR1qCIa?= =?Windows-1252?Q?VGfi1RyH/eGnYsCatmEPuEYN3i2gdseVCfTa+GT5VbpsGoqJctmI4ksu?= =?Windows-1252?Q?tyaV1ze93sBXn/mDL0E+TcEUlKCtDX/gvfb9Y+MpZbOUZPBaBbPx9jjK?= =?Windows-1252?Q?SLpkFFsj1omRlM+/Fw8q2dP3y+vC0Q=3D=3D?= X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7256.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9bdb293-cb91-4d86-6eb9-08db61b7c7bb X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2023 09:16:56.0556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZVL7xRGrw3HzV/2kLOQtzt6vvqQZ8u3pWU7FjaA2/B+GVqBf1a46HysT3tDMu1QDAVBvQdiZgMhysxyMzhAQ6ytOYn6nS3zcr35AkxTAtpk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR02MB9699 X-Proofpoint-ORIG-GUID: aPvYztN_teWW8ICySmVQpfcCdVD_FaWg X-Proofpoint-GUID: aPvYztN_teWW8ICySmVQpfcCdVD_FaWg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-05-31_05,2023-05-30_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 malwarescore=0 clxscore=1015 spamscore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305310080 Archived-At: Subject: Re: [Cbor] Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D & IANA Tag Registration X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2023 09:17:19 -0000 --_000_PH0PR02MB725610ABE5F43D31EDBF7686F2489PH0PR02MB7256namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mostly agree. Important to understand that BigNum implies challenges that extend beyond t= he CBOR codec in most cases. For many implementation platforms, a non-core = library is required to make meaningful use of bignum values. For constraine= d implementations, this is something an implementer would likely wish to av= oid. Many bignum libraries are optimised for crypto use-cases rather than g= eneral purpose arithmetic, and can be fiddly to use. Carsten has mentioned that there may be good reason to wish to standardize = CBOR encodings of other low-precision numeric formats (see https://mailarch= ive.ietf.org/arch/msg/cbor/lFY2jvRQhBzog_EpUXsoor-x8FA/) which are useful f= or specific use-cases. I support this in principle =96 it extends the appli= cability of CBOR as a serialization format. This does mean that any attempt to standardize a deterministic encoding for= mat risks locking us into a particular view of the world that may prove imp= ossible to change in a backwards compatible manner. I agree with Wolf that smallest encoding should be a non-goal. In descendin= g order of priority, I believe the goals should be: * Representation of values without loss of precision. In many applicati= ons it is not reasonable to represent floating numbers with their truncated= integer equivalents. We already have good mechanisms for this which are im= plemented at least in QCBOR and my CBOR codec, and probably many others. * Prefer primitive value representations over non-primitive. This means= that tagged representations such as Bignum and Decimal Fractions are alway= s less preferred than major types. * Prefer smaller representations over larger. The idea of a canonical hierarchy of types is one that I support in princip= le, although it may be difficult to come to consensus once we support addit= ional lower-precision formats. I suspect that it may be impossible to defin= e dCBOR without a set of profiles (or =93configurations=94, or whatever we = choose to call them) which define required features for support =96 thus a = dCBOR codec without float support would necessarily encode floating point v= alues by truncating (or rounding?) to integer values. Best regards Jeremy On 31/05/2023, 09:22, "Wolf McNally" wrote: WARNING: This email originated from outside of Qualcomm. Please be wary of = any links or attachments, and do not enable macros. Christopher and I will be a today=92s meeting. The main concern I have over using the heuristic of =93shortest encoding wi= ns=94 is exactly the issue that, as has been pointed out by others, some Bi= gNum-encoded representations are in fact shorter than regular CBOR uint/nin= t representations. This means that to encode these values deterministically= , a dCBOR codec *must* support BigNum, and I don=92t want this to be a requ= irement. The proposal we have forwarded is =93least precise wins.=94 Since all fixed= -size types can be considered "less precise" than BigNum, BigNum is conside= red less-preferred, and will then only be used when all the less-precise ty= pes fail to represent a presented value. For applications that don=92t requ= ire values that require BigNum representation, the dCBOR codecs used don=92= t need to support it. The same principle also works on a smaller scale for floating point values:= A constrained dCBOR codec wouldn=92t even have to implement floating point= support if it doesn=92t need it, because the integer types are less precis= e than the floating point types. One could quibble about the exact meaning of =93precision=94 in this contex= t when, for instance, comparing the precision of a float type to an int typ= e, but our proposal comes down to establishing a canonical hierarchy of num= eric types (not encodings!) from most-to-least preferred, and finding the s= ingle most-preferred type that can represent a presented value without loss= of accuracy. So if it can be represented in one byte, it will be. If a cod= ec supports BigNum, and a value is presented to the codec API as a BigNum, = and can=92t be represented by any more preferred (less-precise) type, then = BigNum will be used for the encoding. The primary goal of dCBOR is determinism. Shortest-possible encoded form is= nice when possible, but a non-goal. ~ Wolf On May 10, 2023, at 10:55 AM, Laurence Lundblade wr= ote: On May 10, 2023, at 2:44 AM, Jeremy O'Donoghue > wrote: To give a very practical use-case, Rust has a native i128 type, for which t= he most =93natural=94 encoding of Carsten=92s example would be as a CBOR ne= gative integer. Haskell uses =93unlimited=94 length integers as (perhaps mo= re usefully) does Python. I would prefer to see DCBOR require encoding of integer types on the smalle= st/most natural CBOR type. Only when outside the range of the CBOR positive= and negative integer ranges should bigint be used. We don=92t have to cons= train everything else because of the limitations of the C and C++ builtin i= nteger types. Best regards Jeremy +1 for this. DCBOR implementations and applications are going to vary depending on wheth= er floating point is needed/available and on the precision of the float and= on the range of integers needed/available. It=92s not possible to expect e= very implementation to support every number possible, nor will every use ca= se need every value. It might be helpful (necessary to pre-define a few number number range prof= iles so a use case can pick from a menu and so there are example profiles. For example: =B7 Basic 64-bit integer profile: Integer values between MIN_INT64= to MAX_INT64 are allowed. All others error out. =B7 Basic float profile: All values that can be represented by an I= EEE 754 double are allowed. All others error out. Bignum support is not req= uired. =B7 Basic float profile with lignum: All values that can be represe= nted by an IEEE 754 double are allowed. All others error out. Bignum repres= entation are allowed. Implementations must round off big numbers that have = greater precision than can be represented by an IEEE 754 double. LL --_000_PH0PR02MB725610ABE5F43D31EDBF7686F2489PH0PR02MB7256namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Mostly ag= ree.

&nbs= p;

Important= to understand that BigNum implies challenges that extend beyond the CBOR c= odec in most cases. For many implementation platforms, a non-core library i= s required to make meaningful use of bignum values. For constrained implementations, this is something an imple= menter would likely wish to avoid. Many bignum libraries are optimised for = crypto use-cases rather than general purpose arithmetic, and can be fiddly = to use.

&nbs= p;

Carsten h= as mentioned that there may be good reason to wish to standardize CBOR enco= dings of other low-precision numeric formats (see https://mailarchive.ietf.org/arch/msg/cbor/lFY2jvRQhBzog_EpUXsoor-x8FA/= ) which are useful for specific use-cases. I support this in principle =96 = it extends the applicability of CBOR as a serialization format.<= /span>

&nbs= p;

This does= mean that any attempt to standardize a deterministic encoding format risks= locking us into a particular view of the world that may prove impossible t= o change in a backwards compatible manner.

&nbs= p;

I agree w= ith Wolf that smallest encoding should be a non-goal. In descending order o= f priority, I believe the goals should be:

&nbs= p;

  • Representation of values w= ithout loss of precision. In many applications it is not reasonable to repr= esent floating numbers with their truncated integer equivalents. We already have good mechanisms for this which are im= plemented at least in QCBOR and my CBOR codec, and probably many others.
  • Prefer= primitive value representations over non-primitive. This means that tagged= representations such as Bignum and Decimal Fractions are always less preferred than major types.
  • Prefer smaller representations over la= rger.

&nbs= p;

The idea = of a canonical hierarchy of types is one that I support in principle, altho= ugh it may be difficult to come to consensus once we support additional low= er-precision formats. I suspect that it may be impossible to define dCBOR without a set of profiles (or =93conf= igurations=94, or whatever we choose to call them) which define required fe= atures for support =96 thus a dCBOR codec without float support would neces= sarily encode floating point values by truncating (or rounding?) to integer values.

&nbs= p;

Best rega= rds

Jeremy

&nbs= p;

On 31/05/2023, 09:22, &= quot;Wolf McNally" <wolf@wolfmcnally.com> wrote:

 

= WARNING: This email originated from outside of Qualcomm. Please be wary of any link= s or attachments, and do not enable macros.

Christopher and I will = be a today=92s meeting.

 

The main concern I have= over using the heuristic of =93shortest encoding wins=94 is exactly the is= sue that, as has been pointed out by others, some BigNum-encoded representa= tions are in fact shorter than regular CBOR uint/nint representations. This means that to encode these values determin= istically, a dCBOR codec *must* support BigNum, and I don=92t want this to = be a requirement.

 

The proposal we have fo= rwarded is =93least precise wins.=94 Since all fixed-size types can be cons= idered "less precise" than BigNum, BigNum is considered less-pref= erred, and will then only be used when all the less-precise types fail to represent a presented value. For applications that don=92t r= equire values that require BigNum representation, the dCBOR codecs used don= =92t need to support it.

 

The same principle also= works on a smaller scale for floating point values: A constrained dCBOR co= dec wouldn=92t even have to implement floating point support if it doesn=92= t need it, because the integer types are less precise than the floating point types.

 

One could quibble about= the exact meaning of =93precision=94 in this context when, for instance, c= omparing the precision of a float type to an int type, but our proposal com= es down to establishing a canonical hierarchy of numeric types (not encodings!) from most-to-least preferred, and findin= g the single most-preferred type that can represent a presented value witho= ut loss of accuracy. So if it can be represented in one byte, it will be. I= f a codec supports BigNum, and a value is presented to the codec API as a BigNum, and can=92t be represente= d by any more preferred (less-precise) type, then BigNum will be used for t= he encoding.

 

The primary goal of dCB= OR is determinism. Shortest-possible encoded form is nice when possible, bu= t a non-goal.

 

~ Wolf



On May 10, 2023, at 10:= 55 AM, Laurence Lundblade <lgl@island-resort.com> wrote:

 

On May 10, 2023, at 2:4= 4 AM, Jeremy O'Donoghue <jo= donogh@qti.qualcomm.com> wrote:

 

To give a very practica= l use-case, Rust has a native i128 type, for which the most =93natural=94 e= ncoding of Carsten=92s example would be as a CBOR negative integer. Haskell= uses =93unlimited=94 length integers as (perhaps more usefully) does Python. 

 

I would prefer to see D= CBOR require encoding of integer types on the smallest/most natural CBOR ty= pe. Only when outside the range of the CBOR positive and negative integer r= anges should bigint be used. We don=92t have to constrain everything else because of the limitations of the C and = C++ builtin integer types.

 

Best regards=

Jeremy

 

+1 for this.=

 

DCBOR implementations a= nd applications are going to vary depending on whether floating point is ne= eded/available and on the precision of the float and on the range of intege= rs needed/available. It=92s not possible to expect every implementation to support every number possible, nor will = every use case need every value.

 

It might be helpful (ne= cessary to pre-define a few number number range profiles so a use case can = pick from a menu and so there are example profiles.

 

For example:=

=B7         Basic 64-bit integer profile: Integer values= between  MIN_INT64 to MAX_INT64 are allowed. All others error out.

=B7         Basic float profile: All values that can be = represented by an IEEE 754 double are allowed. All others error out. Bignum= support is not required.

=B7         Basic float profile with lignum: All values = that can be represented by an IEEE 754 double are allowed. All others error= out. Bignum representation are allowed. Implementations must round off big= numbers that have greater precision than can be represented by an IEEE 754 double.

LL

 

 

 

 

--_000_PH0PR02MB725610ABE5F43D31EDBF7686F2489PH0PR02MB7256namp_--