On Jan 27, 2026, at 20:14, Martin Thomson <[email protected]> wrote: > > On Wed, Jan 28, 2026, at 12:29, Paul Hoffman wrote: >> It's a short document, so I doubt I missed it, but: what is the >> motivation for prohibiting what works now? It doesn't work "all that >> well", but that's true of at least a quarter of RFCXML. > > The motivation has a few angles: > > * Accessibility. An SVG drawing of math is only accessible to sighted users > (conceding that an LLM might be able to transform an image into something > accessible, but no need for that). > > * Consistency. Equations that are rendered through a single coherent process > can be more readily processed and rendered consistently. > > * Minor stuff like styling is more feasible with something like MathML.
Those seem reasonable. Please add to the next draft. >> Will I really be prohibited from saying "2^128" or "packet size / relay >> time"? > > Probably not. As with any of these policies, judgment is a necessary part of > the application of policy. The RPC will use its judgement based on RSWG RFCs. Our RFCs should be specific where we have consensus on specificity, and should explicitly say where we do not. > I don't know what 2^128 ends up being in the new world, but it already > manifests as 2<sup>128</sup> in many instances today. Having that in text > without math wrapping is probably better than using math in some cases. Requiring authors to learn "math wrapping" just to use simple math seems bad. Causing math-related changes for simple math that the authors don't see until AUTH48 seems bad. >> If I can express a necessary equation in a simple SVG figure, will I >> really be prohibited from doing so? > > I would hope that the RPC, once they have better tools, would not allow that > document to proceed without first replacing it with whatever form is > ultimately adopted. This is an interesting policy question for the RSWG. A stream manager turns a document over the the RFC Editor that has an equation in SVG, and the RFC Editor sees that in their ingestion checks. Does the RPC: a) Send the document back to the stream immediately b) Accept the document but make a substantial change to a technically important part of the document that first appears during AUTH48 (and thus only to the authors and shepherd)? c) Flag the error to the stream and block the document from being processed until the stream causes a new version of the draft to be issued, and the stream manager approves it (again) for publication? > In light of your question and on re-reading the text, I do think that the > prohibition might need to be tuned a little to consider the use of Unicode > symbols for variables. s/a little// This is a major change to an established practice: it should be made explicit, possibly with examples. > If I have to refer to a λ parameter in text, having that appear directly is > potentially OK, as opposed to having to type $\lambda$ and invoke the inline > math handling. That said, the latter has value and might still be easier to > handle for those of us without Greek characters on our keyboards (on Windows > at least, the emoji picker is how I find Greek letters and the usability > sucks). Fully agree. > My view is that this sort of thing is best left for style guides and not > policy, but maybe this document can say something sensible on that point. The RFCE Editor Style Guide says what changes the RPC might make when turning a draft into an RFC. That seems awfully late in the process to say "we will change technically relevant parts of the draft, and those changes will only be reviewed in AUTH48". >> I hope that this document does not reach consensus without saying what >> is wrong with the current methods. > > I assume that this is just a request for discussion here. Which is > reasonable. On the other hand, I don't think that there is much value in > litigating the extent of the badness of present practice. Yes, yes, and yes. > We did that for SVG, but didn't end up capturing much (if any) of it in the > final product of the group. And yes. --Paul Hoffman -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
