Network Working Group A. Rossi Internet-Draft RFC Series Consulting Editor Intended status: Informational M. Thomson Expires: 19 March 2027 L. Eggert 15 September 2026 Mathematical notation in RFCs draft-editorial-rswg-mathinrfcs-03 Abstract This document defines policy and allows new technology for the representation of mathematical content in RFCXML and relevant publication formats. After implementation of this policy, the chosen mathematical notation format should be used in RFCXML and the HTML publication format. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://github.com/alexisannerossi/id-mathinrfcs/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rswg-mathinrfcs/. Discussion of this document takes place on the RSWG Editorial Stream Working Group mailing list (mailto:rswg@rfc-editor.org), which is archived at https://mailarchive.ietf.org/arch/browse/rswg/. Source for this draft and an issue tracker can be found at https://github.com/alexisannerossi/id-mathinrfcs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Rossi, et al. Expires 19 March 2027 [Page 1] Internet-Draft Mathematical notation in RFCs September 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Implementation Guidance . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Informative References . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction This document allows new technology for the representation of mathematical content in RFCXML and relevant publication formats defined in [RFC9720]. This document also defines policy requirements for the inclusion of mathematical content. The primary motivations for this new policy are to improve accessibility for non-sighted users and to ensure consistent processing and rendering across the RFC series. Using a specific mathematical notation format in RFCs provides an option to replace existing practices for conveying mathematical content. Though some simpler uses of math can be represented using inline text, native support for mathematical content can provide a superior replacement for text, Scalable Vector Graphics (SVG), or ASCII art. In HTML, native support for math can then be used in place of these alternatives. Other publication formats may use the best solution available for displaying math. Rossi, et al. Expires 19 March 2027 [Page 2] Internet-Draft Mathematical notation in RFCs September 2026 The RFC Publication Center (RPC) is responsible for tooling and implementation decisions regarding this policy. We expect the adoption of this policy to require changes and adaptation during implementation in early documents using this technology. 2. Policy 1. Mathematical content should appear correctly in RFCXML, HTML and PDF publication formats, as well as any future publication formats that can support it. The RPC will determine how to best represent math in the Text publication format. 2. The mathematical notation format should support both “inline” and “block” form. "Inline" refers to math that is used as part of text (like this x) and "block" form refers to content that might be referenced in the same way that a figure is. 3. It must be possible to reference “block” form mathmatical content from the text in a way that clearly distinguishes equations from references to figures (or other elements that can be referenced, such as citations). In academic writing, figures are usually referenced as “Fig. n” while equations are referenced as “Eq. n”. Authors may determine whether their "block" form content is a figure or an equation. 4. In the "block" form, content must use the chosen mathmatical notation format. ASCII art or SVG renderings of math must not be used in any format except for the Text publication format, as noted. 5. The RPC is expected to exercise discretion regarding the inclusion of simple "inline" math in the body of the document or in figures. Simple text may be used in some cases when the author prefers it. The RPC may adjust their requirements as they gain experience. 6. Including math in figures might be challenging due to technical constraints on the composition of SVG and the chosen mathmatical notation format. Math in figures can be presented using pure text or SVG alternatives when that math content is only illustrative. More substantive math can be included in these less accessible forms in figures when it is also presented in a more accessible form elsewhere in the document on the condition that those alternative presentations are clearly identified. 7. It must be possible to render the mathematical content in the HTML publication format correctly using widely used desktop and mobile browsers. Rossi, et al. Expires 19 March 2027 [Page 3] Internet-Draft Mathematical notation in RFCs September 2026 8. The underlying markup of the RFCXML must embed and preserve the original mathematical notation source code. Users should be able to readily extract this source representation without having to reverse-engineer it from the final visual renderings. 9. Accessibility should be supported for readers of the HTML publication format who rely on various devices, software, and visual presentations (e.g. braille readers, screen readers, enlarging, and text formatting). The RPC will refer to the W3C Accessibility Guidelines [WAI] when making decisions regarding accessibility. The RPC is authorized to make decisions about the representation of mathematical content for both technical and editorial reasons. This ensures that published RFCs meet the above policy and to provide consistency across the RFC series. The RPC must document their decisions in a public place, and all changes to tooling or implementation decisions must be widely communicated to the RFC author community using mailing lists or other means. Any requirement to use a native mathmatical notation format over preexisting alternatives applies only when the format is considered sufficiently mature. There will be a period where the solution is being developed. During this time, the solution might be incomplete or it might be impractical for existing documents to adapt. The RPC is expected to exercise judgment on a case-by-case basis. 3. Implementation Guidance The RPC is expected to solicit community input before making decisions and to publicly explain their reasoning. Documentation produced by the RPC should describe what technical and editorial constraints apply to the HTML publication format and CSS files. That guidance should include updates to style guides to provide advice on how to decide when mathematical notation formats are to be preferred over ASCII or Unicode workarounds that have been historically used in the series. It is expected that native mathematical notation would be preferred in most cases, except for the simplest cases or to specifically support text renderings. Where possible, implementation decisions should focus on specifying what is disallowed, rather than attempting to specify exactly what is allowed. These decisions should also consider the authoring process as a significant factor in implementation. Rossi, et al. Expires 19 March 2027 [Page 4] Internet-Draft Mathematical notation in RFCs September 2026 At the time of writing, the general view was that MathML [MATHML] best fit the mathematical notation format requirements for inclusion in publication formats and RFC XML. For authoring, the use of LaTeX [LaTeX] math syntax was considered most suitable. The RPC is encouraged to consider these options seriously, unless better options become available in future. The RPC should periodically review and revise their practices. 4. Security Considerations This document has no security considerations. 5. IANA Considerations This document has no IANA actions. 6. Acknowledgements This document has greatly benefited from the input of Carsten Bormann who provided significant input on the early draft versions of this document. 7. Informative References [LaTeX] "LaTeX - A document preparation system", n.d., . [MATHML] Carlisle, D., Ion, P., and R. Miner, "Mathematical Markup Language (MathML) Version 3.0 2nd Edition", W3C Recommendation, 10 April 2014, . [RFC9720] Hoffman, P. and H. Flanagan, "RFC Formats and Versions", RFC 9720, DOI 10.17487/RFC9720, January 2025, . [WAI] W3C, "W3C Accessibility Standards Overview", n.d., . Authors' Addresses Alexis Rossi RFC Series Consulting Editor Email: rsce@rfc-editor.org Martin Thomson Rossi, et al. Expires 19 March 2027 [Page 5] Internet-Draft Mathematical notation in RFCs September 2026 Email: mt@lowentropy.net Lars Eggert Email: lars@eggert.org Rossi, et al. Expires 19 March 2027 [Page 6]