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

I am afraid I do not understand exactly what you mean by "what each
piece of the syntax means". Could you, please, provide some example?

ABNF is provided merely to describe the syntax of the BARE Schema
Language, which is not needed for encoding or decoding.

<user-types> corresponds to Section 2.3 User-Defined Types, and
<any-type> corresponds to Sections 2.1 Primitive Types and 2.2 Aggregate
Types of the specification. So maybe this has to be stated explicitly?

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

Here is the script:

https://git.sr.ht/~qeef/draft-devault-bare/tree/master/item/compare-bare-to-cbor.py

I would appreciate if someone can check the script and provide a
feedback. I am going to fix the issues found.

The results for the list of 1,000 messages, where each message (inspired
by the Appendix B. Example Company of the BARE I-D) contains "someone"
with "name", "email", "address" (list of four strings), and "orders"
(list of 10 to 100 orders, where an order has i64 "orderId" and i32
"quantity"), are:

	For 1,000 messages:
	- Raw length, i.e. 100 % [Bytes]: 747933
	- BARE length [%]: 100.94
	- CBOR length [%]: 200.43
	- JSON length [%]: 325.60
	- BARE gzipped [%]: 26.57
	- CBOR gzipped [%]: 29.28
	- JSON gzipped [%]: 32.29