On Wed, Jun 3, 2026, at 17:04, Eliot Lear wrote: >>> • Do we need to be clearer on what "incidental use" is? >> I don't think so. There is judgment involved here, but whether math is >> considered incidental to the purpose of a figure should become clear with >> time. RPC policies might evolve to handle that better than this policy can. > I think I understand why the text was put in, but my point is that I > want to test whether or not there really is a legitimate exception > here. So just between us chickens, could someone contrive an example > that might be a reasonable exception?
Actual examples already exist. https://datatracker.ietf.org/doc/html/draft-savage-ppm-3phm-mpc-01#figure-1 (and other figures in that document) are cases where math notation is put in illustrative figures. More generally, it is common for cryptographic protocols to be presented as sequence diagrams where the messages are math-y to some degree. Variable names with subscripts (as above) at a minimum. It is possible to include MathML in SVG (https://www.comfsm.fm/~dleeling/tech/mathml-in-svg.xhtml). I don't think that we can safely go there as a practical matter, though. Browser might support that, but I doubt that the tool we use for producing PDFs would be happy, because most graphics libraries don't. > Also, I'm sure we all know this, but the policy should be clear (and we > do have pedantic people in the community) that code blocks (a) should > not be used to represent equations or otherwise evade this policy, but > also (b) the policy is not meant to interfere with actual code. The policy is that the RPC exercises judgment in the following of the policy. If you want to offer text, that would be helpful, because I'm out of ideas. >>> The RPC is authorized to make decisions about the representation of >>> mathematical notation for both technical and editorial reasons in order to >>> ensure that published RFCs meet the above policy and to provide consistency >>> across the RFC series. >> I read that as saying that - for any document - the RPC can choose how to >> most effectively present math. And that they need to consider policy, >> series consistency, editorial, and technical concerns alike. > It's the term "technical concerns" that I read into. The decisions is about the "representation". So, yes, that would include variable substitution (or ¬Infected, which would probably work in that case). > With that I want to meander just a bit toward existing work. In > particular I want to highlight the IEEE Math Typesetting Guide[1], > which itself references AMS guidelines. Should the policy require that > our documents conform to the IEEE guidance? No. The bulk of that document is the domain of a style guide, which we have already delegated to the RPC to maintain. I maintain that the policy here is still correct. > • Should equations be rendered in such a way that they can be easily > copied and pasted using common tool sets? I think this might be quite > a tall ask. Using EKR's example above, he's relying on MathJAX, which > is nice, but doesn't observe certain CSS characteristics when rendering > into SVG, as you saw above. Switching to CHTML corrects that problem, > BTW, which I'm not entirely certain is a very interoperable thing for > renderers. Ideally, yes, but the current state of play there is so uneven as to make it impractical for us to mandate in policy. The right play here is to let the RPC factor that into their decision process. > • Related, should the draft give at least some guidance to the > community on how to discuss an equation? Sadly, copying and pasting > MathML-rendered equations usually results in the raw MathML being > rendered these days. Entertainingly, Github comments may get this > better than email (see below), because one can copy into markdown. We've already evolved tools for that. I see LaTeX being used in email, even if it doesn't render. All sorts of things. I don't see that as a problem to be solved here, aside from the one important thing, which is that block-form equations need to have the same sorts of affordances as figures, so they can be referred to ("Equation 3", just like "Figure 3"). That's already in the draft. > I see this on Gitlab: > > https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/writing-mathematical-expressions > > Seems like we might want to follow that pattern. I realize that's not > a RSWG decision, but it's good to understand how we are aligned with > other communities. That's a question for the folks who maintain the markdown formats. I'm sure that Carsten has thought carefully about how to make this work already. The use of $inline-math$ just like in LaTeX is appealing, of course. Absolutely none of our business on the policy end. -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
