Re: [dispatch] draft-devault-bare-07 to be discussed during IETF 114

[Anders Rundgren <[e-mail]>]

On 2022-07-28 10:51, Jiri Vlasak wrote:
>>> Please, note that BARE can not achieve full canonicity -- we need full
>>> compliance to IEEE 754 (e.g. NaN values from sensors or infinity in
>>> mathematical computations).
>>
>> You mean that using variant NaNs for "signaling" is a target for BARE?
>> This concept is probably not overly useful since it is not supported
>> by many platforms.
> 
> BARE target is full compliance to IEEE 754. The design decision is based
> on the feedback [1].

I understand but I am less convinced that NaN + payload actually is used since its support by programming platforms seems pretty scarce to say the least.


> 
>>>> For IEEE floating point data, I would consider adapting the CBOR
>>>> encoding scheme so the re-serialization becomes fully compatible.
>>>
>>> I am sorry but I do not understand. Both, BARE and CBOR use IEEE 754
>>> binary formats.
>>
>> Yes, but to maintain a consistent format there should be exactly one
>> representation of every number, including NaN.
> 
> That is not so easy, as discussed in [1]. For BARE, compliance to IEEE
> 754 is more important than compliance to CBOR.

I'm sure the IEEE 754 folks felt they had to do something with all those "wasted bits" :)  Although (potentially) a good idea, it didn't get traction in JavaScript, Java, C#, etc.


> 
>> Anyway, if canonical representation is of no interest
> 
> It is. There are three problematic types with decent trade-off:
> - f32, f64: there are good reasons for full compliance to IEEE 754
> - str: encoded as utf-8 that does not have to be canonical
> - map<A><B>: using explicit alternative (list of pairs) is preferred
> 
> When broadly compatible canonical representation is needed, the simplest
> solution is to avoid the types above.
> 
>> you can safely ignore my comments :)
> 
> Not possible on my side, sorry. Your feedback is greatly appreciated. Do
> you have some use-case in mind, when canonical f32, f64 are needed?

If you take JOSE/COSE as an example they require putting the encoded data "as is" in a fixed representation (b64u/blob) in order to use the data in cryptographic contexts.  Canonicalization eliminates this step.

However, canonicalized BARE may just be an option, not a general requirement.  In the former case NaN would have to be unique not only for serialization reasons but for compatibility with existing programming platforms.

Regards,
Anders

> 
> Thanks,
> jiri
> 
> [1]: https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAFFTG-a-Vci%2BkS_d_%3DuaX8kyxszqtB-79pcb5580Z9xw72V5kw%40mail.gmail.com%3E