Known issues with the IETF SVG profile

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 https://datatracker.ietf.org/drafts/current/.¶

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.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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!¶

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'

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'

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

4. IANA Considerations

None.¶

5. Security Considerations

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

Appendix A. Change Log

Appendix B. Acknowledgements

TBD¶

Authors' Addresses