rfc9896.original   rfc9896.txt 
Network Working Group A. Rossi Editorial Stream A. Rossi
Internet-Draft RFC Series Consulting Editor Request for Comments: 9896 RFC Series Consulting Editor
Obsoletes: 7996 (if approved) N. Brownlee Obsoletes: 7996 N. Brownlee
Intended status: Informational Category: Informational
Expires: 21 March 2026 J. Mahoney ISSN: 2070-1721 J. Mahoney
RFC Production Center RFC Production Center
M. Thomson M. Thomson
17 September 2025 November 2025
SVGs in RFCs SVGs in RFCs
draft-editorial-rswg-svgsinrfcs-04
Abstract Abstract
This document sets policy for the inclusion of SVGs in the definitive This document sets policy for the inclusion of SVGs in the definitive
versions of RFCs and relevant publication formats. It contains versions of RFCs and relevant publication formats. It contains
policy requirements from RFC 7996 and removes all requirements policy requirements from RFC 7996 but removes all requirements
related to using a specific SVG profile or specific implementation related to using a specific SVG profile or implementation code. It
code. It also makes the RFC Publication Center (RPC) responsible for also makes the RFC Publication Center (RPC) responsible for
implementation decisions regarding SVGs. implementation decisions regarding 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-svgsinrfcs/blob/main/
svgsinrfcs.md. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-editorial-rswg-svgsinrfcs/.
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-svgsinrfcs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the RFC Series Policy Definition
and may be updated, replaced, or obsoleted by other documents at any Process. It represents the consensus of the RFC Series Working Group
time. It is inappropriate to use Internet-Drafts as reference approved by the RFC Series Approval Board. Such documents are not
material or to cite them other than as "work in progress." candidates for any level of Internet Standard; see Section 2 of RFC
7841.
This Internet-Draft will expire on 21 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9896.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Policy Requirements . . . . . . . . . . . . . . . . . . . . . 3 2. Policy Requirements
3. Implementation Guidance . . . . . . . . . . . . . . . . . . . 4 3. Implementation Guidance
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations
6. Informative References . . . . . . . . . . . . . . . . . . . 4 6. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses
1. Introduction 1. Introduction
This document sets policy for the inclusion of SVGs (Scalable Vector This document sets policy for the inclusion of Scalable Vector
Graphics) in the definitive versions of RFCs and relevant publication Graphics (SVGs) in the definitive versions of RFCs and relevant
formats. It contains policy requirements taken from [RFC7996] and publication formats. It contains policy requirements taken from
removes all requirements related to using a specific SVG profile or [RFC7996] but removes all requirements related to using a specific
specific implementation code. SVG profile or implementation code.
SVG has been developed by W3C, the World Wide Web Consortium [SVG]. SVG has been developed by the World Wide Web Consortium (W3C); see
[SVG].
The RFC Publication Center (RPC) is responsible for making SVG The RFC Publication Center (RPC) is responsible for making decisions
tooling and implementation decisions. They may want to use the about SVG tooling and implementation. The RPC may use the content of
content of [RFC7996] as a starting point for those decisions, but [RFC7996] as a starting point for those decisions, but they are not
they are not bound by [RFC7996] and they may change elements of the bound by [RFC7996]. In addition, the RPC may change elements of the
implementation as needed to support the RFC authoring community as implementation as needed to support the RFC authoring community as
long as those changes are aligned with the policy requirements in long as those changes are aligned with the policy requirements in
this document. this document.
2. Policy Requirements 2. Policy Requirements
SVG tooling and implementation decisions are made or overseen by the Decisions about SVG tooling and implementation are made or overseen
RPC, and must adhere to the policy requirements in this document. 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 * SVGs may be included in RFCs to help explain a concept more
clearly, but should not be the only representation of that clearly, but they should not be the only representation of that
concept. A good faith effort should be made to assure that concept. A good-faith effort should be made to ensure that
descriptions of concepts - which might include protocols, formats, descriptions of concepts -- which might include protocols,
or system architectures - are fully represented in the text of the formats, or system architectures -- are fully represented in the
RFC. At minimum, SVGs should be consistent with the text. text of the RFC. At minimum, SVGs should be consistent with the
descriptions in the text of the RFC.
* SVGs must not include animation or interactive features. SVGs * SVGs must not include animation or interactive features. SVGs
should include only limited reactive design elements (scaling, should include only limited reactive design elements (scaling,
dark/light mode, and perhaps minor adjustments to allow for dark/light mode, and perhaps minor adjustments to allow for
variations in display technology). The intent of this is to variations in display technology). The intent of this is to
ensure that the diagram's meaning is not altered. ensure that the diagram's meaning is not altered.
* Images and diagrams in RFCs should be successfully rendered and * Images and diagrams in RFCs should be successfully rendered and
understood by the widest audience possible. To that end, the RPC understood by the widest audience possible. To that end, the RPC
may prohibit the use of SVG features that are known to lack may prohibit the use of SVG features that are known to lack
support on common devices, that do not render on small or low- support on common devices, that do not render on small or low-
resolution screens, or that could make diagrams less resolution screens, or that could make diagrams less
comprehensible for any significant readership. This includes: comprehensible for any significant readership. This includes:
- SVGs must not contain pointers to external resources. - SVGs must not contain pointers to external resources.
- SVGs must not contain executable script. - SVGs must not contain executable script.
- SVGs should be as accessible as possible to people with visual - SVGs should be as accessible as possible to people with visual
disabilities, including those who have color blindness, those disabilities, including those who have color blindness, those
who need to scale or change fonts, and those who use screen who need to scale or change fonts, and those who use screen-
reading software. The RPC will refer to the W3C Accessibility reading software. The RPC will refer to the W3C Accessibility
Guidelines [WAI] when making decisions regarding accessibility. Guidelines [WAI] when making decisions regarding accessibility.
* Authors may include multiple versions of images or diagrams in * Authors may include multiple versions of images or diagrams in
rfcxml. Publication formats should present the versions best RFCXML. Publication formats should present the versions best
suited to each format. In many cases, that will be an SVG. suited to each format. In many cases, that will be an SVG.
* SVG vocabulary and implementation may change over time. Changes * SVG vocabulary and implementation may change over time. Changes
are not required to remain backwards-compatible, although are not required to remain backwards compatible, although
maintaining compatibility where possible is encouraged. maintaining compatibility where possible is encouraged.
The RPC is authorized to place constraints on SVG usage in RFCs for The RPC is authorized to place constraints on SVG usage in RFCs for
both technical and editorial reasons in order to ensure that both technical and editorial reasons in order to ensure that
published RFCs meet the above policy and to provide consistency published RFCs meet the above policy and to provide consistency
across the RFC series. The RPC must document the acceptable usage of across the RFC Series. The RPC must document the acceptable usage of
SVGs, and all changes to tooling or implementation decisions must be SVGs, and all changes to decisions about SVG tooling and
widely communicated to the RFC author community using mailing lists implementation must be widely communicated to the RFC author
or other means. community using mailing lists or other means.
3. Implementation Guidance 3. Implementation Guidance
The RPC is expected to solicit community input before making The RPC is expected to solicit community input before making
decisions and to publicly explain their reasoning. decisions and to publicly explain their reasoning.
Documentation produced by the RPC should describe what technical and Documentation produced by the RPC should describe the technical and
editorial constraints apply to SVGs and provide RFC authors with editorial constraints that apply to SVGs and provide RFC authors with
guidance on how to produce diagrams that meet these constraints. guidance on how to produce diagrams that meet those constraints.
The RPC's implementation should strive to allow SVGs produced by The RPC's implementation should strive to allow SVGs produced by
widely used drawing tools. Where possible, implementation decisions widely used drawing tools. Where possible, implementation decisions
should focus on specifying what is disallowed, rather than attempting should focus on specifying what is disallowed rather than attempting
to specify exactly what is allowed. to specify exactly what is allowed.
The RPC should periodically review and revise their practices. The RPC should periodically review and revise their practices.
4. Security Considerations 4. Security Considerations
This document has no security considerations. This document has no security considerations.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Informative References 6. Informative References
[RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
RFC 7996, DOI 10.17487/RFC7996, December 2016, RFC 7996, DOI 10.17487/RFC7996, December 2016,
<https://www.rfc-editor.org/rfc/rfc7996>. <https://www.rfc-editor.org/info/rfc7996>.
[SVG] W3C, "Scalable Vector Graphics", n.d., [SVG] W3C, "Scalable Vector Graphics (SVG) 2",
<https://www.w3.org/TR/SVG/>. <https://www.w3.org/TR/SVG/>.
[WAI] W3C, "W3C Accessibility Standards Overview", n.d., [WAI] W3C, "W3C Accessibility Standards Overview",
<https://www.w3.org/WAI/standards-guidelines/>. <https://www.w3.org/WAI/standards-guidelines/>.
Authors' Addresses Authors' Addresses
Alexis Rossi Alexis Rossi
RFC Series Consulting Editor RFC Series Consulting Editor
Email: rsce@rfc-editor.org Email: rsce@rfc-editor.org
Nevil Brownlee Nevil Brownlee
Email: nevil.brownlee@gmail.com Email: nevil.brownlee@gmail.com
 End of changes. 24 change blocks. 
80 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.48.