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

[Martin Thomson <[e-mail]>]

On Tue, Jul 26, 2022, at 12:34, Richard Barnes wrote:
> 2. QUIC has its own different syntax. 
> https://www.rfc-editor.org/rfc/rfc9000.html#name-notational-conventions

I want to caution against using this as the basis for a formal grammar.  It was never intended as such.  These are pictures, not specifications.

If you want something that you can feed into a parser/generator, ASN.1 and PER (probably the unaligned variant, which is the less weird of the two) is superior in many respects.  CBOR is similarly good (I don't like CBOR for reasons, but it has a lot of tooling support now).  Protobuf is even better.  And there are many others with similarly good tooling and support.  The TLS format is often used, but I am of the opinion that it is not ideal in many cases and bad in some others; see cTLS.

But the idea that there might be a generic set of tools ignores the fact that there is a continuous desire to find something "optimal" for different use cases.  None of the design choices in the above are perfect because adaptation to a specific use case is a constant consideration.

That you might invent a format that will rule them all is ... for want of a nicer word ... hubris.  You might as well expect everyone to decide that vi or emacs is superior to the point that the other can be archived and never used ever again.  See also why git is the only possible answer for VCS.

There is perhaps a use case for a format system for protocols that undergo symbolic analysis.  Even there, the encoding is rarely the subject of the analysis.  Encodings are so trivial that they are rarely considered.  That is, some tools did look at this for QUIC and TLS, but most operated on an abstract model of the protocol; it is a gap, but not a particularly bad one given how easy it is to create unambiguous encodings.

What role the IETF might play in all this mess is unclear.  As much as any major player, we're responsible for adding to the pile of different options, even as we manage to consolidate here and there.

Perhaps the IETF's role as a bespoke protocol crafting shop means we'll always turn out new methods of describing the way to arrange bits on a wire.  I'm personally OK with that.