| rfc9896.txt | rfc9896_prop.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 | |||
| December 2025 | December 2025 | |||
| SVGs in RFCs | SVG in RFCs | |||
| Abstract | Abstract | |||
| This document defines 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 from RFC 7996 | publication formats. It contains policy requirements from RFC 7996 | |||
| but removes all requirements related to using a specific SVG profile | but removes all requirements related to using a specific SVG profile | |||
| or implementation code. It also makes the RFC Production Center | or implementation code. It also makes the RFC Production Center | |||
| (RPC) responsible for decisions about SVG tooling and implementation. | (RPC) responsible for decisions about SVG tooling and implementation. | |||
| This document obsoletes RFC 7996. | 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 | |||
| skipping to change at line 64 ¶ | skipping to change at line 64 ¶ | |||
| 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 defines 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 defined in [RFC9720]. It contains policy | publication formats defined in [RFC9720]. It contains policy | |||
| requirements taken from [RFC7996] but removes all requirements | requirements taken from [RFC7996] but removes all requirements | |||
| related to using a specific 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 by the RPC | Decisions about SVG tooling and implementation are made by the RPC | |||
| and must adhere to the policy requirements in this document: | and must adhere to the policy requirements in this 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. In particular: | 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 [RFC9720]. Publication formats should present the versions | RFCXML [RFC9720]. Publication formats should present the versions | |||
| best 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. | |||
| End of changes. 12 change blocks. | ||||
| 25 lines changed or deleted | 26 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||