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

[Jiri Vlasak <[e-mail]>]

On Thu, Sep 28, 2023 at 02:54:33PM -0400, Dale R. Worley wrote:
> I'm late to this party, but two things strike me immediately:
>
> Eric Rescorla <[e-mail]> writes:
> > 1. The convention in IETF is to have things in "network" (big-endian) order.
>
> Yes; we've settled on consistently using big-endian order.  Is there a
> reason for the IETF to bless an encoding scheme that is little-endian?

BARE use-cases section includes "A structured data format for storing
data in persistent storage" [1] (along more examples that invove network
communication). The little endian is chosen because it is widely used in
processor architectures.

Is that a sufficient reason? If there is no chance that a protocol based
on the little endian would be published in Standards Track, please, let
me know.

> Section 1 starts, "The purpose of the BARE message encoding, like
> hundreds of others, is to encode application messages."  This is very
> true.  But the I-D doesn't address why this encoding is decidedly better
> than existing alternatives.  Presumably there's a case to be made for
> it, but the case isn't made in the I-D.

In general, it is better because of the BARE's goals:

- Concise messages
- A well-defined message schema
- Broad compatibility with programming environments
- Simplicity of implementation

and how these goals are met.

I did some comparison with similar encodings in the presentation for
IETF 114 [2]. My summary is that BARE:

- has extensive support for primitive and aggregated data types,
- these data types area clearly distinguished,
- BARE is well defined,
- BARE is simple.


[1]: https://www.ietf.org/archive/id/draft-devault-bare-09.html#name-use-cases
[2]: https://datatracker.ietf.org/meeting/114/materials/slides-114-dispatch-binary-application-record-encoding-bare-00