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

[Cullen Jennings <[e-mail]>]

It would be useful to standardize something like this - when writing protocol specification and code I have often wished for something like this. I don’t think it is the same as CBOR.  The sheer number of things like this in common use but without a proper specification speak to the need. Many of them were designed to be fast, while CBOR was largely designed to be small. 

I think there are a bunch of ways this could be improved to help with things like:
* schema syntax for future extensions points, 
* some pre defined thing for common data such as time 
but all of that could be done if we decided to move this forward. 


> On Jun 9, 2022, at 3:19 PM, Tim Bray <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Thu, Jun 9, 2022 at 1:14 PM Jiri Vlasak <[e-mail] <mailto:[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 <https://www.rfc-editor.org/rfc/rfc8949.html>
> [2]: https://www.ietf.org/archive/id/draft-devault-bare-07.html <https://www.ietf.org/archive/id/draft-devault-bare-07.html>
> _______________________________________________
> dispatch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch