Re: [Cbor] NaN behavior for CDE

Joe Hildebrand <hildjj@cursive.net> Tue, 09 January 2024 19:14 UTC

Return-Path: <hildjj@cursive.net>
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 47151C14F6FB for <cbor@ietfa.amsl.com>; Tue, 9 Jan 2024 11:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=cursive.net
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 9rIPa9IvRCEg for <cbor@ietfa.amsl.com>; Tue, 9 Jan 2024 11:14:14 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 D4D46C14F5FF for <cbor@ietf.org>; Tue, 9 Jan 2024 11:14:14 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-7beddc139c4so34261839f.0 for <cbor@ietf.org>; Tue, 09 Jan 2024 11:14:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; t=1704827653; x=1705432453; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+p9FHOPB4ams2cG5L8I24tjgoxsT3kFkm2r1EOzyk0U=; b=C2RtDpAIz+dT4AFFvmrQy4aFl7FXswYNZ7qWkxMpYo3lWAhgeO4Q57gdMKJolT8GDD akiG4fpOCtLHa8dgX07fekw8WAzysWonp3XhiHZFeGYlebqVIWSn6MslqwZr0i7He4Im 1hVOWl1YQ8a+5MWZ2rK2zSf1XjYGfY3Kh45W4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704827653; x=1705432453; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+p9FHOPB4ams2cG5L8I24tjgoxsT3kFkm2r1EOzyk0U=; b=Sx4TMllqhN3sGtfZM0iQcNX0IaCs0p0MURQtK4O5SUDrCSOX2mFSFi0ud44TBEqezw qE8kEJPTt3aKMntr0hqDc8l0+qlmpzHUhUYz7A1Z2bOIoYFHaFv809RStV3rmpL9aTmY WM/sVtq6vm5qQnwMV7NC9lwT3TQ8CfCtJqKoOAw6wccSj1YHgZQDSZtl8/W5PMpbh1bY HDG3A/5fR1yXTtAX8w45ZUuJDxRBf8fYizanY9+G+qzRC3+LotXYqSl3fyNg/mR0da8s DiQOWe8bWrvSLmzSjqV41Fvtfj5MltzucILsoRoSOyVAtZ4ps5n8ubAaf8pBl9gAWzp5 VvGA==
X-Gm-Message-State: AOJu0YwMH+LE18FzgbF3y4JGMr0S+wyLNJgpseAO0mC7KWQlZVile102 GI8bzc9QUhD4kwRJuvhDw9JdnYfHtRKl
X-Google-Smtp-Source: AGHT+IErgQxS/JYJrgvSfc1DAKjlqLBZNFchLYDPc5ugtOFpIehZKRXRnsQRG2a23F65bfngNs3Ojw==
X-Received: by 2002:a5e:8f42:0:b0:7be:ef47:e75a with SMTP id x2-20020a5e8f42000000b007beef47e75amr448210iop.25.1704827653637; Tue, 09 Jan 2024 11:14:13 -0800 (PST)
Received: from smtpclient.apple ([2601:282:2100:4fc9:55d4:a7e1:9792:46f8]) by smtp.gmail.com with ESMTPSA id l20-20020a5e8814000000b007bc3f75039dsm444872ioj.29.2024.01.09.11.14.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2024 11:14:13 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Joe Hildebrand <hildjj@cursive.net>
In-Reply-To: <FC9DABEF-030D-4AE1-82A5-E0306CCF6B49@island-resort.com>
Date: Tue, 09 Jan 2024 12:14:02 -0700
Cc: Carsten Bormann <cabo@tzi.org>, "cbor@ietf.org" <cbor@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B2DADFC9-F696-413D-B3F5-9B1A32F41AED@cursive.net>
References: <B3993FCB-3878-47EE-A9D7-21F34530BE51@island-resort.com> <6B10BDA4-994A-4614-966E-487E0B6F46D3@tzi.org> <AEB51081-00F9-40CC-9043-29EB4A083CFC@island-resort.com> <D5F97344-DFD1-4298-B409-87504E654F0C@tzi.org> <A6EBE8A8-2A46-4061-AAD5-177DBC301AA2@island-resort.com> <CC160EDF-E9A4-4798-87E3-24219A20C8D8@cursive.net> <FC9DABEF-030D-4AE1-82A5-E0306CCF6B49@island-resort.com>
To: "lgl island-resort.com" <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/YhD8eJ9zZNqRpA354Z275N3IMgk>
Subject: Re: [Cbor] NaN behavior for CDE
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: Tue, 09 Jan 2024 19:14:19 -0000

Perhaps both of the first two?

— 
Joe Hildebrand

> On Jan 9, 2024, at 12:12 PM, lgl island-resort.com <lgl@island-resort.com> wrote:
> 
> The question is how and where to express this best current practice.
> 
> - Built into the CDE definition (I’m suggesting that)
> - As extra text in the CDE definition (Carsten is kind of going for that)
> - Other document (yuck — too many documents)
> - Rely on library documentation
> 
> A big part of my motivation is that I think CBOR serialization variation is already messy and confusing for most reader and users of CBOR. It is one of the messiest and least understood parts of CBOR (IMO). I’m hoping that the CDE document is sharp and clarifying.
> 
> LL
> 
> 
>> On Jan 9, 2024, at 12:00 PM, Joe Hildebrand <hildjj@cursive.net> wrote:
>> 
>> Agree with this. I'd go as far as to say that it might be a best current practice that protocols intended for wide interoperability SHOULD NOT rely on sending or receiving NaN payloads (including quiet bits) in CBOR or any other encoding. 
>> 
>> — 
>> Joe Hildebrand
>> 
>>> On Jan 9, 2024, at 11:39 AM, lgl island-resort.com <lgl@island-resort.com> wrote:
>>> 
>>> I understand what you are proposing now. It is the same as Attempt-to-Preserve-Payload in my TL message that you probably DR  because it was TL :-) 
>>> 
>>> I still think some of the points I make apply:
>>> - No support for NaN payloads in CDDL or in other text or literal representations of float
>>> - Cbor.me does preferred serialization, but not NaN payloads
>>> - CBOR Sample code for conversion to half-precision doesn’t support NaN payloads
>>> - No C/C++ APIs to support encoding/decoding of NaN payloads
>>> - No compelling use cases
>>> 
>>> LL
>>> 
>>> 
>>> 
>>>> On Jan 8, 2024, at 1:20 PM, Carsten Bormann <cabo@tzi.org> wrote:
>>>> 
>>>> On 2024-01-02, at 23:27, lgl island-resort.com <lgl@island-resort.com> wrote:
>>>>> 
>>>>> I think what you are saying here is that CDE does not make a choice about NaN payloads. It is left up to the protocol / profile.
>>>> 
>>>> That is not what I was trying to say.
>>>> 
>>>> I was trying to point out that, since CBOR supports NaN payloads, CDE needs to support them, too.
>>>> 
>>>>> Thus, a particularly thorough generic CBOR encoder supporting CDE probably has a configuration setting that allows the user to pick NaN payload behavior.
>>>> 
>>>> I hope not.
>>>> 
>>>> I submitted a -01 that should clarify this:
>>>> 
>>>> Status:   https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/
>>>> HTML:     https://www.ietf.org/archive/id/draft-ietf-cbor-cde-01.html
>>>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-cbor-cde-01
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>>> 
>>>>> LL
>>>>> 
>>>>> 
>>>>>> On Jan 2, 2024, at 2:14 PM, Carsten Bormann <cabo@tzi.org> wrote:
>>>>>> 
>>>>>> I wish everyone a great new year.
>>>>>> 
>>>>>> On Jan 2, 2024, at 23:06, lgl island-resort.com <lgl@island-resort.com> wrote:
>>>>>>> 
>>>>>>> The TLDR for this is that I think CDE should not support NaN payloads.
>>>>>> 
>>>>>> Since CBOR supports NaN payloads, CDE needs to define how to deterministically represent them.
>>>>>> 
>>>>>>> CDE NaN should always be 0xf97e00 the same as dCBOR.
>>>>>> 
>>>>>> That is a perfectly fine application profile.
>>>>>> I think the consensus on this list appears to be that we put very little blame on "generic encoders" that do not support NaN payloads, i.e., aren’t really fully generic in the fullest sense.
>>>>>> We probably need better nomenclature for “not quite fully generic” encoders in this sense.
>>>>>> 
>>>>>>> Also, it appears to me that Preferred Serialization (RFC 8949 section 4.1)  requires NaN payload support. Looking for confirmation on that.
>>>>>> 
>>>>>> Preferred Serialization tells you the preferred serialization *if* CBOR provides a choice between multiple encodings with the same semantics.
>>>>>> If your implementation doesn’t provide support at all for something in the CBOR generic data model, preferred serialization doesn’t place any constraints on you.
>>>>>> If you convert all NaNs to quiet NaNs with zero payloads before encoding them in CBOR, preferred serialization will make you emit f97e00 for all of them.
>>>>>> 
>>>>>> Grüße, Carsten
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
>> 
>