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

Hi Jiri,

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].  They seem to
have the same underlying design principles, in particular in terms of the
receiver having to know the schema for the data before decoding it.  The
one thing that it seems like TLS accounts for and BARE does not is
canonicalization -- the TLS syntax is used for things like signing, where
it's important for the same struct to always encode to the same thing.
BARE is close, but there are a few things that would need to be nailed
down, like the order of map keys.

Functionally, BARE is a superset of the TLS language, with the main
additions being:

- map<A, B>
- variable-length integers
- signed integers
- floating point numbers
- bool

This is a pretty small gap to close.  MLS has already extended the TLS
syntax with optional<T> and variable-length list headers, using the
variable-length integers from QUIC [3], so it's close on variable-length
integers.  Obviously, the rest of the primitives are just a question of
byte size and interpretation.  The only non-trivial thing here would be the
map encoding, for which the BARE approach seems fine (it's one I have used
as a hack in some TLS-syntax-based things).  The only change I would make
is to require that the map be sorted by key, as noted above.

Given the above, and given that the TLS syntax has started to be used
outside of TLS, it seems like it could be worthwhile to have an effort to
mature the TLS syntax from something done specific to TLS to something that
can meet the needs of both TLS and a broader class of protocols.  With the
idea of making something we could use for BARE use cases as well as TLS 1.4
and MLS 2.0.  The fact that there are already literally billions of TLS
syntax implementations out there seems like another advantage to using it
as a starting point.

As far as the DISPATCH question -- maybe a small, focused working group?

--Richard

[1] https://datatracker.ietf.org/doc/html/rfc8446#section-3
[2]
https://www.ietf.org/archive/id/draft-ietf-mls-protocol-16.html#name-presentation-language
[3] https://www.rfc-editor.org/rfc/rfc9000#name-variable-length-integer-enc

On Wed, Jun 8, 2022 at 10:37 AM Jiri Vlasak <jiri.hubacek@gmail.com> wrote:

> Dear members of DISPATCH WG,
>
> I would like to ask you to consider discussing Binary Application Record
> Encoding (BARE) I-D [1] during the upcoming DISPATCH meeting at IETF
> 114.
>
> The BARE has been discussed in the technical community, including
> implementers of BARE [2][3]. I have sent the request for feedback to
> art@ietf.org [4]. I have also reached out to the Independent Submission
> Editor, who has been very helpful in recommending appropriate next
> steps.
>
> I am new to the IETF standardization process and do not know how the
> process works in detail. I cannot attend the DISPATCH meeting in person,
> but I can participate remotely if needed.
>
> Thank you, have a nice day,
> Jiri
>
> [1]: https://www.ietf.org/archive/id/draft-devault-bare-07.html
> [2]: https://lists.sr.ht/~sircmpwn/public-inbox?search=bare
> [3]: https://git.sr.ht/~qeef/draft-devault-bare/
> [4]:
> https://mailarchive.ietf.org/arch/msg/art/p6s0Q3KPaVkBj7Y9xkNSF5XJQcs/
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>