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

[Victorien Elvinger <[e-mail]>]

Hello !

I am a contributor to the BARE draft.

 > It seems worth observing here that BARE has a lot of overlap with
 > the "TLS syntax", the presentation syntax used in TLS and MLS

Yes. However there is a significative incompatibility: endianness.
BARE message are little-endian encoded.
TLS messages are big-endian encoded.


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

We should make a survey to convince us about that.

Moreover, many ordered maps are maps that respect the order of
insertion of the key-value pairs. Thus keys are not ordered...

So we should decide what we mean by ordered maps:
maps that order their keys or maps that account for the insertion-order?

I think you consider the former?
Because you want the same encoding regardless the insertion order?


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

If we are going to require an order between keys, then I might prefer to
require a lexicographic order on their binary representation.


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

Keys have to be ordered first before encoding the map, right?
Unless the programming language support maps with ordered keys.


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

Indeed, the support of NaN payload propagation is really messy.
However, most of processors propagate the payload [1].
Although it can be turned off on ARM processors and this must be turned
on for RISC-V processors.

The 2019 update of IEEE 754 standard adds a function to access
the NaN payload and another one to set the NaN payload.
However, the behavior of these functions may depend on the considered
platform [2].

This is difficult to determinate whether NaN payload propagation is
actually used or not.
I have already taken the time to look for data on this subject.
However, I have not been able to find any useful data...

If we normalize NaN into a single representation,
we could also wonder whether -0 should be normalized to +0?

That's why we decided to avoid dealing with this mess.

Even if we have canonical floats and canonical maps,
there is still a big issue with UTF-8 (grapheme cluster vs code points, 
...).
And no one agrees on what is a true canonial Unicode string is...

[1] 
https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf
[2] 
https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/payload-functions.txt

-- 
Victorien Elvinger
PhD and R&D Engineer, Inria Grand Est

PGP https://pgp.mit.edu/pks/lookup?search=victorien+elvinger