Hi Martin, Thanks for the response, and thanks Alexis for invoking this discussion.
On 03.06.2026 07:02, Martin Thomson wrote:
Hopefully this helps:https://github.com/alexisannerossi/id-mathinrfcs/pull/9 Inline with some notes where appropriate. On Wed, Jun 3, 2026, at 14:21, 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?
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.
• I'm not sure I understand the implications of the sixth bullet (meaning and and formatting...).I don't think that the implementation being considered achieves this goal, so I'm going to recommend that we remove it. My understanding of the requirement was that it meant that you could extract both the semantics of the math AND how to present it from the format chosen. I am not 100% confident that MathML achieves that in all cases. If someone wants to point to a resource that claims definitively that MathML can capture meaning, I'd try to find a way to restore the text. But the MathML spec only claims "describing mathematical notation and capturing both its structure and content".• Does PDF not have accessibility requirements or are we looking to meet a minimum bar?I did not seek to address this comment. I'm not enough of an expert here to recommend something concrete. If I had to volunteer a position, it is that PDF is best maintained with lower a11y targets than HTML. If something can be done to make math more accessible in PDF, the policy doesn't prohibit that work from being undertaken, but it doesn't need to require it. To that end, I don't know if we want silence on the point, or we could add a note about not having hard requirements for PDF.• The first sentence after the bullets "The RFC is authorized..." reads as though it extends to the content of the mathematical formula. Can we discuss precisely what is intended by that sentence?I don't see how you would infer that. The sentence is a bit too long, but here it is: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. And actually there may be very good cause for that. EKR will forgive me, but I'm going to borrow an example from his blog on age verfication (I enjoyed reading it!).
As you can see, the equation overruns the side bar. Some of this is old hat. The RPC could simply suggest to the author that /Infected**/be given a variable (say) of /I/. But it also has to do with how to break up equations into appropriate verbs. So that *is* somewhat getting into the content, but not the semantics. And that works right up until the point that someone is borrowing a well known *long* equation from another source.
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? Now, the IEEE guidance is really quite focused on LaTeX, but if we're going there *anyway, *why not be consistent? Don't laugh, but this will also help automation, and I think that has to be a consideration at this point.
This raises a few more points: * 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. * 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. * This really is a question to our tooling folk: is our archival tooling up to representing SVGs inline? I will say that Apple Mail does a miserable job of this, btw, often placing inline images at the wrong position. TB has its own problems, typically with sizing images.
• Side point: Are there operational considerations that would cause use of LaTeX equations to limit the use of Markdown?None that I'm aware of. This is roughly how it works in kramdown-rfc today. LaTeX is pretty good at this stuff and it fits pretty well. ~~~math e^{i\pi}+1=0 ~~~
Sooooo... I see this on Gitlab: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/writing-mathematical-expressionsSeems 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.
Thanks, Eliot[1] http://conferences.ieeeauthorcenter.ieee.org/wp-content/uploads/sites/8/IEEE-Math-Typesetting-Guide-for-LaTeX-Users.pdf
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
