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

[Jiri Vlasak <[e-mail]>]

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

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

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

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