On 2026-01-29, at 17:27, Joel Halpern <[email protected]> wrote:
>
> I was having trouble parsing this email. Presumably the problem is on my
> end. But assuming others share my reading, may I ask a clarifying question?
Sorry about that.
> By "the RFC is accessible" are you referring to the important use case of
> taking a published RFC and using it as a basis for a new I-D.
This is certainly a use case where the availability of actual source is helpful.
(For RFC 9438, you can kramdown-rfc-extract-markdown on the last I-D .xml [or
rfc9438.form.xml, if you caught it during AUTH48] and get some source minus
last-minute corrections. Not sure how that is for other RFCs with math.)
> If the mathematical representation in the final XML(or markdown?) is
> processed compared with what humans can work with, that would seem to create
> a problem?
The XML contains *renderings* in plaintext and SVG forms as an <artset element.
There is no easy way to convert these renderings back to the math.
There is currently no way to include the math these renderings were generated
from.
Of course, you can manually translate back
> ┌────────────────┐
> 3 │W - cwnd
> ╲ │ max epoch
> K = ╲ │────────────────
> ╲│ C
into
> K = \sqrt[3]{\frac{W_{max} - cwnd_{epoch}}{C}}
but it is less error-prone to simply have the latter available, which is what
we are moving to.
The “accessibility” use case can be easier to address if the source is
available with the RFC.
Note that currently the authors get to select the tools with which they create
the renderings in the submitted XML; with moving to source availability, we
might include both source and rendered forms (which might be inconsistent!), or
we might try to have a canonical toolset so only the source “needs” to be
included, which in theory is great but in practice might create problems with
the evolution of these tools.
Grüße, Carsten
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
