Hello all,
An updated markdown file incorporating suggestions is attached.
For coauthors and RSAB shepherd, this commit highlights the changes:
https://github.com/alexisannerossi/id-svgsinrfcs/commit/17cd7552f6da4f3573af9bb810820863ac9ea07c
Thanks,
Alexis
On Mon, Nov 17, 2025 at 10:46 PM <[email protected]> wrote:
> *****IMPORTANT*****
>
> Updated 2025/11/17
>
> RFC Author(s):
>
> Your document has now entered AUTH48.
>
> The document was edited in kramdown-rfc as part of the RPC pilot test (see
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
>
> Please review the procedures for AUTH48 using kramdown-rfc:
>
>
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
>
> Once your document has completed AUTH48, it will be published as
> an RFC.
>
>
> Files
> -----
>
> The files are available here:
> https://www.rfc-editor.org/authors/rfc9896.md
> https://www.rfc-editor.org/authors/rfc9896.html
> https://www.rfc-editor.org/authors/rfc9896.pdf
> https://www.rfc-editor.org/authors/rfc9896.txt
>
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9896-diff.html
> https://www.rfc-editor.org/authors/rfc9896-rfcdiff.html (side by side)
>
> Diff of the kramdown:
> https://www.rfc-editor.org/authors/rfc9896-md-diff.html
> https://www.rfc-editor.org/authors/rfc9896-md-rfcdiff.html (side by
> side)
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9896
>
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
---
title: SVGs in RFCs
docname: draft-editorial-rswg-svgsinrfcs-04
number: 9896
stand_alone: true
v: 3
obsoletes: 7996
ipr: trust200902
cat: info
submissionType: editorial
date: 2025-11
keyword:
- SVG
author:
-
ins: A. Rossi
name: Alexis Rossi
organization: RFC Series Consulting Editor
email: [email protected]
-
ins: N. Brownlee
name: Nevil Brownlee
organization:
email: [email protected]
-
ins: J. Mahoney
name: Jean Mahoney
organization: RFC Production Center
email: [email protected]
-
ins: M. Thomson
name: Martin Thomson
organization:
email: [email protected]
normative:
informative:
RFC9720:
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
This document defines policy for the inclusion of SVGs (Scalable Vector Graphics) in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from RFC 7996 but removes all requirements related to using a specific SVG profile or implementation code. It also makes the RFC Production Center (RPC) responsible for decisions about SVG tooling and implementation.
This document obsoletes RFC 7996.
--- middle
# Introduction
This document sets 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 requirements related to using a specific SVG profile or implementation code.
SVG has been developed by the World Wide Web Consortium (W3C); see {{SVG}}.
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 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 community as long as those changes are aligned with the policy requirements in this document.
# Policy Requirements
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 they should 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, SVGs should be consistent with the 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. 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, including those who have color blindness, those who need to scale or change fonts, and those who use 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 {{RFC9720}}. 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, 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.
The RPC must document the acceptable usage of SVGs, and all changes to decisions about SVG tooling and implementation 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 the technical and editorial constraints that apply to SVGs
and provide RFC authors with guidance on how to produce diagrams that meet 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 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
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
