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

[Jiri Vlasak <[e-mail]>]

> > 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].

> > > 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.

> 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?

Thanks,
jiri

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