idnits 2.17.1 draft-fossati-svg-test-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (10 March 2020) is 1509 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None T. Fossati 3 Internet-Draft 10 March 2020 4 Intended status: Experimental 5 Expires: 11 September 2020 7 SVG Tests 8 draft-fossati-svg-test-01 10 Abstract 12 This memo is for experimenting with SVG in the context of RFC 13 production. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 11 September 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Conventions used in this document . . . . . . . . . . . . 2 50 2. Code Layout . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. From ASCII art to SVG . . . . . . . . . . . . . . . . . . . . 3 52 4. Building the XML . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5.1. A Sequence Diagram . . . . . . . . . . . . . . . . . . . 4 55 5.2. Lots of Boxes and Arrows . . . . . . . . . . . . . . . . 5 56 5.3. Even More Boxes and Numbered Arrows . . . . . . . . . . . 6 57 5.4. And Another One . . . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 This memo is for experimenting with SVG in the context of RFC 67 production. 69 This document assumes a kramdown-rfc2629 based editing flow. 71 1.1. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 75 "OPTIONAL" in this document are to be interpreted as described in 76 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 77 capitals, as shown here. 79 2. Code Layout 81 The code is structured as follows: 83 ├── Makefile 84 ├── art 85 │ ├── cdni-delegation.ascii-art 86 │ ├── cdni-dns-redirection.ascii-art 87 │ ├── e2e-flow.ascii-art 88 │ ├── stir-delegation.ascii-art 89 │ └── stir-delegation.svg 90 └── draft-fossati-svg-test.md 92 In particular, the art directory contains the diagrams in ASCII art. 94 3. From ASCII art to SVG 96 The Makefile contains bunch of variables and a pattern rule to deal 97 with automatic generation of SVG from ASCII using a Golang tool 98 called goat. Another tool, svgcheck, is used to make sure xml2rfc 99 will like the SVG. 101 # The "art" variables: 103 art_src := $(wildcard $(art_dir)/*.ascii-art) 104 art_svg := $(art_src:.ascii-art=.svg) 106 # The pattern rule used to transform each and every ASCII 107 # art into SVG: 109 %.svg: %.ascii-art 110 @$(goat) $< | $(svgcheck) -r -o $@ 2>/dev/null || true 112 To install goat and svgcheck, do: 114 $ go get github.com/blampe/goat 115 $ pip install svgcheck 117 4. Building the XML 119 The Submit tool on the Datatracker wants the submitted XML to be self 120 contained. 122 To inline the diagrams you need to do the following: 124 $ kramdown-rfc2629 --v3 \ 125 draft-fossati-svg-test.md > draft-fossati-svg-test.xml 126 $ xml2rfc --v3 --preptool draft-fossati-svg-test.xml 127 $ xml2rfc --v3 --expand draft-fossati-svg-test.prepped.xml 128 $ mv draft-fossati-svg-test.prepped.exp.xml \ 129 draft-fossati-svg-test.xml 130 $ rm -f draft-fossati-svg-test.prepped.xml 132 The "prepped" and "expanded" draft-fossati-svg-test.xml inlines both 133 the ASCII and the SVG in the artset and is ready for submission. 135 Of course, from there you can also do the usual TXT / HTML 136 generation: 138 $ xml2rfc --v3 draft-fossati-svg-test.xml \ 139 draft-fossati-svg-test.txt 140 $ xml2rfc --v3 --html draft-fossati-svg-test.xml \ 141 draft-fossati-svg-test.html 143 5. Examples 145 5.1. A Sequence Diagram 147 kramdown does not support artset natively. So the artset must be 148 inserted using native xml2rfc syntax. The SVG is included in artwork 149 as a local file. The SVG file is created from its ASCII art 150 equivalent as explained in Section 3. 152 153
155 156 158 160 161
162 164 The result is shown in Figure 1. 166 .------. .---------------. .------. 167 | NDC | | IdO | | CA | 168 +--------+ +--------+--------+ +--------+ 169 | Client | | Server | Client | | Server | 170 '---+----' '----+---+---+----' '----+---' 171 | | | | 172 | Order | | | 173 | Signature | | | 174 o------------------->| | | 175 | | | | 176 | [ No identity ] | | | 177 | [ validation ] | | | 178 | | | | 179 | CSR | | | 180 | Signature | | | 181 o------------------->| | | 182 | Acknowledgement | | Order' | 183 |<-------------------o | Signature | 184 | | o------------------->| 185 | | | Required | 186 | | | Authorizations | 187 | | |<-------------------o 188 | | | Responses | 189 | | | Signature | 190 | | o------------------->| 191 | | | | 192 | | |<~~~~Validation~~~~>| 193 | | | | 194 | | | CSR | 195 | | | Signature | 196 | | o------------------->| 197 | | | Acknowledgement | 198 | | |<-------------------o 199 | | | | 200 |<~~Await issuance~->| |<~~Await issuance~~>| 201 | | 202 | (unauthenticated) GET STAR certificate | 203 o------------------------------------------------>| 204 | Certificate #1 | 205 |<------------------------------------------------o 206 | (unauthenticated) GET STAR certificate | 207 o------------------------------------------------>| 208 | Certificate #2 | 209 |<------------------------------------------------o 210 | [...] | 211 | (unauthenticated) GET STAR certificate | 212 o------------------------------------------------>| 213 | Certificate #n | 214 |<------------------------------------------------o 216 Figure 1: End to end STAR delegation flow 218 5.2. Lots of Boxes and Arrows 220 221
223 224 226 228 229
230 231 .------------. 232 video.cp.example ? | .-----. | 233 .---------------------------------->| | | 234 | (a) | | DNS | CP | 235 | .-------------------------------+ | | 236 | | CNAME video.ucdn.example | '-----' | 237 | | '------------' 238 | | 239 | | 240 .-----------|---v--. .------------. 241 | .-----.-+-----. | video.ucdn.example ? | .-----. | 242 | | | +----------------------------->| | | 243 | UA | TLS | DNS | | (b) | | DNS | uCDN | 244 | | | |<-----------------------------+ | | 245 | '--+--'-----+-' | CNAME video.dcdn.example | '-----' | 246 '------|----^---|--' '------------' 247 | | | 248 | | | 249 | | | .------------. 250 | | | video.dcdn.example ? | .-----. | 251 | | '------------------------------>| | | 252 | | (c) | | DNS | | 253 | '-----------------------------------+ | | 254 | A 192.0.2.1 | +-----+ dCDN | 255 | | | | | 256 '--------------------------------------->| TLS | | 257 SNI: video.cp.example | | | | 258 | '-----' | 259 '------------' 261 Figure 2: DNS Redirection 263 5.3. Even More Boxes and Numbered Arrows 265 266
268 269 271 273 274
275 276 .--------------------. 277 | .------.------. | 278 | | STAR | ACME |<-------------. 279 .------->| CP | dele | STAR | | | 280 | | | srv | cli +-----. | 281 | | '---+--'------' | | 6 282 | '---------|------^---' 5 | 283 | | | | .--|-------. 284 | | | | | .-+----. | 285 | 7 | '---->| ACME | | 286 | | | | | STAR | C | 287 0 | 4 | +------| A | 288 | | | | | HTTP | | 289 | | | | '----+-' | 290 | | .-' '--^--|----' 291 | .--------------v--|--. | | 292 | | .------.----+-. | | 10 293 | | | | STAR | | | | 294 '-->| uCDN | CDNI | dele | | | | 295 | | | fwd | | | | 296 | '----+-'-+----' | | | 297 '-------^--|---|--^--' | | 298 | | | | | | 299 | 2 8 | | | 300 1 | | 3 | | 301 | | | | 9 | 302 .-------|--v---v--|---------. | | 303 | .-+----.----+-.------. | | | 304 | | | STAR | +------------' | 305 | dCDN | CDNI | dele | HTTP | | | 306 | | | cli | |<--------------' 307 | '------'------'------' | 308 '---------------------------' 310 Figure 3: Two levels delegation in CDNI 312 5.4. And Another One 313 314
316 317 319 321 322
323 325 .-------------------. 326 | .------.------. | 327 | | STAR | STAR |<--------------. 328 .-->| SP1 | dele | dele | | | 329 | | | srv | cli +-----. | 330 | | '----+-'------' | | 4 331 | '------^--|---------' 3 | 332 | | | | .----|-----. 333 | | 5 | | .---+--. | 334 | | | '--->| ACME | | 335 | | | | | STAR | C | 336 1 | | | +------| A | 337 | | | .--->| HTTP | | 338 | 2 | | | '---+--' | 339 | | | | '----|-----' 340 | .------|--v---------. 6 | 341 | | .-+----.------. | | 7 342 | | | STAR | +-----' | 343 '-->| SP2 | dele | HTTP | | | 344 | | cli | |<--------------' 345 | '----+-'-+----' | 346 '-------------------' 348 Figure 4: Delegation in STIR 350 6. IANA Considerations 352 No requests are made to IANA. 354 7. Security Considerations 356 There are none. 358 8. Acknowledgments 360 Yaron for pointing out the current limitations in the tooling and 361 providing the workaround. 363 9. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 371 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 372 May 2017, . 374 Author's Address 376 Thomas Fossati 378 Email: thomas.fossati@arm.com