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

[Anders Rundgren <[e-mail]>]

On 2022-07-28 9:40, Jiri Vlasak wrote:
> Please, note that I re-added the [e-mail] to CC.

OK :)


>> As an author of https://www.rfc-editor.org/rfc/rfc8785.html I would
>> REQUIRE keys to be sorted.  The cost isn't for real.
> 
> With all the respect, it is not good idea in my opinion. These are the
> reasons:
> 
> - there is no wide support for ordered maps in programming environments

I don't have full insight in this but in programming environments that actually support a map concept, ordered maps are likely to be found.


> - there are situations when ordering is not important

Right, what I'm saying is that the cost for ordering (on the sender side) is very small regardless of programming language.


> - we would need to decide how to order

Right.  Given the fact that all BARE keys must be of the same type makes this a simple task.


> - there is alternative, explicit solution (list of pairs) with no
>    difference in overhead

That should work as well.


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


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

Anyway, if canonical representation is of no interest, you can safely ignore my comments :)


Cheers,
Anders