rfc9896.original.md		rfc9896.md
	---		---
	title: SVGs in RFCs		title: SVGs in RFCs
	docname: draft-editorial-rswg-svgsinrfcs-04		docname: draft-editorial-rswg-svgsinrfcs-04
	venue:		number: 9896
	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"
	stand_alone: true		stand_alone: true
	v: 3		v: 3
	obsoletes: 7996		obsoletes: 7996
	ipr: trust200902		ipr: trust200902
	kw: Internet-Draft
	cat: info		cat: info
	submissionType: editorial		submissionType: editorial
			date: 2025-12
	keyword:		keyword:
	- SVG		- SVG
	author:		author:
	-		-
	ins: A. Rossi		ins: A. Rossi
	name: Alexis Rossi		name: Alexis Rossi
	organization: RFC Series Consulting Editor		organization: RFC Series Consulting Editor
	email: rsce@rfc-editor.org		email: rsce@rfc-editor.org
	-		-
	ins: N. Brownlee		ins: N. Brownlee
	name: Nevil Brownlee		name: Nevil Brownlee
	organization:		organization:
	skipping to change at line 45 ¶		skipping to change at line 40 ¶
	email: jmahoney@staff.rfc-editor.org		email: jmahoney@staff.rfc-editor.org
	-		-
	ins: M. Thomson		ins: M. Thomson
	name: Martin Thomson		name: Martin Thomson
	organization:		organization:
	email: mt@lowentropy.net		email: mt@lowentropy.net
	normative:		normative:
	informative:		informative:
			RFC9720:
	RFC7996:		RFC7996:
	SVG:		SVG:
	author:		author:
	org: W3C		org: W3C
	title: Scalable Vector Graphics		title: Scalable Vector Graphics (SVG) 2
	target: https://www.w3.org/TR/SVG/		target: https://www.w3.org/TR/SVG/
			date: false
	WAI:		WAI:
	author:		author:
	org: W3C		org: W3C
	title: W3C Accessibility Standards Overview		title: W3C Accessibility Standards Overview
	target: https://www.w3.org/WAI/standards-guidelines/		target: https://www.w3.org/WAI/standards-guidelines/
			date: false
	--- abstract		--- abstract
	This document sets policy for the inclusion of SVGs in the definitive versions of RFC		This document defines policy for the inclusion of Scalable Vector Graphics (SVGs) in
	s and relevant publication formats. It contains policy requirements from RFC 7996 and		the definitive versions of RFCs and relevant publication formats. It contains policy
	removes all requirements related to using a specific SVG profile or specific impleme		requirements from RFC 7996 but removes all requirements related to using a specific S
	ntation code. It also makes the RFC Publication Center (RPC) responsible for implemen		VG profile or implementation code. It also makes the RFC Production Center (RPC) resp
	tation decisions regarding SVGs.		onsible for decisions about SVG tooling and implementation.
			This document obsoletes RFC 7996.
	--- middle		--- middle
	# Introduction		# Introduction
	This document sets policy for the inclusion of SVGs (Scalable Vector Graphics) in the definitive versions of RFCs and relevant publication formats. It contains policy req uirements taken from {{RFC7996}} and removes all requirements related to using a spec ific SVG profile or specific implementation code.		This document defines policy for the inclusion of Scalable Vector Graphics (SVGs) in the definitive versions of RFCs and relevant publication formats defined in {{RFC9720 }}. It contains policy requirements taken from {{RFC7996}} but removes all requiremen ts related to using a specific 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 tooling and implementa tion decisions. They may want to use the content of {{RFC7996}} as a starting point f or those decisions, but they are not bound by {{RFC7996}} and they may change element s of the implementation as needed to support the RFC authoring community as long as t hose changes are aligned with the policy requirements in this document.		The RFC Production Center (RPC) is responsible for making decisions about SVG tooling and implementation. The RPC may use the content of {{RFC7996}} as a starting point f or those decisions, but they are not bound by {{RFC7996}}. In addition, the RPC may c hange 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		# Policy Requirements
	SVG tooling and implementation decisions are made or overseen by the RPC, and must ad here to the policy requirements in this document.		Decisions about SVG tooling and implementation are made 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 should not be the only representation of that concept. A good faith effort should be made to as sure that descriptions of concepts - which might include protocols, formats, or syste m architectures - are fully represented in the text of the RFC. At minimum, SVGs shou ld be consistent with the text.		* SVGs may be included in RFCs to help explain a concept more clearly, but they shoul d not be the only representation of that concept. A good-faith effort should be made to ensure that descriptions of concepts -- which might include protocols, formats, or system architectures -- are fully represented in the text of the RFC. At minimum, SV Gs should be consistent with the descriptions in the text of the RFC.
	* SVGs must not include animation or interactive features. SVGs should include only l imited reactive design elements (scaling, dark/light mode, and perhaps minor adjustme nts to allow for variations in display technology). The intent of this is to ensure t hat the diagram's meaning is not altered.		* SVGs must not include animation or interactive features. SVGs should include only l imited reactive design elements (scaling, dark/light mode, and perhaps minor adjustme nts to allow for variations in display technology). The intent of this is to ensure t hat the diagram's meaning is not altered.
	* Images and diagrams in RFCs should be successfully rendered and understood by the w idest audience possible. To that end, the RPC may prohibit the use of SVG features th at are known to lack support on common devices, that do not render on small or low-re solution screens, or that could make diagrams less comprehensible for any significant readership. This includes:		* Images and diagrams in RFCs should be successfully rendered and understood by the w idest audience possible. To that end, the RPC may prohibit the use of SVG features th at are known to lack support on common devices, that do not render on small or low-re solution 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 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 disabilities, incl		* SVGs should be as accessible as possible to people with visual disabilities, incl
	uding those who have color blindness, those who need to scale or change fonts, and th		uding those who have color blindness, those who need to scale or change fonts, and th
	ose who use screen reading software. The RPC will refer to the W3C Accessibility Guid		ose who use screen-reading software. The RPC will refer to the W3C Accessibility Guid
	elines {{WAI}} when making decisions regarding accessibility.		elines {{WAI}} when making decisions regarding accessibility.
	* Authors may include multiple versions of images or diagrams in rfcxml. Publication		* Authors may include multiple versions of images or diagrams in RFCXML {{RFC9720}}.
	formats should present the versions best suited to each format. In many cases, that		Publication formats should present the versions best suited to each format. In many
	will be an SVG.		cases, that will be an SVG.
	* SVG vocabulary and implementation may change over time. Changes are not required to		* SVG vocabulary and implementation may change over time. Changes are not required to
	remain backwards-compatible, although maintaining compatibility where possible is en		remain backwards compatible, although maintaining compatibility where possible is en
	couraged.		couraged.
	The RPC is authorized to place constraints on SVG usage in RFCs for both technical an d editorial reasons		The RPC is authorized to place constraints on SVG usage in RFCs for both technical an d editorial reasons
	in order to ensure that published RFCs meet the above policy		in order to ensure that published RFCs meet the above policy
	and to provide consistency across the RFC series.		and to provide consistency across the RFC Series.
	The RPC must document the acceptable usage of SVGs, and all changes to tooling or imp		The RPC must document the acceptable usage of SVGs, and all changes to decisions abou
	lementation decisions must be widely communicated to the RFC author community using m		t SVG tooling and implementation must be widely communicated to the RFC author commun
	ailing lists or other means.		ity using mailing lists or other means.
	# Implementation Guidance		# Implementation Guidance
	The RPC is expected to solicit community input before making decisions and to publicl y explain their reasoning.		The RPC is expected to solicit community input before making decisions and to publicl y explain their reasoning.
	Documentation produced by the RPC should describe what technical and editorial constr		Documentation produced by the RPC should describe the technical and editorial constra
	aints apply to SVGs		ints that apply to SVGs
	and provide RFC authors with guidance on how to produce diagrams that meet these cons		and provide RFC authors with guidance on how to produce diagrams that meet those cons
	traints.		traints.
	The RPC's implementation should strive to allow SVGs produced by widely used drawing tools.		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 disallowe d, rather than attempting to specify exactly what is allowed.		Where possible, implementation decisions should focus on specifying what is disallowe d rather than 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.
	# Security Considerations		# Security Considerations
	This document has no security considerations.		This document has no security considerations.
	# IANA Considerations		# IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
End of changes. 19 change blocks.
	39 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48.