rfc9896v1.txt   rfc9896.txt 
Editorial Stream A. Rossi Editorial Stream A. Rossi
Request for Comments: 9896 RFC Series Consulting Editor Request for Comments: 9896 RFC Series Consulting Editor
Obsoletes: 7996 N. Brownlee Obsoletes: 7996 N. Brownlee
Category: Informational Category: Informational
ISSN: 2070-1721 J. Mahoney ISSN: 2070-1721 J. Mahoney
RFC Production Center RFC Production Center
M. Thomson M. Thomson
November 2025 December 2025
SVGs in RFCs SVG in RFCs
Abstract Abstract
This document sets policy for the inclusion of SVGs in the definitive This document defines policy for the inclusion of Scalable Vector
versions of RFCs and relevant publication formats. It contains Graphics (SVG) in the definitive versions of RFCs and relevant
policy requirements from RFC 7996 but removes all requirements publication formats. It contains policy requirements from RFC 7996
related to using a specific SVG profile or implementation code. It but removes all requirements related to using a specific SVG profile
also makes the RFC Production Center (RPC) responsible for or implementation code. It also makes the RFC Production Center
implementation decisions regarding SVGs. (RPC) responsible for decisions about SVG tooling and implementation.
This document obsoletes RFC 7996.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the RFC Series Policy Definition This document is a product of the RFC Series Policy Definition
Process. It represents the consensus of the RFC Series Working Group Process. It represents the consensus of the RFC Series Working Group
approved by the RFC Series Approval Board. Such documents are not approved by the RFC Series Approval Board. Such documents are not
candidates for any level of Internet Standard; see Section 2 of RFC candidates for any level of Internet Standard; see Section 2 of RFC
skipping to change at line 61 skipping to change at line 63
1. Introduction 1. Introduction
2. Policy Requirements 2. Policy Requirements
3. Implementation Guidance 3. Implementation Guidance
4. Security Considerations 4. Security Considerations
5. IANA Considerations 5. IANA Considerations
6. Informative References 6. Informative References
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
This document sets policy for the inclusion of Scalable Vector This document defines policy for the inclusion of Scalable Vector
Graphics (SVGs) in the definitive versions of RFCs and relevant Graphics (SVG) in the definitive versions of RFCs and relevant
publication formats. It contains policy requirements taken from publication formats defined in [RFC9720]. It contains policy
[RFC7996] but removes all requirements related to using a specific requirements taken from [RFC7996] but removes all requirements
SVG profile or implementation code. related to using a specific SVG profile or implementation code.
SVG has been developed by the World Wide Web Consortium (W3C); see SVG has been developed by the World Wide Web Consortium (W3C); see
[SVG]. [SVG].
The RFC Production Center (RPC) is responsible for making decisions The RFC Production Center (RPC) is responsible for making decisions
about SVG tooling and implementation. The RPC may use the content of about SVG tooling and implementation. The RPC may use the content of
[RFC7996] as a starting point for those decisions, but they are not [RFC7996] as a starting point for those decisions, but they are not
bound by [RFC7996]. In addition, the RPC 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
Decisions about SVG tooling and implementation are made or overseen Decisions about SVG tooling and implementation are made by the RPC
by the RPC and must adhere to the policy requirements in this and must adhere to the policy requirements in this document:
document:
* SVGs may be included in RFCs to help explain a concept more * SVG drawings may be included in RFCs to help explain a concept
clearly, but they should not be the only representation of that more clearly, but they should not be the only representation of
concept. A good-faith effort should be made to ensure that that concept. A good-faith effort should be made to ensure that
descriptions of concepts -- which might include protocols, descriptions of concepts -- which might include protocols,
formats, or system architectures -- are fully represented in the formats, or system architectures -- are fully represented in the
text of the RFC. At minimum, SVGs should be consistent with the text of the RFC. At minimum, SVG drawings should be consistent
descriptions in the text of the RFC. with the descriptions in the text of the RFC.
* SVGs must not include animation or interactive features. SVGs * SVG drawings must not include animation or interactive features.
should include only limited reactive design elements (scaling, SVG drawings should include only limited reactive design elements
dark/light mode, and perhaps minor adjustments to allow for (scaling, dark/light mode, and perhaps minor adjustments to allow
variations in display technology). The intent of this is to for 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. In particular:
- SVGs must not contain pointers to external resources. - SVG drawings must not contain pointers to external resources.
- SVGs must not contain executable script. - SVG drawings must not contain executable script.
- SVGs should be as accessible as possible to people with visual - SVG drawings should be as accessible as possible to people with
disabilities, including those who have color blindness, those visual disabilities, including those who have color blindness,
who need to scale or change fonts, and those who use screen- those who need to scale or change fonts, and those who use
reading software. The RPC will refer to the W3C Accessibility screen-reading software. The RPC will refer to the W3C
Guidelines [WAI] when making decisions regarding accessibility. 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 [RFC9720]. Publication formats should present the versions
suited to each format. In many cases, that will be an SVG. best 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 decisions about SVG tooling and SVG, and all changes to decisions about SVG tooling and
implementation must be widely communicated to the RFC author implementation must be widely communicated to the RFC author
community using mailing lists 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 the technical and Documentation produced by the RPC should describe the technical and
editorial constraints that apply to SVGs and provide RFC authors with editorial constraints that apply to SVG and provide RFC authors with
guidance on how to produce diagrams that meet those 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 SVG drawings produced
widely used drawing tools. Where possible, implementation decisions by widely used drawing tools. Where possible, implementation
should focus on specifying what is disallowed rather than attempting decisions should focus on specifying what is disallowed rather than
to specify exactly what is allowed. attempting 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/info/rfc7996>. <https://www.rfc-editor.org/info/rfc7996>.
[SVG] W3C, "Scalable Vector Graphics (SVG) 2", [RFC9720] Hoffman, P. and H. Flanagan, "RFC Formats and Versions",
<https://www.w3.org/TR/SVG/>. 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", [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
 End of changes. 17 change blocks. 
43 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.48.