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

[Ben Schwartz <[e-mail]>]

Adding bitfield support seems reasonable.  As noted in RFC 4506, we're not
the first people to have this discussion:

   The XDR standard lacks representations for bit fields and bitmaps,
   since the standard is based on bytes.  ...

   One could imagine extensions to XDR that would let it describe almost
   any existing protocol, such as TCP.  The minimum necessary for this
   is support for different block sizes and byte-orders.  The XDR
   discussed here could then be considered the 4-byte big-endian member
   of a larger XDR family.

I think there's something to be said for a backward-looking approach to
start.  This would provide the unique advantage of being able to represent
some important IETF wire formats.  Otherwise, the value proposition over
FlatBuffers, XDR, etc. is not clear to me.

On Tue, Jul 26, 2022 at 12:35 PM Richard Barnes <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[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
>>>
>>