Change:
1.3. <del> Packet and frame diagrams in this document use the format described in Section 3.1 of RFC2360, with the following additional conventions: </del> <ins> Packet and frame diagrams in this document use a bespoke format.  The purpose of this format is to summarize, not define, protocol elements.  Prose defines the complete semantics and details of structures. </ins> <del> Indicates that x is optional </del> <ins> Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is separated by commas. </ins> <del> Indicates that x is A bits long </del> <ins> Individual fields include length information, plus indications about fixed value, optionality, or repetitions.  Individual fields use the following notational conventions, with all lengths in bits: </ins> <del> Indicates that x is one of A, B, or C bits long </del> <ins> Indicates that x is A bits long </ins> Indicates that x uses the variable-length encoding in <del> Indicates that x is variable-length </del> <ins> Indicates that x can be any length from A to B; A can be omitted to indicate a mimumum of zero bits and B can be omitted to indicate no set upper limit; values in this format always end on an octet boundary Indicates that x has a fixed value of C Indicates that x has a value in the range from C to D, inclusive Indicates that x is optional (and has length of E) Indicates that x is repeated zero or more times (and that each instance is length E) By convention, individual fields reference a complex field by using the name of the complex field. For example: </ins> 2.

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.