Network Working Group                                           A. RossiInternet-Draft                              RFC Series Consulting EditorIntended status: Informational                                M. ThomsonExpires: 31 July 2026                                                                                                                  L. Eggert                                                         27 January 2026                     Mathematical notation in RFCs                       draft-rossi-mathinrfcs-00Abstract   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,   mathematical notation in RFCXML and the HTML publication format will   no longer be accepted in Unicode or Scalable Vector Graphics (SVGs).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/edit/main/draft-   rossi-mathinrfcs-00.md.  Status information for this document may be   found at https://datatracker.ietf.org/doc/draft-rossi-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 31 July 2026                  [Page 1]Internet-Draft        Mathematical notation in RFCs         January 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 31 July 2026.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 Requirements . . . . . . . . . . . . . . . . . . . . .   3   3.  Implementation Guidance . . . . . . . . . . . . . . . . . . .   3   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4   7.  Informative References  . . . . . . . . . . . . . . . . . . .   4   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   41.  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.   Mathematical notation in RFCs will no longer be accepted in Unicode   or Scalable Vector Graphics (SVGs) for RFCXML or the HTML publication   format.  Other publication formats may use the best solution   available for displaying math.  This document specifically removes   support for displaying math in unicode or SVGs in the HTML   publication format as these are not adequately accessible to all   readers.   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.Rossi, et al.             Expires 31 July 2026                  [Page 2]Internet-Draft        Mathematical notation in RFCs         January 20262.  Policy Requirements   *  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.   *  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.   *  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”.   *  Major desktop and mobile browsers must be capable of natively      rendering the mathematical notation correctly in the HTML      publication format.   *  The chosen implementation should allow representation of both the      meaning and the formatting of the mathematical content.   *  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 in   order to ensure 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.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.Rossi, et al.             Expires 31 July 2026                  [Page 3]Internet-Draft        Mathematical notation in RFCs         January 2026   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.   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   [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   Lars Eggert   Email: lars@eggert.orgRossi, et al.             Expires 31 July 2026                  [Page 4]