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

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>>
>>
>> On Mon, Jul 25, 2022 at 9:00 AM Richard Barnes <[e-mail]> wrote:
>>
>>> On Wed, Jun 8, 2022 at 5:06 PM John Levine <[e-mail]> wrote:
>>>
>>>> It appears that Jiri Vlasak  <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>