Skip to main content

Mathematical notation in RFCs
draft-editorial-rswg-mathinrfcs-02

Document Type Active Internet-Draft (individual)
Authors Alexis Rossi , Martin Thomson , Lars Eggert
Last updated 2026-07-28 (Latest revision 2026-07-24)
Replaces draft-rswg-mathinrfcs
RFC stream Editorial
Intended RFC status Informational
Formats
Stream Editorial state Active editorial stream document
Consensus boilerplate Unknown
Document shepherd Dirk KUTSCHER
draft-editorial-rswg-mathinrfcs-02
Network Working Group                                           A. Rossi
Internet-Draft                              RFC Series Consulting Editor
Intended status: Informational                                M. Thomson
Expires: 25 January 2027                                                
                                                               L. Eggert
                                                            24 July 2026

                     Mathematical notation in RFCs
                   draft-editorial-rswg-mathinrfcs-02

Abstract

   This document defines policy and allows new technology for the
   representation of mathematical notation in RFCXML and relevant
   publication formats.  After implementation of this policy, the chosen
   mathematical notation 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-editorial-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 25 January 2027                [Page 1]
Internet-Draft        Mathematical notation in RFCs            July 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 25 January 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 notation 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.

   Mathematical notation 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 notation 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 25 January 2027                [Page 2]
Internet-Draft        Mathematical notation in RFCs            July 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 notation 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.  Mathematical notation should support both “inline” and “block”
       form.  "Inline" refers to notation that is used as part of text
       (like this x) and "block" form refers to equations that might be
       referenced in the same way that a figure is.

   3.  It must be possible to reference “block” form equations from the
       text in a way that clearly distinguishes them 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”.

   4.  In the "block" form, equations must use the chosen math 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 math form.
       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 notation in the
       HTML publication format correctly using widely used desktop and
       mobile browsers.

Rossi, et al.            Expires 25 January 2027                [Page 3]
Internet-Draft        Mathematical notation in RFCs            July 2026

   8.  The underlying markup of the RFCXML must embed and preserve the
       original mathematical 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 notation 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 math format over preexisting
   alternatives applies only when the math 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 math forms are to be preferred
   over ASCII or Unicode workarounds that have been historically used in
   the series.  It is expected that native math support 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 25 January 2027                [Page 4]
Internet-Draft        Mathematical notation in RFCs            July 2026

   At the time of writing, the general view was that MathML [MATHML]
   best fit the 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.,
              <https://www.latex-project.org/>.

   [MATHML]   Carlisle, D., Ion, P., and R. Miner, "Mathematical Markup
              Language (MathML) Version 3.0 2nd Edition",
              W3C Recommendation, 10 April 2014,
              <https://www.w3.org/TR/2014/REC-MathML3-20140410/>.

   [RFC9720]  Hoffman, P. and H. Flanagan, "RFC Formats and Versions",
              RFC 9720, DOI 10.17487/RFC9720, January 2025,
              <https://www.rfc-editor.org/rfc/rfc9720>.

   [WAI]      W3C, "W3C Accessibility Standards Overview", n.d.,
              <https://www.w3.org/WAI/standards-guidelines/>.

Authors' Addresses

   Alexis Rossi
   RFC Series Consulting Editor
   Email: rsce@rfc-editor.org

   Martin Thomson
   Email: mt@lowentropy.net

Rossi, et al.            Expires 25 January 2027                [Page 5]
Internet-Draft        Mathematical notation in RFCs            July 2026

   Lars Eggert
   Email: lars@eggert.org

Rossi, et al.            Expires 25 January 2027                [Page 6]