---
title: SVGs in RFCs
docname: draft-editorial-rswg-svgsinrfcs-04
venue:
  group: RSWG
  type: Editorial Stream Working Group
  mail: rswg@rfc-editor.org
  arch: https://mailarchive.ietf.org/arch/browse/rswg/
  github: "alexisannerossi/id-svgsinrfcs"
  latest: "https://github.com/alexisannerossi/id-svgsinrfcs/blob/main/svgsinrfcs.md"
number: 9896
stand_alone: true
v: 3
obsoletes: 7996
ipr: trust200902
kw: Internet-Draft
cat: info
submissionType: editorial
date: 2025-11
keyword:
 - SVG

author:
  -
    ins: A. Rossi
    name: Alexis Rossi
    organization: RFC Series Consulting Editor
    email: rsce@rfc-editor.org
  -
    ins: N. Brownlee
    name: Nevil Brownlee
    organization:
    email: nevil.brownlee@gmail.com
  -
    ins: J. Mahoney
    name: Jean Mahoney
    organization: RFC Production Center
    email: jmahoney@staff.rfc-editor.org
  -
    ins: M. Thomson
    name: Martin Thomson
    organization:
    email: mt@lowentropy.net

normative:

informative:
  RFC7996:
  SVG:
    author:
      org: W3C
    title: Scalable Vector Graphics (SVG) 2
    target: https://www.w3.org/TR/SVG/
    date: false
  WAI:
    author:
      org: W3C
    title: W3C Accessibility Standards Overview
    target: https://www.w3.org/WAI/standards-guidelines/
    date: false

--- abstract

<!-- [rfced] Abstract

a) The Abstract does not explicitly mention that this document obsoletes RFC
7996. See the checklist in the "Abstract" section of
https://authors.ietf.org/required-content. Please review and let us know how
you would like to update.

b) This sentence mentions the RPC being responsible for implementation
decisions. Other instances in the document mention the RPC being responsible
for decisions about both tooling and implementation. Are any updates needed?

Original:
   It also makes the RFC Publication Center (RPC) responsible for
   implementation decisions regarding SVGs.

Perhaps:
   It also makes the RFC Publication Center (RPC) responsible for
   decisions about SVG tooling and implementation.
-->

<!-- [rfced] Abstract/Introduction: Is "sets" the best word choice here? Would
"defines" or something else be better? Also, will all readers know what the
"definitive versions of RFCs and relevant publication formats" are? Would
adding a citation or clarification  in the Introduction be helpful? If so,
please provide the appropriate citation or text.

Original:
   This document sets policy for the inclusion of SVGs in the definitive
   versions of RFCs and relevant publication formats.
   ...
   This document sets policy for the inclusion of SVGs (Scalable Vector
   Graphics) in the definitive versions of RFCs and relevant publication
   formats.
-->

This document sets policy for the inclusion of SVGs in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from RFC 7996 and but removes all requirements related to using a specific SVG profile or specific implementation code. It also makes the RFC Publication Center (RPC) responsible for implementation decisions regarding SVGs.

--- middle

# Introduction

This document sets policy for the inclusion of SVGs (Scalable Scalable Vector Graphics) Graphics (SVGs) in the definitive versions of RFCs and relevant publication formats. It contains policy requirements taken from {{RFC7996}} and but removes all requirements related to using a specific SVG profile or specific implementation code.

SVG has been developed by W3C, the World Wide Web Consortium (W3C); see {{SVG}}.

The RFC Publication Center (RPC) is responsible for making decisions about SVG tooling and implementation decisions. They implementation. The RPC may want to use the content of {{RFC7996}} as a starting point for those decisions, but they are not bound by {{RFC7996}} and they {{RFC7996}}. In addition, the RPC may change elements of the implementation as needed to support the RFC authoring community as long as those changes are aligned with the policy requirements in this document.

# Policy Requirements

<!-- [rfced] Section 2: In the text below, how may we update "This includes"?
It is not clear what "This" refers to.

Original:
   *  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.  This includes:

      -  SVGs must not contain pointers to external resources.

      -  SVGs must not contain executable script.

      -  SVGs should be as accessible as possible to people with visual
         disabilities, ...

Perhaps:
   *  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:

      -  SVGs must not contain pointers to external resources.

      -  SVGs must not contain executable script.

      -  SVGs should be as accessible as possible to people with visual
         disabilities, ...

Or:
   *  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.  For instance:

      -  SVGs must not contain pointers to external resources.

      -  SVGs must not contain executable script.

      -  SVGs should be as accessible as possible to people with visual
         disabilities, ...
-->

<!-- [rfced] Section 2: FYI, we have updated the sentence below to clarify that
SVGs should be consistent with the content of the RFC (rather than the text
output file of the RFC).

Original:
  At minimum, SVGs should be consistent with the text.

Current:
  At minimum, SVGs should be consistent with the descriptions
  in the text of the RFC.
-->

<!-- [rfced] Section 2: This sentence mentions that decisions about SVG
tooling and implementation are "made or overseen" by the RPC. The document
mentions several times that the RPC is responsible for making decisions, but
this is the only mention of "overseen" in the document. Please review and let
us know if any updates are needed.

Original:
   SVG tooling and implementation decisions are made or overseen by the
   RPC, and must adhere to the policy requirements in this document.
-->

<!-- [rfced] Section 2: We updated "rfcxml" to "RFCXML" in the first sentence
below per RFC 9720. Would it be helpful to also include a citation to RFC 9720
or other applicable reference here?

Original:
   *  Authors may include multiple versions of images or diagrams in
      rfcxml.  Publication formats should present the versions best
      suited to each format.  In many cases, that will be an SVG.

Perhaps:
   *  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.
-->

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

* SVGs 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 good-faith effort should be made to assure ensure that descriptions of concepts - -- which might include protocols, formats, or system architectures - -- are fully represented in the text of the RFC. At minimum, SVGs should be consistent with the text. descriptions in the text of the RFC.
* SVGs must not include animation or interactive features. SVGs should include only limited reactive design elements (scaling, dark/light mode, and perhaps minor adjustments to allow for variations in display technology). The intent of this is to ensure that the diagram's meaning is not 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. This includes:
  * SVGs must not contain pointers to external resources.
  * SVGs must not contain executable script.
  * SVGs 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 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. RFCXML.  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, 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
in order to ensure that published RFCs meet the above policy
and to provide consistency across the RFC series. Series.
The RPC must document the acceptable usage of SVGs, and all changes to decisions about SVG tooling or and implementation decisions must be widely communicated to the RFC author community using mailing lists or other means.

# 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 the technical and editorial constraints that apply to SVGs
and provide RFC authors with guidance on how to produce diagrams that meet these those constraints.

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

The RPC should periodically review and revise their practices.

# Security Considerations

This document has no security considerations.

# IANA Considerations

This document has no IANA actions.

--- back

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.

-->