On 5/19/25 11:23 AM, Eric Rescorla wrote:
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...
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:
Many people have their own tools to generate some or all of the official
authoritative form of a document from some other intermediate language.
The problem is that the original text, and tools used to generate the
submitted form, are not part of the public record for the document.
We now have some ways for an author to submit a "source" form of a
document, which is then automatically compiled into the authoritative
form. We do this for xml, and markdown. This eliminates my earlier
objection.
But AFAIK we don't have a way to submit multiple pieces of source data
for portions of a document, that are then automatically processed by
different tools and assembled to create the authoritative form.
(We don't even have the vocabulary to talk about this precisely. ISTM
that the lease processed form of the data should be considered the
authoritative form. I have been inconsistent above.)
Thanks,
Paul
_______________________________________________
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
