Internet DRAFT - draft-carpenter-rswg-rfc7996-issues

draft-carpenter-rswg-rfc7996-issues







RSWG                                                     B. E. Carpenter
Internet-Draft                                            J. N. Brownlee
Intended status: Informational                         Univ. of Auckland
Expires: 10 March 2023                                  6 September 2022


                 Known issues with the IETF SVG profile
                 draft-carpenter-rswg-rfc7996-issues-00

Abstract

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






Carpenter & Brownlee      Expires 10 March 2023                 [Page 1]

Internet-Draft           IETF SVG profile issues          September 2022


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  List of Issues  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Some tedious details  . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   5
     A.1.  Draft-00  . . . . . . . . . . . . . . . . . . . . . . . .   5
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

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.





Carpenter & Brownlee      Expires 10 March 2023                 [Page 2]

Internet-Draft           IETF SVG profile issues          September 2022


   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.






Carpenter & Brownlee      Expires 10 March 2023                 [Page 3]

Internet-Draft           IETF SVG profile issues          September 2022


   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
        (https://mailarchive.ietf.org/arch/msg/tools-discuss/
        StvU0GvMTwY0zEqt7I_cWLYcp_4) (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'






Carpenter & Brownlee      Expires 10 March 2023                 [Page 4]

Internet-Draft           IETF SVG profile issues          September 2022


4.  IANA Considerations

   None.

5.  Security Considerations

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

6.  Informative References

   [RFC7996]  Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
              RFC 7996, DOI 10.17487/RFC7996, December 2016,
              <https://www.rfc-editor.org/info/rfc7996>.

Appendix A.  Change Log

A.1.  Draft-00

   *  Original version

Appendix B.  Acknowledgements

   TBD

Authors' Addresses

   Brian E. Carpenter
   The University of Auckland
   School of Computer Science
   The University of Auckland
   PB 92019
   Auckland 1142
   New Zealand
   Email: brian.e.carpenter@gmail.com


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






Carpenter & Brownlee      Expires 10 March 2023                 [Page 5]