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

[Jiri Vlasak <[e-mail]>]

I am sorry for longer delay.

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

I think I understand the benefits of canonicity. Also, I think BARE can
not be fully canonical. However, decent solutions exist, as mentioned
above.

I would like to compare the problem of floating point numbers to
strings. In these situations, BARE depends on IEEE 754 and UTF-8
respectivelly. I believe it is not in the scope of BARE to circumvent
used specifications.

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

There are two options for canonicalized BARE, in my opinion:
1. Use BARE schema that does not use f32, f64, str, or map.
2. Use canonical implementations of IEEE 754 and UTF-8.

When implementing BARE, it is possible to write IEEE 754 encoder/decoder
from scratch, but also it is possible to use existing library. The same
apply to strings.

Please note, that BARE is canonical when possible.