]> The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand nevil.brownlee@gmail.com

RSWG Internet-Draft 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.

Introduction The latest version of the XML2RFC format for preparing RFCs relies on embedding diagrams in a particular subset of SVG defined in . 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 authors will be pleased to incorporate brief descriptions of additional issues.

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

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!

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: There's also some makework in the IETF toolchain: And some things that we will always need:

IANA Considerations None.

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

Informative References This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.

Change Log

Draft-00

• Original version

Acknowledgements TBD