idnits 2.17.1 draft-brownlee-svg-rfc-10.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 161 has weird spacing: '...he list below...' == Line 162 has weird spacing: '...eft,and their...' == Line 165 has weird spacing: '...bset of the S...' -- The document date (August 14, 2015) is 3177 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SVG' is mentioned on line 78, but not defined Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Brownlee 3 Internet-Draft The University of Auckland 4 Intended status: Informational IAB 5 Expires: February 15, 2016 August 14, 2015 7 SVG Drawings for RFCs: SVG 1.2 RFC 8 draft-brownlee-svg-rfc-10 10 Abstract 12 This document specifies SVG 1.2 RFC - an SVG profile for use in 13 diagrams that may appear in RFCs - and considers some of the issues 14 concerning the creation and use of such diagrams. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 15, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. SVG 1.2 RFC: An SVG profile for RFCs . . . . . . . . . . . . 3 52 2.1. Elements, properties and attributes allowed in SVG 1.2 53 RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. How to create SVG drawings . . . . . . . . . . . . . . . . . 6 55 4. Accessibility Considerations . . . . . . . . . . . . . . . . 7 56 5. Meta-language for diagrams common in RFCs . . . . . . . . . . 7 57 5.1. Packet Layout Diagrams . . . . . . . . . . . . . . . . . 7 58 5.2. Sequence Diagrams (1) . . . . . . . . . . . . . . . . . . 8 59 5.3. Sequence Diagrams (2) . . . . . . . . . . . . . . . . . . 10 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 62 8. Revision History [RFC Editor please delete] . . . . . . . . . 13 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 65 9.2. Informative References . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 68 1. Introduction 70 Over the last two years the RFC Editor has worked with the Internet 71 community to develop specifications for changes in the format of 72 RFCs. An outline of the resulting specifications was published as 73 [RFC6949] in May 2013. Since then a Design Team has been working 74 with the RFC Editor to flesh out those specifications. One aspect of 75 the changes is to allow line drawings in RFCs; [RFC6949] says 77 "Graphics may include ASCII art and a more complex form to be 78 defined, such as SVG line art [SVG]. Color and grayscale will not 79 be accepted. RFCs must correctly display in monochromatic black- 80 and-white to allow for monochrome displays, black-and- white 81 printing, and support for visual disabilities." 83 SVG (Scalable Vector Graphics) has been developed by W3C, the World 84 Wide Web Consortium; its current standard is SVG 1.1 Full 85 [W3C.REC-SVG11-20110816]. This document defines SVG 1.2 RFC, an SVG 86 profile (i.e. a subset of SVG) that is suitable for RFC line 87 drawings. 89 Note that in RFCs, the text provides normative descriptions of 90 protocols, systems, etc. Diagrams may be used to help explain 91 concepts more clearly, but they provide supporting detail, and should 92 not be considered to be complete specifications in themselves. 94 The details (particularly any vocabularies) described in this 95 document are expected to change based on experience gained in 96 implementing the RFC production center's toolset. Revised documents 97 will be published capturing those changes as the toolset is 98 completed. Other implementers must not expect those changes to 99 remain backwards-compatible with the details described this document. 101 2. SVG 1.2 RFC: An SVG profile for RFCs 103 As a starting point for SVG 1.2 RFC, the Design Team decided to use 104 SVG 1.2 Tiny [W3C.REC-SVGTiny12-20081222]. SVG 1.2 Tiny is an SVG 105 subset intended to be implemented on small, mobile devices such as 106 cellphones and smartphones. That should allow RFCs to be rendered 107 well on such devices, especially those that have small screens. 108 However, RFCs are self-contained documents that do not change once 109 they are published. The use of SVG drawings in RFCs is intended to 110 allow authors to create drawings that are simple to produce, and 111 easier to understand than our traditional 'ASCII Art' ones. In 112 short, we are also trying to improve access to the content in RFCs, 113 so SVG drawings need to be kept as simple as possible. 115 SVG can provide a complete User Interface, but within RFCs, all we 116 need are simple diagrams that do not change once the RFC is 117 published. Therefore, SVG RFC does not allow anything from the 118 following sections in SVG Tiny 1.2 [W3C.REC-SVGTiny12-20081222]: 120 12 Multimedia 121 13 Interactivity 122 15 Scripting 123 16 Animation 124 18 Metadata 125 19 Extensibility 127 Note that SVG Tiny 1.2 elements may have many properties or 128 attributes that are needed to support aspects of the above sections. 129 Those are not allowed in SVG 1.2 RFC. 131 Considering the other sections in SVG Tiny 1.2 132 [W3C.REC-SVGTiny12-20081222]: 134 9 Basic Shapes 135 10 Text 136 Everything in these sections is allowed in SVG 1.2 RFC. 138 11 Painting: Filling, Stroking, Colors and Paint Servers 139 Anything relating to 'color' is not allowed in SVG 1.2 RFC, 140 everything else is allowed. This is a requirement documented in 141 [RFC6949]. 143 14 Linking 144 SVG Tiny 1.2 allows internationalized IRIs in references. In 145 SVG 1.2 RFC such links must be ASCII only. That should not 146 cause problems, since one can just use the URI form of any IRI. 147 Authors should try to use links only to URIs that are long-term 148 stable. 150 17 Fonts 151 SVG 1.2 RFC only allows 'serif', 'sans-serif' and 'monospace' 152 generic font families from the WebFonts facility, described in 153 CSS 2.1, [W3C.REC-CSS2-20110607], section 15, Fonts. In 154 particular, the SVG 'font' element is not allowed. 156 2.1. Elements, properties and attributes allowed in SVG 1.2 RFC 158 Elements, properties and attributes selected for SVG 1.2 RFC from 159 [W3C.REC-SVGTiny12-20081222]. 161 In the list below, elements and properties are listed on the 162 left,and their allowed values are given in parentheses on the 163 right. 164 , the list of allowed colours, is a black-and-white 165 subset of the SVG colour names. 167 Elements: 169 svg (version, baseProfile=tiny, width, viewBox, 170 preserveAspectRatio, snapshotTime, height, 171 id, role) 172 g (id, role, transform, label,class) 173 defs (id, role) 174 title (id, role) 175 desc (id, role) 176 use (x, y, href, xlink:href, id, role, transform) 178 rect (x, y, width, height, rx, ry 179 id, role, transform, stroke-miterlimit) 180 circle (cx, cy, r, id, role, transform) 181 ellipse (cx, cy, rx, ry, id, role, transform) 182 line (x1, y1, x2, y2, id, role, transform) 183 polyline (points, id, role, transform) 184 polygon (points, id, role, transform) 186 text (x, y, rotate, id, role, transform) 187 tspan (id, role) 188 textArea (x, y, width, height, auto, id, role, transform) 189 tbreak (id, role) 190 solidColor (id, role) 191 linearGradient (gradientUnits, x1, y1, x2, y2, id, role) 192 radialGradient (gradientUnits, cx, cy, r, id, role) 193 stop (offset, id, role) 194 path (d, pathLength, id, role, transform, stroke-miterlimit) 196 Properties: (most allow inherit as a value) 198 stroke 199 stroke-width 200 stroke-linecap (butt, round, square) 201 stroke-linejoin (miter, round, bevel) 202 stroke-mitrelimit 203 stroke-dasharray 204 stroke-dashoffset 205 stroke-opacity 206 vector-effect (non-scaling-stroke, none) 207 viewport-fill (none, currentColor) 208 viewport-fill-opacity 210 display (inline, block, list-item, run-in, compact, 211 marker, table, inline-table, table-row-group, 212 table-header-group, table-footer-group, 213 table-row, table-column-group, 214 table-column, table-cell, table-caption, 215 none) 216 visibility (visible, hidden, collapse) 217 color-rendering (auto, optimizeSpeed, optimizeQuality) 218 shape-rendering (auto, optimizeSpeed, crispEdges, 219 geometricPrecision) 220 text-rendering (auto, optimizeSpeed, optimizeLegibility, 221 geometricPrecision) 222 buffered-rendering (auto, dynamic, static) 224 (black, grey, darkgrey, dimgrey, lightgrey, 225 gray, darkgray, dimgray, lightgray, white) 226 opacity 227 solid-opacity 228 solid-color (currentColor, ) 229 color (currentColor, ) 231 stop-color (currentColor, ) 232 stop-opacity 234 line-increment (auto) 235 text-align (start,end, center) 236 display-align (auto, before, center, after) 237 font-size 238 font-family (serif, sans-serif, monospace) 239 font-weight (normal, bold, bolder, lighter) 240 font-style (normal, italic, oblique) 241 font-variant (normal, small-caps) 242 direction (ltr, rtl) 243 unicode-bidi (normal, embed, bidi-override) 244 text-anchor (start, middle, end) 245 fill (none, black or grey) 246 fill-rule (nonzero, evenodd) 247 fill-opacity 249 3. How to create SVG drawings 251 Many drawing packages can be used to create SVG drawings, for example 252 Open Source packages Inkscape and Dia. Be aware that such packages 253 may use SVG elements or attributes that are not allowed in SVG 1.2 254 RFC. 256 -For example, the 'marker' attribute is often used to place symbols 257 such as arrowheads on lines, but 'marker' is not allowed in SVG 1.2 258 Tiny or SVG 1.2 RFC. In such cases one has to draw the arrowhead in 259 another, simpler way. 261 -SVG clip paths are used to define a shape; objects outside that 262 shape become invisible. The 'clipPath' element is not allowed in 263 SVG 1.2 Tiny or SVG 1.2 RFC. 265 Diagrams produced with these packages may contain elements, their 266 attributes or properties, or values of attributes or properties that 267 are not allowed in SVG 1.2 RFC. We will need to provide a tool to 268 strip out anything that is not allowed in SVG 1.2 RFC, or to replace 269 disallowed values, e.g. 'sans-serif' for 'Sans' as values for 'font- 270 family'. Experience with a simple test version a tool for this has 271 shown that such deletion and replacement can be effective for making 272 SVG files from drawing packages conform to SVG 1.2 RFC, without 273 visibly changing the diagrams they produce. 275 The tool described above can also be used by Authors simply to check 276 that their diagrams conform to SVG 1.2 RFC. To help with this, if 277 visible changes do occur, the tool should produce a list of non- 278 allowed keywords and the context in which they were found. 280 Another way to create SVG drawings is to write programs to draw them. 281 For example, using python and its svgwrite module is a pleasant 282 environment (for those who like writing code). 284 To include a diagram into an RFC, the xml2rfc (v3) tool will need to 285 provide a way to include SVG drawings in Internet Drafts. 287 4. Accessibility Considerations 289 One of the long-term goals for RFCs is to make them more accessible, 290 e.g. to sight-impaired readers. For diagrams, it would be useful for 291 authors to provide alternative forms of the diagram, so that voice- 292 reading software could be used to 'talk through' the diagram. Simply 293 reading the SVG code for a complex diagram seems unlikely to work. 295 SVG 1.2 RFC allows SVG's 'title' and 'desc' elements. 'title' 296 provides a brief text caption for an SVG object (much like a figure 297 caption), and 'desc' provides a longer text description of what the 298 object actually represents. As well, the SVG 'role' attribute can be 299 used to indicate to a browser how an SVG object is to be interpreted. 300 Good suggestions on how to use these elements are given in 301 [SVG-ACCESS-TIPS]. 303 ARIA is a W3C Recommendation for using SVG to create 'Accessible Rich 304 Internet Applications.' A helpful introduction to ARIA is provided 305 by [SVG-ARIA-PRIMER], while [SVG-USING-ARIA] gives examples of how to 306 use ARIA to enhance SVG accessibility. 308 5. Meta-language for diagrams common in RFCs 310 This section presents a few examples of possible meta-languages which 311 could be used to create the kinds of diagrams that are most common in 312 RFCs. Note that they are merely examples, they do not imply that 313 these particular experimental languages might be more widely 314 implemented or used. Instead, they seem to show that designing meta- 315 languages simple enough to serve as audible representations of 316 complex diagrams is difficult indeed! 318 The SVG diagrams produced from the following examples can be seen at 319 https://www.cs.auckland.ac.nz/~nevil/SVG_RFC_1.2 320 along with an html version of this draft that includes the SVG 321 diagrams. 323 5.1. Packet Layout Diagrams 325 Example: Figure 3 from RFC 793. 327 In these examples the first line specifies the generated SVG 328 filename. The scale factor determines the size of the SVG drawing; 329 it needs to be set so that the drawing fits nicely into the final 330 document. 332 'packet;' starts the packet description; it's followed by a 333 description of the fields in each row. 335 info; 336 output "tcp-header.svg", scale 0.65; 338 packet; 339 row 0; 340 field "Source Port", 0 to 15; 341 field "Destination Port", 16 to 31; 342 row 1; 343 field "Sequence Number", 0 to 31; 344 row 2; 345 field "Acknowledgement Number", 0 to 31; 346 row 3; 347 field "Data Offset", 0 to 3; 348 field "Reserved", 4 to 9; 349 field "Urg", 10 to 10, fsize 14; # 14 px font so the flags fit 350 field "Ack", 11 to 11, fsize 14; 351 field "Psh", 12 to 12, fsize 14; 352 field "Rst", 13 to 13, fsize 14; 353 field "Syn", 14 to 14, fsize 14; 354 field "Fin", 15 to 15, fsize 14; 355 field "Window", 16 to 31; 356 row 4; 357 field "Checksum", 0 to 15; 358 field "Urgent Pointer", 16 to 31; 359 row 5; 360 field "Options", 0 to 23; 361 field "Padding", 24 to 31; 362 row 6; 363 field "Data", 0 to 31; 365 5.2. Sequence Diagrams (1) 367 Example: Figure 6 from draft-loreto-httpbis-trusted-proxy20-00. 369 In this example, columns are vertical lines with a text header above 370 them. There are three columns, and columns 1 and 2 are spaced 250 371 pixels apart. 373 The rest of the file describes objects to be drawn; most of them are 374 plines (polylines) from one column to another, but object 3 only 375 extends across to 0.3 of the distance between columns 1 and 2. 377 info; 378 output "httpbis-proxy20-fig6.svg", scale 0.9; 380 #Thu, 30 Jan 14 (NZDT) 382 #Figure 6 of draft-loreto-httpbis-trusted-proxy20-00.txt 384 column 1 width 250; # columns have vertical line to bottom 385 text above "user-agent"; 387 column 2 width 250; 388 text "Proxy"; 390 column 3; # Last col 391 text "Server"; 393 object 1; # Only need polylines 394 pline 1 to 2, arrowhead at end; 395 text above "(1) TLS ClientHello"; 396 text below "(ALPN ProtocolName: http)"; 398 object 2; 399 pline 1 to 2, arrowhead at start; 400 text above "(2) TLS Error"; 401 text below "(Proxy Cert)"; 403 object 3; 404 pline 1 to 1.3, down, back to 1, arrowhead at end; 405 text seg 2 centre "(inform user of the SecureProxy)"; 407 object 4; 408 pline 1 to 2, arrowhead at end; 409 text above "(3) TLS ClientHello"; 411 object 5; 412 pline 1 to 2, arrowhead at start; 413 text above "(4) ServerHello"; 415 object 6; 416 blank 1 to 2; 418 object 7; 419 block 1 to 2, objects 8 to 15, colour "grey"; 420 text above "HTTP2.0"; 422 object 8; 423 pline 1 to 2, arrowhead at end; 424 text seg 1 centre "(5) stream(X) GET"; 426 object 9; 427 pline 2 to 3, arrowhead at end; 428 text seg 1 above "(6) TLS ClientHello"; 430 object 10; 431 pline 2 to 3, arrowhead at start; 432 text seg 1 above "TLS ServerHello"; 434 object 11; 435 blank 2 to 3; 437 object 12; 438 block 2 to 3, objects 13 to 15, colour "grey"; 439 text seg 1 above "HTTP2.0"; 441 object 13; 442 pline 2 to 3, arrowhead at end; 443 text seg 1 centre "(7) stream(Z) GET"; 445 object 14; 446 pline 2 to 3, arrowhead at start; 447 text seg 1 centre "(8) stream(Z) 200 OK"; 449 object 15; 450 pline 1 to 2, arrowhead at start; 451 text seg 1 centre "(9) stream(X) 200 OK"; 453 5.3. Sequence Diagrams (2) 455 Example: Figure 3 from RFC 4321 457 This example uses (x,y) coordinates to specify points in in plines. 458 For these, the x units are columns and the y units are lines 459 (positive means 'down the diagram'). 461 both x and y may be absolute, e.g. 4.3, or relative, e.g. +1.5). 462 For the first point of a pline, relative means 'relative to the 463 starting point of the previous pline,' for other points in a pline it 464 means 'relative to the last point.' 466 Note that column 1 is drawn in white, i.e. nothing is drawn for it. 467 It's simply used to make a blank area where objects 8 and 9 can place 468 text. For both those objects a pline is used to specify the text's 469 position. 471 Last, the metalanguage allows simple macros, introduced by 'define 472 foo = '. These make it easier to re-use definitions, for example of 473 line types. 475 info; 476 output "rfc4321-fig3.svg", scale 0.9; 478 # Sat, 5 Apr 14 (NZDT) 480 #Figure 3 of RFC 4321 482 define hw = width 110; # Hop width 484 column 1 width 130, colour "white"; # No heading or vertical line 486 column 2 hw; text above "UAC"; 488 column 3 hw; text "P1"; 490 column 4 hw; text "P2"; 492 column 5 hw; text "P3"; 494 column 6 hw; text "UAS"; 496 define tgrey = colour "lightgrey" width 5; # Thick grey 497 define ahe = arrowhead at end; 499 object 1; 500 pline 1.8 501 to 2.3 tgrey, to (2.4,+0), to (2.6,+1.5), to (2.7,+0) ahe, 502 to 3.3 tgrey, to (3.4,+0), to (3.6,+1.5), to (3.7,+0) ahe, 503 to 4.3 tgrey, to (4.4,+0), to (4.6,+1.5), to (4.7,+0) ahe, 504 to 5.3 tgrey, to (5.4,+0), to (5.6,+1.5), to (5.7,+0) ahe, 505 to 6.3 tgrey; 507 object 2; 508 pline (1.8,+10) to 2.3 tgrey; 510 object 3; 511 pline (3.3,+2) 512 to 2.85 tgrey, to (2.7,+0) tgrey, 513 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 514 text seg 2 centre "408"; 516 object 4; 517 pline (4.3,+1.5) 518 to 3.9 tgrey, to (3.7,+0) tgrey, 519 to (3.5,+0), to (3.3,+1.5), to (3.1,+0) ahe, 520 to 2.9 tgrey, to (2.7,+0) tgrey, 521 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 522 text seg 2 centre "408"; 523 text seg 7 centre "408"; 525 object 5; 526 pline (5.3,+1.5) 527 to 4.9 tgrey, to (4.7,+0) tgrey, 528 to (4.5,+0), to (4.3,+1.5), to (4.1,+0) ahe, 529 to 3.9 tgrey, to (3.7,+0) tgrey, 530 to (3.5,+0), to (3.3,+1.5), to (3.1,+0) ahe, 531 to 2.9 tgrey, to (2.7,+0) tgrey, 532 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 533 text seg 2 centre "408"; 534 text seg 7 centre "408"; 535 text seg 12 centre "408"; 537 object 6; 538 pline (6.3,+1.5) 539 to 5.9 tgrey, to (5.7,+0) tgrey, 540 to (5.5,+0), to (5.3,+1.5), to (5.1,+0) ahe; 541 to 4.9 tgrey, to (4.7,+0) tgrey, 542 to (4.5,+0), to (4.3,+1.5), to (4.1,+0) ahe; 543 to 3.9 tgrey, to (3.7,+0) tgrey, 544 to (3.5,+0), to (3.3,+1.5), to (3.1,+0) ahe; 545 to 2.9 tgrey, to (2.7,+0) tgrey, 546 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 547 text seg 2 centre "408"; 548 text seg 7 centre "408"; 549 text seg 12 centre "408"; 550 text seg 17 centre "408"; 552 object 7: 553 pline (1.63,4.1) to (1.73,+0); 555 object 8; 556 pline (1.68,4.1) to (+0,14) arrowhead at end; 557 text centre "64*T1"; 559 object 9; 560 pline (1.2,13.1) to (1.5,+0) colour "white"; 561 text centre "(timeout)"; 563 6. IANA Considerations 565 This document does not create a new registry nor does it register any 566 values in existing registries; no IANA action is required. 568 7. Acknowledgements 570 Thanks to the RSE and the Design Team members for their helpful 571 comments and suggestions for SVG 1.2 RFC. 573 8. Revision History [RFC Editor please delete] 575 version -10,14 Aug 15: 576 Section 1: Added "Details are expected to change" paragraph. 578 version -09, 31 Mar 15: 579 No changes, version number incremented to keep draft alive 581 version -08, 29 Sep 14: 582 Section 1: Changed comment about diagrams 'not being normative' to 583 'not complete specifications in themselves. 584 Section 2.1: Added SVG 1.2 Tiny 'id' attribute because most 585 drawing packages use it in constructing drawings. 586 Section 2.1: Added SVG 1.2 Tiny 'role' attribute so that ARIA can 587 use it. 588 Section 3: added comment about changes to xml2rfc required to 589 include SVG diagrams. 590 Section 4: Added reference to svg-aria-primer. 592 version -07, 3 Jul 14: 593 Expanded text about Accessibility in 'how to create SVG drawings' 594 section into 'Accessibility Considerations section. Added two SVG 595 Accessibility references to support that. 597 version -06, 26 Jun 14: 598 Remove trailing / from URL in section 4; the html version on 599 tools.ietf.org/html assumed the next word was part of that URL. 601 version -05, 25 Jun 14: 602 Improved section on 'how to create SVG drawings' By adding some 603 text about which elements aren't allowed in SVG 1.2 RFC. 604 Added more text describing the tool for checking, stripping out or 605 replacing incompatible elements and attributes from an SVG file. 607 version -04, 30 Apr 14: 608 Fixed typos, used full references for two of the w3c refs - each 609 had an author name using UTF8 characters. 610 Moved the Elements and Attributes appendix up earlier to make it 611 sub-section 2.1. 612 Disclaimer added to the Meta-languages section. 614 version -03, 14 Apr 14: 615 Added two more example diagrams; a simple packet layout, and a 616 diagram that uses lots of diagonal lines. 618 version -02, 12 Feb 14: 619 Added metalanguage example to make time-sequence drawings. 621 version -01, 11 Feb 14: 622 Allow links to 'long-term stable URIs' 623 Link URIs must be ASCII only 624 Need for tools to check SVG 1.2 RFC compatibility and to strip 625 'unnecessary' attributes explicitly stated. 626 Statement that drawings can't be normative removed; Postscript- 627 only RFCs already exist. 628 Added most attributes and elements to the Appendix. 630 version -00, 29 Jan 14: 631 Initial version, using content from Nevil's 632 emails to the Design Team. 634 9. References 636 9.1. Normative References 638 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 639 Requirements and Future Development", RFC 6949, 640 DOI 10.17487/RFC6949, May 2013, 641 . 643 [W3C.REC-SVGTiny12-20081222] 644 Andersson, O., Berjon, R., Dahlstrom, E., Emmons, A., 645 Ferraiolo, J., Grasso, A., Hardy, V., Hayman, S., Jackson, 646 D., Lilley, C., McCormack, C., Neumann, A., Northway, C., 647 Quint, A., Ramani, N., Schepers, D., and A. Shellshear, 648 "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", 649 World Wide Web Consortium Recommendation REC- 650 SVGTiny12-20081222, December 2008, 651 . 653 [W3C.REC-CSS2-20110607] 654 Bos, B., Celik, T., Hickson, I., and H. Lie, "Cascading 655 Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", 656 World Wide Web Consortium Recommendation REC- 657 CSS2-20110607, June 2011, 658 . 660 9.2. Informative References 662 [W3C.REC-SVG11-20110816] 663 Dahlstrom, E., Dengler, P., Grasso, A., Lilley, C., 664 McCormack, C., Schepers, D., Watt, J., Ferraiolo, J., 665 Fujisawa, J., and D. Jackson, "Scalable Vector Graphics 666 (SVG) 1.1 (Second Edition)", World Wide Web Consortium 667 Recommendation REC-SVG11-20110816, August 2011, 668 . 670 [SVG-ACCESS-TIPS] 671 Watson, L., "Tips for Creating Accessible SVG", SitePoint 672 tips-accessible-svg, May 2014, 673 . 675 [SVG-ARIA-PRIMER] 676 Pappas, L., Schwerdtfeger, R., and M. Cooper, "WAI-ARIA 677 1.0 Primer", World Wide Web Consortium WD WD-wai-aria- 678 primer-20100916, September 2010, 679 . 681 [SVG-USING-ARIA] 682 Watson, L., "Using ARIA to enhance SVG accessibility", The 683 Paciello Group 2013/12/using-aria-enhance-svg- 684 accessibility, December 2013, 685 . 688 Authors' Addresses 690 Nevil Brownlee 691 The University of Auckland 693 Email: n.brownlee@auckland.ac.nz 695 Internet Architecture Board 697 Email: iab@iab.org