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

[Eric Rescorla <[e-mail]>]

On Thu, Jun 9, 2022 at 1:14 PM Jiri Vlasak <[e-mail]> 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
>