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

The world is well-supplied with schema-driven binary encoding schemes, all
claiming excellent compatibility and performance characteristics: Avro,
Protobufs, Cap'n proto, Thrift, FlatBuffers are the ones I can think of off
the top of my head.

I'd be interested in hearing why BARE is different/better/interesting.

On Thu, Jun 9, 2022 at 2:14 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Thu, Jun 9, 2022 at 1:14 PM Jiri Vlasak <jiri.hubacek@gmail.com> wrote:
>
>> > > > An obvious question is why one would use BARE rather than CBOR
>> > > > which appears at first glance to do the largely the same thing.
>> > > > See RFCs 8949, 8152, 8392, 8610, 8742, 8746, and 8812.
>> > >
>> > > An obvious answer is that because BARE spec [1] is short. It has
>> > > about 17 pages (depends on the format), that include schema language
>> > > and many examples.
>> > >
>> >
>> > Without taking a position on BARE, this is not necessarily a virtue.
>> > There are (at least) two reasons why a draft might be shorter than
>> > alternative technologies (1) that it is simpler (2) that is
>> > underspecified.
>>
>> (1) is one of the BARE's goals. We worked hard to avoid (2) and I am
>> happy to discuss it.
>>
>
> Since sending this email I have taken a quick look at the specification,
> and IMO the description of the schema language needs to be fleshed
> out some. Providing the ABNF is insufficient, you need to explain
> what each piece of the syntax means. You might be able to
> save some space by interlacing that with the description of each
> type.
>
>
>
>> > > Moreover, BARE needs the schema available prior to the
>> > > communication, which is not needed in CBOR [2] as stated in the
>> > > objectives. In this manner, BARE better compares to XDR [3].
>> > >
>> >
>> > As I understand it, CBOR does however support schema, no? If so, I'm
>> > not sure why requiring it is an advantage. Is the idea that it makes
>> > the format more compact? Something else?
>>
>> To my understanding, yes, CBOR supports schema. However, to cite from
>> the CBOR specification [1], "3. Data must be able to be decoded without
>> a schema description." That is not the case for BARE. So, to cite from
>> the BARE specification [2], "A BARE message has a comparable size and
>> entropy to the underlying state it represents."
>>
>> I am not saying that requiring the schema is an advantage, which lead us
>> to the original question -- you probably use BARE when you need simple
>> schema and concise messages; you probably use CBOR when you need
>> self-descriptive messages.
>>
>
> It would probably help to provide some measurements that compared
> the overhead of CBOR to the overhead of BARE. As a bonus, it
> would help to compare the overhead of compressed CBOR to the
> overhead of compressed BARE.
>
>
>
>
>> > Finally, I note that your name does not appear in the author list of
>> > this document.  Can you clarify the situation here?
>>
>> Of course, and I am sorry I did not do it earlier. After the -01 version
>> of the BARE draft the development stagnated. The original author was out
>> of free time, letting the BARE I-D to expire. After some time, the
>> requests to revive the specification appeared from the interested
>> developers. I worked with one of the developers/implementers to review
>> the BARE and incorporated all the received feedback.
>>
>> My primary motivation is to understand the RFC process on the
>> specification, which I believe is worth the standardization.
>>
>> I was hesitating to add myself and the imlementor mentioned earlier as
>> the authors, because our roles are more like pre-editor and contributor
>> ones. So I decided not to, but it is maybe wrong? Could I, please, ask,
>> what is the common practice in the similar situations?
>>
>
> I'm not sure about wrong, but it's just surprising to see someone proposing
> a specification without their name on it. It would probably be better to
> add
> your name so that people know who to contact, etc., but I don't think
> you need to submit a -08 just for that.
>
> -Ekr
>
>
>>
>> Thanks, have a nice day,
>> jiri
>>
>> [1]: https://www.rfc-editor.org/rfc/rfc8949.html
>> [2]: https://www.ietf.org/archive/id/draft-devault-bare-07.html
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>