Internet-Draft IETF SVG profile issues September 2022
Carpenter & Brownlee Expires 10 March 2023 [Page]
Intended Status:
B. E. Carpenter
Univ. of Auckland
J. N. Brownlee
Univ. of Auckland

Known issues with the IETF SVG profile


This document lists a number of issues observed in practice by authors attempting to include SVG diagrams in RFCs following the profile established by RFC7996.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 10 March 2023.

Table of Contents

1. Introduction

The latest version of the XML2RFC format for preparing RFCs relies on embedding diagrams in a particular subset of SVG defined in [RFC7996]. The great advantage of SVG is that it is intrinsically XML and therefore is a natural fit for XML2RFC in the way that no bitmap graphical format can be. Discussion of that basic choice is out of scope for this document.

A number of RFCs including such diagrams have been successfully published, but their authors have encountered various issues in doing so. This document's only purpose is to describe those issues. Any attempt to resolve them is out of scope for this document, which is not expected to be published as an RFC. However, RFC 7996 itself observes that:

The details (particularly any vocabularies) described in this
document are expected to change based on experience gained in
implementing the new publication toolsets.  Revised documents will be
published capturing those changes...

The authors will be pleased to incorporate brief descriptions of additional issues.

2. Background

[RFC7996] specifies SVG 1.2 RFC, an SVG profile for use in diagrams that may appear in RFCs. It is in fact a subset of SVG 1.2 Tiny, itself a W3C subset of SVG 1. At the time that the RFC Editor chose this approach, it was a reasonable hope that "Tiny" would succeed in the market. This has not happened, and that is at the root of many of the issues listed below.

On the other hand, there are good reasons why the RFC Editor cannot allow just any arbitrary SVG construct in RFCs - for example, to satisfy accessibility concerns, to avoid external dependencies in RFCs, and to avoid potentially malicious embedded scripts.

3. List of Issues

These are in no particular order.

  1. Very few (possibly only one) drawing tools can intrinsically respect the RFC 7996 profile. Some simple drawing tools (e.g. dia) allow the user to more or less respect the profile. However, the most popular drawing tools are very far from being able to respect the profile, even if the author avoids colour and greyscale.
    The evidence here is anecdotal, and the details are tedious (see below for some examples). The result, however, is that a diagram produced as slideware for presentation and discussion cannot, in the large majority of cases, be converted into RFC 7996 format. An author is obliged to discover how to regenerate the diagram with a different tool capable of respecting the profile.
  2. RFC 7996 forbids any colour except black or white, and therefore also forbids greyscale. Some people object to this restriction and assert that accessibility does not require it.
  3. Some drawing utilities generate colour or greyscale automatically. While a heuristic tool could fix this up (changing lighter shades to white and darker shades to black), this is a limiting factor.
  4. Some drawing utilities generate internal URLs, which are harmless, but the profile disallows all URLs.
  5. Some drawing utilities generate scripts for no apparent reason. We'd certainly want to forbid these anyway.
  6. Some drawing utilities manage to transform text into separate letters, or even letters into graphics, resulting in very bloated files that render badly.
  7. The S in SVG stands for 'Scalable' but the normal combination of a 'viewbox' element with a 'height' and 'width' element breaks scaling in most browsers.
  8. The existing tool chain, in particular the svgcheck module, fixes up non-conforming SVG as best it can, but sometimes this has alarming results such as completely black boxes in a diagram. There's an example in the mail archive (you need to view the attachments).
  9. Authors who want to provide ASCII art alternatives struggle to find tools that can generate acceptable SVG from ASCII art, or vice versa.
  10. Some quite basic elements such as 'marker' (commonly generated for arrowheads) are not allowed by RFC7996.
  11. Please email your issue and it can go here!

3.1. Some tedious details

RFC 7996 doesn't like 'stroke="none"' and 'stroke:none', even though they seem to be harmless and are often present.

Colour is represented in various different ways and formats, depending on which drawing tool generated the SVG. So a heuristic to fix up colour has to deal with all of them.

There are a number of ways in which RFC 7996 dislikes quite straightforward constructs that all browsers (the consumers of these SVG files) support. Just to give a few essentially random examples:

The element 'style' is not allowed as a child of 'svg'
The element 'path' does not allow the attribute 'marker-end'
Style property 'fill' promoted to attribute
Style property 'stroke-opacity' promoted to attribute
Style property 'stroke-miterlimit' removed
The element 'foreignObject' is not allowed as a child of 'g'

There's also some makework in the IETF toolchain:

The attribute 'stroke' does not allow the value 'rgb(0,0,0)', replaced with 'black'
The attribute 'stroke' does not allow the value 'rgb(0%,0%,0%)', replaced with 'black'
The attribute 'font-family' does not allow the value 'Arial, sans-serif', replaced with 'sans-serif'

And some things that we will always need:

The element 'script' is not allowed as a child of 'svg'

4. IANA Considerations


5. Security Considerations

Any form of scripting should remain forbidden in the SVG included in any Internet Draft or RFC.

6. Informative References

Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", RFC 7996, DOI 10.17487/RFC7996, , <>.

Appendix A. Change Log

A.1. Draft-00

  • Original version

Appendix B. Acknowledgements


Authors' Addresses

Brian E. Carpenter
The University of Auckland
School of Computer Science
The University of Auckland
PB 92019
Auckland 1142
New Zealand
Nevil Brownlee
The University of Auckland
School of Computer Science
The University of Auckland
PB 92019
Auckland 1142
New Zealand