Re: [Cbor] NaN behavior for CDE

["lgl island-resort.com" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>> 
>>> On 2024-01-02, at 23:27, lgl island-resort.com <[e-mail]> 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 <[e-mail]> wrote:
>>>>> 
>>>>> I wish everyone a great new year.
>>>>> 
>>>>> On Jan 2, 2024, at 23:06, lgl island-resort.com <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
>