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-11
	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 49 ¶		skipping to change at line 44 ¶
	organization:		organization:
	email: mt@lowentropy.net		email: mt@lowentropy.net
	normative:		normative:
	informative:		informative:
	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		<!-- [rfced] Abstract
	s and relevant publication formats. It contains policy requirements from RFC 7996 and
	removes all requirements related to using a specific SVG profile or specific impleme		a) The Abstract does not explicitly mention that this document obsoletes RFC
	ntation code. It also makes the RFC Publication Center (RPC) responsible for implemen		7996. See the checklist in the "Abstract" section of
	tation decisions regarding SVGs.		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 RFC
			s and relevant publication formats. It contains policy requirements from RFC 7996 but
			removes all requirements related to using a specific SVG profile or implementation c
			ode. It also makes the RFC Publication Center (RPC) responsible for implementation de
			cisions regarding SVGs.
	--- 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 sets policy for the inclusion of Scalable Vector Graphics (SVGs) in the definitive versions of RFCs and relevant publication formats. It contains policy req uirements taken from {{RFC7996}} but removes all requirements related to using a spec ific 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 Publication Center (RPC) is responsible for making decisions about SVG toolin g and implementation. The RPC may use the content of {{RFC7996}} as a starting point for those decisions, but they are not bound by {{RFC7996}}. In addition, the RPC may change elements of the implementation as needed to support the RFC authoring communit y 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		<!-- [rfced] Section 2: In the text below, how may we update "This includes"?
	here to the policy requirements in this document.		It is not clear what "This" refers to.
	* SVGs may be included in RFCs to help explain a concept more clearly, but should not		Original:
	be the only representation of that concept. A good faith effort should be made to as		* Images and diagrams in RFCs should be successfully rendered and
	sure that descriptions of concepts - which might include protocols, formats, or syste		understood by the widest audience possible. To that end, the RPC
	m architectures - are fully represented in the text of the RFC. At minimum, SVGs shou		may prohibit the use of SVG features that are known to lack
	ld be consistent with the text.		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 mu
			st adhere to the policy requirements in this document:
			* 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. 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 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. Publication
	formats should present the versions best suited to each format. In many cases, that		formats should present the versions best suited to each format. In many cases, that
	will be an SVG.		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.
	--- back		--- 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.
			-->
End of changes. 18 change blocks.
	43 lines changed or deleted		162 lines changed or added
This html diff was produced by rfcdiff 1.48.