Stretching the RSWG scope a bit... see below:
On 07-May-25 10:28, Martin Thomson wrote:
On Wed, May 7, 2025, at 00:09, Michael Richardson wrote:
I think that the packet diagrams *are* normative as to the structure of the
packet structure. But that we should never put BCP14 language in the diagram.
I think that many people think of packet diagrams as normative, but I'm
convinced that this is both inaccurate and unnecessary.
Consider ASN.1 or other schema languages, which are - to a very broad
approximation - accessible. Those can be normative. I don't think that ASCII
art can be, except in a few quite narrow cases. The normative purpose in those
cases is probably better served by a formal schema language.
In comparison, most of our packet diagrams are not and cannot be. RFC 791 is perhaps unique in
that it describes a totally fixed structure. But most other protocols are not that way. There are
variable-length portions, optional fields, extension headers, and other things that require text to
explain what is going on. The diagram includes hints with "..." and "[]" and
other conventions. All of which it to say that packet diagrams are often closer to *illustration*
than specification.
If we are to achieve our accessibility goals, there are two angles that we
should consider concurrently:
* Alternative text descriptions of diagrams. I personally find these tedious
to generate and often question the value of them.
* Ensuring that the text contains a complete specification. This is the
attitude that was drilled into me and I've become convinced that it works.
It's possibly the only thing that works reliably.
Isn't there a third option: formal notation to describe packet formats? We do
that with CBOR/CDDL for example, and I attempted a toy version of it for TLV
type formats at https://github.com/becarpenter/tlv .
Brian
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
