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

[Jiri Vlasak <[e-mail]>]

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

Thank you, I will do my research on TLS and MLS in the following weeks
to understand the overlap.

> The one thing that it seems like TLS accounts for and BARE does not is
> canonicalization

We discussed this during the draft update process. Unfortunately,
complete canonicalization is not possible at least because of the
support for the floating point numbers. From the "Appendix D. Design
Decisions" of the BARE I-D:

> f32 and f64 are fully compliant with IEEE 754 [IEEE.754.1985]
> 
> 	The use-case is a sensor sending NaN values or encoding of
> 	infinity in scientific applications.
> 
> 	The consequences are that encoded values of f32 and f64 types
> 	are not canonical, and therefore forbidden as map keys.

However, it is possible to use such a scheme that is fully canonical.

> BARE is close, but there are a few things that would need to be nailed
> down, like the order of map keys.

This is another deliberate decision. From the "Appendix D. Design
Decisions" of the BARE I-D:

> There is no ordered map type
> 
> 	Ordered maps are not widely supported in programming
> 	environments. Users that want to use ordered maps can use a list
> 	of pairs:
> 
> 	list<struct {
> 		key: KeyType
> 		val: ValType
> 	}>