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

This is sort of what I was thinking, though more forward-looking than
backward.  Though note that:

1. TLS syntax (and BARE) operate on byte boundaries, so things that deal
bitwise (like IP or TCP headers) are not that natural
2. QUIC has its own different syntax.
https://www.rfc-editor.org/rfc/rfc9000.html#name-notational-conventions

On Tue, Jul 26, 2022 at 11:09 AM Ben Schwartz <bemasc@google.com> wrote:

> I wonder if the IETF itself could be the customer.  Could we develop a
> structure syntax that is capable of representing, say, 70% of IETF wire
> formats?
>
> If we could convert the TLS/QUIC/MLS presentation language into an actual
> parser-generator that is capable of representing TLS 1.3 and QUICv1, I
> think that would be fairly compelling.  If it can also represent IPv6, TCP,
> HTTP/2, and/or HTTP/3, that might lower the cost of writing new
> implementations, avoid some security bugs, and perhaps even transform the
> way we write new protocols.
>
> On Mon, Jul 25, 2022 at 9:15 AM Eric Rescorla <ekr@rtfm.com> wrote:
>
>> My sense is that the competitors for this work are, e.g., protocol
>> buffers, thrift etc.
>>
>> With that said, I don't think the most important question is technical
>> details but rather customer demand, What I mean by this is that there are
>> quite a few pieces of technology in this space, and so we should only take
>> this on if there is real evidence of some constituency which will adopt the
>> output of this work (if it happens). Presumably, we can make whatever
>> technical design choices will result in a good system, but there's no point
>> in doing that if people don't want to use it.
>>
>> -Ekr
>>
>>
>> On Mon, Jul 25, 2022 at 6:09 AM Richard Barnes <rlb@ipv.sx> wrote:
>>
>>>
>>>
>>> On Mon, Jul 25, 2022 at 9:00 AM Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>>> On Wed, Jun 8, 2022 at 5:06 PM John Levine <johnl@taugh.com> wrote:
>>>>
>>>>> It appears that Jiri Vlasak  <jiri.hubacek@gmail.com> said:
>>>>> >Dear members of DISPATCH WG,
>>>>> >
>>>>> >I would like to ask you to consider discussing Binary Application
>>>>> Record
>>>>> >Encoding (BARE) I-D [1] during the upcoming DISPATCH meeting at IETF
>>>>> >114.
>>>>>
>>>>> 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.  If you can join the
>>>>> session remotely, I expect we can have a useful discussion about this
>>>>> and related topics.
>>>>>
>>>>
>>>> Probably for similar reasons that TLS and MLS do not use CBOR.  CBOR is
>>>> much more complex than is called for in a lot of use cases (arguments about
>>>> spec size aside), in particular because it enables decodability without a
>>>> schema.
>>>>
>>>> I do not view CBOR as a plausible competitor for this work.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>>>
>>>>> R's,
>>>>> John
>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> dispatch@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>