RFC 9896

SVG in RFCs

📅 published January 2026, from ietf

Okay bestie, this RFC is about putting SVG pictures into RFCs, and the vibe is "keep the drawings honest, keep them accessible, and let the RPC handle the tooling" 🎀✨

RFC 9896: SVG in RFCs 🦋

Here's the tea on the header stuff, so you don't have to squint at the columns 👀

  • Number: RFC 9896, filed under the Editorial Stream 💅
  • Title: SVG in RFCs
  • Authors: Alexis Rossi (RFC Series Consulting Editor), Nevil Brownlee, Jean Mahoney (RFC Production Center), and Martin Thomson 🫶
  • Category: Informational (so not a Standards Track thing, just for info) 🌸
  • Date: January 2026
  • Obsoletes: RFC 7996 💔
  • Updates: nothing 🙅‍♀️
  • ISSN: 2070-1721

Abstract

okay so this doc sets the policy for putting Scalable Vector Graphics (SVG) into the definitive versions of RFCs and related publication formats 🧚 It keeps the policy requirements from RFC 7996, but drops everything about using one specific SVG profile or implementation code. It also makes the RFC Production Center (RPC) the boss of SVG tooling and implementation decisions 👑

This document obsoletes RFC 7996.

Status of This Memo

Not an Internet Standards Track spec, just published for info 💜

This document is a product of the RFC Series Policy Definition Process. It represents the consensus of the RFC Series Working Group approved by the RFC Series Approval Board. These documents are not candidates for any level of Internet Standard; see Section 2 of RFC 7841 🙈

Info about the current status of this document, any errata, and how to give feedback can be found at:

https://www.rfc-editor.org/info/rfc9896

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, because they describe your rights and restrictions with respect to this document 📜

Table of Contents

1.  Introduction
2.  Policy Requirements
3.  Implementation Guidance
4.  Security Considerations
5.  IANA Considerations
6.  Informative References
Authors' Addresses

1. Introduction ✨

So this doc sets the policy for SVG in the definitive versions of RFCs and related publication formats defined in [RFC9720]. It keeps the policy requirements taken from [RFC7996], but drops all the requirements about using a specific SVG profile or implementation code 💅

SVG was developed by the World Wide Web Consortium (W3C); see [SVG] 🌸

The RFC Production Center (RPC) is in charge of making decisions about SVG tooling and implementation. The RPC may use the content of [RFC7996] as a starting point for those decisions, but they are not bound by [RFC7996]. Also, the RPC may change elements of the implementation as needed to support the RFC authoring community, as long as those changes line up with the policy requirements in this document 🦋

2. Policy Requirements 🎀

Decisions about SVG tooling and implementation are made by the RPC and MUST adhere to the policy requirements in this document:

  • SVG drawings MAY be included in RFCs to help explain a concept more clearly, but they SHOULD NOT be the only representation of that concept. A good-faith effort SHOULD be made to make sure descriptions of concepts (which might include protocols, formats, or system architectures) are fully represented in the text of the RFC. At minimum, SVG drawings SHOULD be consistent with the descriptions in the text of the RFC 💜
  • SVG drawings MUST NOT include animation or interactive features. SVG drawings SHOULD include only limited reactive design elements (scaling, dark/light mode, and perhaps minor adjustments to allow for variations in display technology). The whole point is that the diagram's meaning doesn't get altered 🔥
  • Images and diagrams in RFCs SHOULD be successfully rendered and understood by the widest audience possible. To that end, the RPC MAY prohibit the use of SVG features that are known to lack support on common devices, that do not render on small or low-resolution screens, or that could make diagrams less comprehensible for any significant readership. In particular:
    • SVG drawings MUST NOT contain pointers to external resources.
    • SVG drawings MUST NOT contain executable script.
    • SVG drawings SHOULD be as accessible as possible to people with visual disabilities, including those who have color blindness, those who need to scale or change fonts, and those who use screen-reading software. The RPC will refer to the W3C Accessibility Guidelines [WAI] when making decisions regarding accessibility 🫶
  • Authors MAY include multiple versions of images or diagrams in RFCXML [RFC9720]. Publication formats SHOULD present the versions best suited to each format. In many cases, that will be an SVG 🧚
  • SVG vocabulary and implementation MAY change over time. Changes are not REQUIRED to remain backwards compatible, although maintaining compatibility where possible is encouraged 🌈

The RPC is authorized to place constraints on SVG usage in RFCs for both technical and editorial reasons, so that published RFCs meet the above policy and stay consistent across the RFC Series. The RPC MUST document the acceptable usage of SVG, and all changes to decisions about SVG tooling and implementation 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 the technical and editorial constraints that apply to SVG and give RFC authors guidance on how to produce diagrams that meet those constraints 🌸

The RPC's implementation SHOULD strive to allow SVG drawings produced by widely used drawing tools. Where possible, implementation decisions SHOULD focus on specifying what is disallowed rather than attempting to specify exactly what is allowed 🦋

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. Informative References 📚

[RFC7996]  Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
           RFC 7996, DOI 10.17487/RFC7996, December 2016,
           <https://www.rfc-editor.org/info/rfc7996>.

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

[SVG]      W3C, "Scalable Vector Graphics (SVG) 2", 4 October 2018,
           <https://www.w3.org/TR/2018/CR-SVG2-20181004/>.

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

Authors' Addresses 📮

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

Nevil Brownlee
Email: nevil.brownlee@gmail.com

Jean Mahoney
RFC Production Center
Email: jmahoney@staff.rfc-editor.org

Martin Thomson
Email: mt@lowentropy.net
📦 where this page comes from