SVG Teststhomas.fossati@arm.com
Security
NoneInternet-DraftThis memo is for experimenting with SVG in the context of RFC production.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 11 September 2020.
Copyright Notice
Copyright (c) 2020 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
() 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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Conventions used in this document
. Code Layout
. From ASCII art to SVG
. Building the XML
. Examples
. A Sequence Diagram
. Lots of Boxes and Arrows
. Even More Boxes and Numbered Arrows
. And Another One
. IANA Considerations
. Security Considerations
. Acknowledgments
. Normative References
Author's Address
IntroductionThis memo is for experimenting with SVG in the context of RFC production.This document assumes a kramdown-rfc2629 based editing flow.Conventions used in this documentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.Code LayoutThe code is structured as follows:In particular, the art directory contains the diagrams in ASCII art.From ASCII art to SVGThe Makefile contains bunch of variables and a pattern rule to deal with
automatic generation of SVG from ASCII using a Golang tool called goat.
Another tool, svgcheck, is used to make sure xml2rfc will like the SVG./dev/null || true
]]>To install goat and svgcheck, do:Building the XMLThe Submit tool on the Datatracker wants the submitted XML to be self
contained.To inline the diagrams you need to do the following: draft-fossati-svg-test.xml
$ xml2rfc --v3 --preptool draft-fossati-svg-test.xml
$ xml2rfc --v3 --expand draft-fossati-svg-test.prepped.xml
$ mv draft-fossati-svg-test.prepped.exp.xml \
draft-fossati-svg-test.xml
$ rm -f draft-fossati-svg-test.prepped.xml
]]>The "prepped" and "expanded" draft-fossati-svg-test.xml inlines both the ASCII
and the SVG in the artset and is ready for submission.Of course, from there you can also do the usual TXT / HTML generation:ExamplesA Sequence Diagramkramdown does not support artset natively. So the artset must be inserted
using native xml2rfc syntax. The SVG is included in artwork as a local file.
The SVG file is created from its ASCII art equivalent as explained in
.
]]>The result is shown in .Lots of Boxes and Arrows
]]>Even More Boxes and Numbered Arrows
]]>And Another One
]]>IANA ConsiderationsNo requests are made to IANA.Security ConsiderationsThere are none.AcknowledgmentsYaron for pointing out the current limitations in the tooling and providing the
workaround.Normative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Author's Addressthomas.fossati@arm.com