On Mon, May 19, 2025 at 7:51 AM Eliot Lear <l...@lear.ch> wrote:
> Hiya,
> On 19.05.2025 16:44, Paul Kyzivat wrote:
>
>
> No one formal language is going to meet all needs.
>
> I think that's a good take away from this discussion. What's the take
> away for this group? In my view, it is better that tooling handle what it
> can handle at the highest layer it can process stuff. That will lay the
> ground for better consistency across the series, in terms of use of colors,
> sizing, fonts, etc.
>
> A good example of where to have another food fight: should we support UML
> as a high level description or should we incorporate mermaid? Alexa points
> out draw.io is dropping support for the former in favor of the latter.
> But we need something that can do appropriate generation into ASCII still.
> Anyone tried that with Mermaid?
>
> And I'm dying to see what people are doing with Markdown and math...
>
Thanks Eliot for trying to help pull us up a level.
I think there are a number of questions being grouped together
here. The first is around how much we should be specifying protocols
in formal languages, whether ABNF or bit-wise languages like in TLS or
QUIC. The second is what tooling we should be providing/requiring for
generating rich images in RFCs.
Where these two questions intersect is when those rich images are part
of the formal specification of the protocol, as in bit diagrams.
To try to sharpen this point, consider the QUIC initial packet:
Initial Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 0,
Reserved Bits (2),
Packet Number Length (2),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Token Length (i),
Token (..),
Length (i),
Packet Number (8..32),
Packet Payload (8..),
}
This is equivalent to a bit diagram and in many pre-QUIC
specifications, that's what it would have been. The IETF could, if it
wanted, require that specifications contain this kind of formal
description of PDUs. This does not preclude the existence of bit
diagrams or even make them difficult to provide: one could readily
write a tool to draw a bit diagram based on this input and I'm sure
many people have done so for similar languages (and most likely for
this one!), so that the bit diagrams were automatically produced as
part of the RFC production process. On the other side of the spectrum,
nothing prevents authors from writing their bit diagrams in some DSL
and then compiling them to ASCII and cutting-and-pasting them into the
markdown, or anything in between.
A similar situation exists for UML or Mermaid diagrams, where we have
some DSL which then is compiled down to a diagram (the same for LaTeX
math notation). There are a number of possible options, including the
following.
1. Say nothing and tell people they can embed compiled diagrams.
2. Support a specific set of DSLs which are handled automatically
but allow people to paste in their own stuff.
3. Require that anything visual also have *some* DSL source.
4. (3) but require specific DSLs.
I'm still figuring out what I think about this--and perhaps others may
be too--but I suspect that the right answer is to try to provide
first-class support for a single set of DSLs for each use case but at
present not require anything. To try to break down the use cases a
bit, we might have something like:
- Math: LaTeX?
- Ladder diagrams: Mermaid? UML?
- State machine diagrams: ???
- Bit diagrams: Maybe something derived from QUIC?
On this last point, I'm definitely not saying that we should require
QUIC-style language for all protocols; that would not be appropriate
and one size doesn't fit all. At most the idea here would be that if
you are going to do a bit diagram you should also provide some
DSL-type form.
Like I said, I'm still trying to figure out what I think, but perhaps
this will help others form their own opinions, even if only because
they violently disagree!
-Ekr
_______________________________________________
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
