idnits 2.17.1 draft-brownlee-svg-rfc-11.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 162 has weird spacing: '...he list below...' == Line 163 has weird spacing: '...eft,and their...' == Line 166 has weird spacing: '...bset of the S...' -- The document date (August 17, 2015) is 3175 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 18, 2016 August 17, 2015 7 SVG Drawings for RFCs: SVG 1.2 RFC 8 draft-brownlee-svg-rfc-11 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 18, 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 in this 100 document. 102 2. SVG 1.2 RFC: An SVG profile for RFCs 104 As a starting point for SVG 1.2 RFC, the Design Team decided to use 105 SVG 1.2 Tiny [W3C.REC-SVGTiny12-20081222]. SVG 1.2 Tiny is an SVG 106 subset intended to be implemented on small, mobile devices such as 107 cellphones and smartphones. That should allow RFCs to be rendered 108 well on such devices, especially those that have small screens. 109 However, RFCs are self-contained documents that do not change once 110 they are published. The use of SVG drawings in RFCs is intended to 111 allow authors to create drawings that are simple to produce, and 112 easier to understand than our traditional 'ASCII Art' ones. In 113 short, we are also trying to improve access to the content in RFCs, 114 so SVG drawings need to be kept as simple as possible. 116 SVG can provide a complete User Interface, but within RFCs, all we 117 need are simple diagrams that do not change once the RFC is 118 published. Therefore, SVG RFC does not allow anything from the 119 following sections in SVG Tiny 1.2 [W3C.REC-SVGTiny12-20081222]: 121 12 Multimedia 122 13 Interactivity 123 15 Scripting 124 16 Animation 125 18 Metadata 126 19 Extensibility 128 Note that SVG Tiny 1.2 elements may have many properties or 129 attributes that are needed to support aspects of the above sections. 130 Those are not allowed in SVG 1.2 RFC. 132 Considering the other sections in SVG Tiny 1.2 133 [W3C.REC-SVGTiny12-20081222]: 135 9 Basic Shapes 136 10 Text 137 Everything in these sections is allowed in SVG 1.2 RFC. 139 11 Painting: Filling, Stroking, Colors and Paint Servers 140 Anything relating to 'color' is not allowed in SVG 1.2 RFC, 141 everything else is allowed. This is a requirement documented in 142 [RFC6949]. 144 14 Linking 145 SVG Tiny 1.2 allows internationalized IRIs in references. In 146 SVG 1.2 RFC such links must be ASCII only. That should not 147 cause problems, since one can just use the URI form of any IRI. 148 Authors should try to use links only to URIs that are long-term 149 stable. 151 17 Fonts 152 SVG 1.2 RFC only allows 'serif', 'sans-serif' and 'monospace' 153 generic font families from the WebFonts facility, described in 154 CSS 2.1, [W3C.REC-CSS2-20110607], section 15, Fonts. In 155 particular, the SVG 'font' element is not allowed. 157 2.1. Elements, properties and attributes allowed in SVG 1.2 RFC 159 Elements, properties and attributes selected for SVG 1.2 RFC from 160 [W3C.REC-SVGTiny12-20081222]. 162 In the list below, elements and properties are listed on the 163 left,and their allowed values are given in parentheses on the 164 right. 165 , the list of allowed colours, is a black-and-white 166 subset of the SVG colour names. 168 Elements: 170 svg (version, baseProfile=tiny, width, viewBox, 171 preserveAspectRatio, snapshotTime, height, 172 id, role) 173 g (id, role, transform, label,class) 174 defs (id, role) 175 title (id, role) 176 desc (id, role) 177 use (x, y, href, xlink:href, id, role, transform) 179 rect (x, y, width, height, rx, ry 180 id, role, transform, stroke-miterlimit) 181 circle (cx, cy, r, id, role, transform) 182 ellipse (cx, cy, rx, ry, id, role, transform) 183 line (x1, y1, x2, y2, id, role, transform) 184 polyline (points, id, role, transform) 185 polygon (points, id, role, transform) 187 text (x, y, rotate, id, role, transform) 188 tspan (id, role) 189 textArea (x, y, width, height, auto, id, role, transform) 190 tbreak (id, role) 191 solidColor (id, role) 192 linearGradient (gradientUnits, x1, y1, x2, y2, id, role) 193 radialGradient (gradientUnits, cx, cy, r, id, role) 194 stop (offset, id, role) 195 path (d, pathLength, id, role, transform, stroke-miterlimit) 197 Properties: (most allow inherit as a value) 199 stroke 200 stroke-width 201 stroke-linecap (butt, round, square) 202 stroke-linejoin (miter, round, bevel) 203 stroke-mitrelimit 204 stroke-dasharray 205 stroke-dashoffset 206 stroke-opacity 207 vector-effect (non-scaling-stroke, none) 208 viewport-fill (none, currentColor) 209 viewport-fill-opacity 211 display (inline, block, list-item, run-in, compact, 212 marker, table, inline-table, table-row-group, 213 table-header-group, table-footer-group, 214 table-row, table-column-group, 215 table-column, table-cell, table-caption, 216 none) 217 visibility (visible, hidden, collapse) 218 color-rendering (auto, optimizeSpeed, optimizeQuality) 219 shape-rendering (auto, optimizeSpeed, crispEdges, 220 geometricPrecision) 221 text-rendering (auto, optimizeSpeed, optimizeLegibility, 222 geometricPrecision) 223 buffered-rendering (auto, dynamic, static) 225 (black, grey, darkgrey, dimgrey, lightgrey, 226 gray, darkgray, dimgray, lightgray, white) 227 opacity 228 solid-opacity 229 solid-color (currentColor, ) 230 color (currentColor, ) 232 stop-color (currentColor, ) 233 stop-opacity 235 line-increment (auto) 236 text-align (start,end, center) 237 display-align (auto, before, center, after) 238 font-size 239 font-family (serif, sans-serif, monospace) 240 font-weight (normal, bold, bolder, lighter) 241 font-style (normal, italic, oblique) 242 font-variant (normal, small-caps) 243 direction (ltr, rtl) 244 unicode-bidi (normal, embed, bidi-override) 245 text-anchor (start, middle, end) 246 fill (none, black or grey) 247 fill-rule (nonzero, evenodd) 248 fill-opacity 250 3. How to create SVG drawings 252 Many drawing packages can be used to create SVG drawings, for example 253 Open Source packages Inkscape and Dia. Be aware that such packages 254 may use SVG elements or attributes that are not allowed in SVG 1.2 255 RFC. 257 -For example, the 'marker' attribute is often used to place symbols 258 such as arrowheads on lines, but 'marker' is not allowed in SVG 1.2 259 Tiny or SVG 1.2 RFC. In such cases one has to draw the arrowhead in 260 another, simpler way. 262 -SVG clip paths are used to define a shape; objects outside that 263 shape become invisible. The 'clipPath' element is not allowed in 264 SVG 1.2 Tiny or SVG 1.2 RFC. 266 Diagrams produced with these packages may contain elements, their 267 attributes or properties, or values of attributes or properties that 268 are not allowed in SVG 1.2 RFC. We will need to provide a tool to 269 strip out anything that is not allowed in SVG 1.2 RFC, or to replace 270 disallowed values, e.g. 'sans-serif' for 'Sans' as values for 'font- 271 family'. Experience with a simple test version a tool for this has 272 shown that such deletion and replacement can be effective for making 273 SVG files from drawing packages conform to SVG 1.2 RFC, without 274 visibly changing the diagrams they produce. 276 The tool described above can also be used by Authors simply to check 277 that their diagrams conform to SVG 1.2 RFC. To help with this, if 278 visible changes do occur, the tool should produce a list of non- 279 allowed keywords and the context in which they were found. 281 Another way to create SVG drawings is to write programs to draw them. 282 For example, using python and its svgwrite module is a pleasant 283 environment (for those who like writing code). 285 To include a diagram into an RFC, the xml2rfc (v3) tool will need to 286 provide a way to include SVG drawings in Internet Drafts. 288 4. Accessibility Considerations 290 One of the long-term goals for RFCs is to make them more accessible, 291 e.g. to sight-impaired readers. For diagrams, it would be useful for 292 authors to provide alternative forms of the diagram, so that voice- 293 reading software could be used to 'talk through' the diagram. Simply 294 reading the SVG code for a complex diagram seems unlikely to work. 296 SVG 1.2 RFC allows SVG's 'title' and 'desc' elements. 'title' 297 provides a brief text caption for an SVG object (much like a figure 298 caption), and 'desc' provides a longer text description of what the 299 object actually represents. As well, the SVG 'role' attribute can be 300 used to indicate to a browser how an SVG object is to be interpreted. 301 Good suggestions on how to use these elements are given in 302 [SVG-ACCESS-TIPS]. 304 ARIA is a W3C Recommendation for using SVG to create 'Accessible Rich 305 Internet Applications.' A helpful introduction to ARIA is provided 306 by [SVG-ARIA-PRIMER], while [SVG-USING-ARIA] gives examples of how to 307 use ARIA to enhance SVG accessibility. 309 5. Meta-language for diagrams common in RFCs 311 This section presents a few examples of possible meta-languages which 312 could be used to create the kinds of diagrams that are most common in 313 RFCs. Note that they are merely examples, they do not imply that 314 these particular experimental languages might be more widely 315 implemented or used. Instead, they seem to show that designing meta- 316 languages simple enough to serve as audible representations of 317 complex diagrams is difficult indeed! 319 The SVG diagrams produced from the following examples can be seen at 320 https://www.cs.auckland.ac.nz/~nevil/SVG_RFC_1.2 321 along with an html version of this draft that includes the SVG 322 diagrams. 324 5.1. Packet Layout Diagrams 326 Example: Figure 3 from RFC 793. 328 In these examples the first line specifies the generated SVG 329 filename. The scale factor determines the size of the SVG drawing; 330 it needs to be set so that the drawing fits nicely into the final 331 document. 333 'packet;' starts the packet description; it's followed by a 334 description of the fields in each row. 336 info; 337 output "tcp-header.svg", scale 0.65; 339 packet; 340 row 0; 341 field "Source Port", 0 to 15; 342 field "Destination Port", 16 to 31; 343 row 1; 344 field "Sequence Number", 0 to 31; 345 row 2; 346 field "Acknowledgement Number", 0 to 31; 347 row 3; 348 field "Data Offset", 0 to 3; 349 field "Reserved", 4 to 9; 350 field "Urg", 10 to 10, fsize 14; # 14 px font so the flags fit 351 field "Ack", 11 to 11, fsize 14; 352 field "Psh", 12 to 12, fsize 14; 353 field "Rst", 13 to 13, fsize 14; 354 field "Syn", 14 to 14, fsize 14; 355 field "Fin", 15 to 15, fsize 14; 356 field "Window", 16 to 31; 357 row 4; 358 field "Checksum", 0 to 15; 359 field "Urgent Pointer", 16 to 31; 360 row 5; 361 field "Options", 0 to 23; 362 field "Padding", 24 to 31; 363 row 6; 364 field "Data", 0 to 31; 366 5.2. Sequence Diagrams (1) 368 Example: Figure 6 from draft-loreto-httpbis-trusted-proxy20-00. 370 In this example, columns are vertical lines with a text header above 371 them. There are three columns, and columns 1 and 2 are spaced 250 372 pixels apart. 374 The rest of the file describes objects to be drawn; most of them are 375 plines (polylines) from one column to another, but object 3 only 376 extends across to 0.3 of the distance between columns 1 and 2. 378 info; 379 output "httpbis-proxy20-fig6.svg", scale 0.9; 381 #Thu, 30 Jan 14 (NZDT) 383 #Figure 6 of draft-loreto-httpbis-trusted-proxy20-00.txt 385 column 1 width 250; # columns have vertical line to bottom 386 text above "user-agent"; 388 column 2 width 250; 389 text "Proxy"; 391 column 3; # Last col 392 text "Server"; 394 object 1; # Only need polylines 395 pline 1 to 2, arrowhead at end; 396 text above "(1) TLS ClientHello"; 397 text below "(ALPN ProtocolName: http)"; 399 object 2; 400 pline 1 to 2, arrowhead at start; 401 text above "(2) TLS Error"; 402 text below "(Proxy Cert)"; 404 object 3; 405 pline 1 to 1.3, down, back to 1, arrowhead at end; 406 text seg 2 centre "(inform user of the SecureProxy)"; 408 object 4; 409 pline 1 to 2, arrowhead at end; 410 text above "(3) TLS ClientHello"; 412 object 5; 413 pline 1 to 2, arrowhead at start; 414 text above "(4) ServerHello"; 416 object 6; 417 blank 1 to 2; 419 object 7; 420 block 1 to 2, objects 8 to 15, colour "grey"; 421 text above "HTTP2.0"; 423 object 8; 424 pline 1 to 2, arrowhead at end; 425 text seg 1 centre "(5) stream(X) GET"; 427 object 9; 428 pline 2 to 3, arrowhead at end; 429 text seg 1 above "(6) TLS ClientHello"; 431 object 10; 432 pline 2 to 3, arrowhead at start; 433 text seg 1 above "TLS ServerHello"; 435 object 11; 436 blank 2 to 3; 438 object 12; 439 block 2 to 3, objects 13 to 15, colour "grey"; 440 text seg 1 above "HTTP2.0"; 442 object 13; 443 pline 2 to 3, arrowhead at end; 444 text seg 1 centre "(7) stream(Z) GET"; 446 object 14; 447 pline 2 to 3, arrowhead at start; 448 text seg 1 centre "(8) stream(Z) 200 OK"; 450 object 15; 451 pline 1 to 2, arrowhead at start; 452 text seg 1 centre "(9) stream(X) 200 OK"; 454 5.3. Sequence Diagrams (2) 456 Example: Figure 3 from RFC 4321 458 This example uses (x,y) coordinates to specify points in in plines. 459 For these, the x units are columns and the y units are lines 460 (positive means 'down the diagram'). 462 both x and y may be absolute, e.g. 4.3, or relative, e.g. +1.5). 463 For the first point of a pline, relative means 'relative to the 464 starting point of the previous pline,' for other points in a pline it 465 means 'relative to the last point.' 467 Note that column 1 is drawn in white, i.e. nothing is drawn for it. 468 It's simply used to make a blank area where objects 8 and 9 can place 469 text. For both those objects a pline is used to specify the text's 470 position. 472 Last, the metalanguage allows simple macros, introduced by 'define 473 foo = '. These make it easier to re-use definitions, for example of 474 line types. 476 info; 477 output "rfc4321-fig3.svg", scale 0.9; 479 # Sat, 5 Apr 14 (NZDT) 481 #Figure 3 of RFC 4321 483 define hw = width 110; # Hop width 485 column 1 width 130, colour "white"; # No heading or vertical line 487 column 2 hw; text above "UAC"; 489 column 3 hw; text "P1"; 491 column 4 hw; text "P2"; 493 column 5 hw; text "P3"; 495 column 6 hw; text "UAS"; 497 define tgrey = colour "lightgrey" width 5; # Thick grey 498 define ahe = arrowhead at end; 500 object 1; 501 pline 1.8 502 to 2.3 tgrey, to (2.4,+0), to (2.6,+1.5), to (2.7,+0) ahe, 503 to 3.3 tgrey, to (3.4,+0), to (3.6,+1.5), to (3.7,+0) ahe, 504 to 4.3 tgrey, to (4.4,+0), to (4.6,+1.5), to (4.7,+0) ahe, 505 to 5.3 tgrey, to (5.4,+0), to (5.6,+1.5), to (5.7,+0) ahe, 506 to 6.3 tgrey; 508 object 2; 509 pline (1.8,+10) to 2.3 tgrey; 511 object 3; 512 pline (3.3,+2) 513 to 2.85 tgrey, to (2.7,+0) tgrey, 514 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 515 text seg 2 centre "408"; 517 object 4; 518 pline (4.3,+1.5) 519 to 3.9 tgrey, to (3.7,+0) tgrey, 520 to (3.5,+0), to (3.3,+1.5), to (3.1,+0) ahe, 521 to 2.9 tgrey, to (2.7,+0) tgrey, 522 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 523 text seg 2 centre "408"; 524 text seg 7 centre "408"; 526 object 5; 527 pline (5.3,+1.5) 528 to 4.9 tgrey, to (4.7,+0) tgrey, 529 to (4.5,+0), to (4.3,+1.5), to (4.1,+0) ahe, 530 to 3.9 tgrey, to (3.7,+0) tgrey, 531 to (3.5,+0), to (3.3,+1.5), to (3.1,+0) ahe, 532 to 2.9 tgrey, to (2.7,+0) tgrey, 533 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 534 text seg 2 centre "408"; 535 text seg 7 centre "408"; 536 text seg 12 centre "408"; 538 object 6; 539 pline (6.3,+1.5) 540 to 5.9 tgrey, to (5.7,+0) tgrey, 541 to (5.5,+0), to (5.3,+1.5), to (5.1,+0) ahe; 542 to 4.9 tgrey, to (4.7,+0) tgrey, 543 to (4.5,+0), to (4.3,+1.5), to (4.1,+0) ahe; 544 to 3.9 tgrey, to (3.7,+0) tgrey, 545 to (3.5,+0), to (3.3,+1.5), to (3.1,+0) ahe; 546 to 2.9 tgrey, to (2.7,+0) tgrey, 547 to (2.5,+0), to (2.25,+1.5), to (2.0,+0) ahe; 548 text seg 2 centre "408"; 549 text seg 7 centre "408"; 550 text seg 12 centre "408"; 551 text seg 17 centre "408"; 553 object 7: 554 pline (1.63,4.1) to (1.73,+0); 556 object 8; 557 pline (1.68,4.1) to (+0,14) arrowhead at end; 558 text centre "64*T1"; 560 object 9; 561 pline (1.2,13.1) to (1.5,+0) colour "white"; 562 text centre "(timeout)"; 564 6. IANA Considerations 566 This document does not create a new registry nor does it register any 567 values in existing registries; no IANA action is required. 569 7. Acknowledgements 571 Thanks to the RSE and the Design Team members for their helpful 572 comments and suggestions for SVG 1.2 RFC. 574 8. Revision History [RFC Editor please delete] 576 version -11, 17 Aug 15: 577 Section 1: Fixed typo in "Details are expected to change" 578 paragraph. 580 version -10, 14 Aug 15: 581 Section 1: Added "Details are expected to change" paragraph. 583 version -09, 31 Mar 15: 584 No changes, version number incremented to keep draft alive 586 version -08, 29 Sep 14: 587 Section 1: Changed comment about diagrams 'not being normative' to 588 'not complete specifications in themselves. 589 Section 2.1: Added SVG 1.2 Tiny 'id' attribute because most 590 drawing packages use it in constructing drawings. 591 Section 2.1: Added SVG 1.2 Tiny 'role' attribute so that ARIA can 592 use it. 593 Section 3: added comment about changes to xml2rfc required to 594 include SVG diagrams. 595 Section 4: Added reference to svg-aria-primer. 597 version -07, 3 Jul 14: 598 Expanded text about Accessibility in 'how to create SVG drawings' 599 section into 'Accessibility Considerations section. Added two SVG 600 Accessibility references to support that. 602 version -06, 26 Jun 14: 603 Remove trailing / from URL in section 4; the html version on 604 tools.ietf.org/html assumed the next word was part of that URL. 606 version -05, 25 Jun 14: 607 Improved section on 'how to create SVG drawings' By adding some 608 text about which elements aren't allowed in SVG 1.2 RFC. 609 Added more text describing the tool for checking, stripping out or 610 replacing incompatible elements and attributes from an SVG file. 612 version -04, 30 Apr 14: 613 Fixed typos, used full references for two of the w3c refs - each 614 had an author name using UTF8 characters. 615 Moved the Elements and Attributes appendix up earlier to make it 616 sub-section 2.1. 617 Disclaimer added to the Meta-languages section. 619 version -03, 14 Apr 14: 620 Added two more example diagrams; a simple packet layout, and a 621 diagram that uses lots of diagonal lines. 623 version -02, 12 Feb 14: 624 Added metalanguage example to make time-sequence drawings. 626 version -01, 11 Feb 14: 627 Allow links to 'long-term stable URIs' 628 Link URIs must be ASCII only 629 Need for tools to check SVG 1.2 RFC compatibility and to strip 630 'unnecessary' attributes explicitly stated. 631 Statement that drawings can't be normative removed; Postscript- 632 only RFCs already exist. 633 Added most attributes and elements to the Appendix. 635 version -00, 29 Jan 14: 636 Initial version, using content from Nevil's 637 emails to the Design Team. 639 9. References 641 9.1. Normative References 643 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 644 Requirements and Future Development", RFC 6949, 645 DOI 10.17487/RFC6949, May 2013, 646 . 648 [W3C.REC-SVGTiny12-20081222] 649 Andersson, O., Berjon, R., Dahlstrom, E., Emmons, A., 650 Ferraiolo, J., Grasso, A., Hardy, V., Hayman, S., Jackson, 651 D., Lilley, C., McCormack, C., Neumann, A., Northway, C., 652 Quint, A., Ramani, N., Schepers, D., and A. Shellshear, 653 "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", 654 World Wide Web Consortium Recommendation REC- 655 SVGTiny12-20081222, December 2008, 656 . 658 [W3C.REC-CSS2-20110607] 659 Bos, B., Celik, T., Hickson, I., and H. Lie, "Cascading 660 Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", 661 World Wide Web Consortium Recommendation REC- 662 CSS2-20110607, June 2011, 663 . 665 9.2. Informative References 667 [W3C.REC-SVG11-20110816] 668 Dahlstrom, E., Dengler, P., Grasso, A., Lilley, C., 669 McCormack, C., Schepers, D., Watt, J., Ferraiolo, J., 670 Fujisawa, J., and D. Jackson, "Scalable Vector Graphics 671 (SVG) 1.1 (Second Edition)", World Wide Web Consortium 672 Recommendation REC-SVG11-20110816, August 2011, 673 . 675 [SVG-ACCESS-TIPS] 676 Watson, L., "Tips for Creating Accessible SVG", SitePoint 677 tips-accessible-svg, May 2014, 678 . 680 [SVG-ARIA-PRIMER] 681 Pappas, L., Schwerdtfeger, R., and M. Cooper, "WAI-ARIA 682 1.0 Primer", World Wide Web Consortium WD WD-wai-aria- 683 primer-20100916, September 2010, 684 . 686 [SVG-USING-ARIA] 687 Watson, L., "Using ARIA to enhance SVG accessibility", The 688 Paciello Group 2013/12/using-aria-enhance-svg- 689 accessibility, December 2013, 690 . 693 Authors' Addresses 695 Nevil Brownlee 696 The University of Auckland 698 Email: n.brownlee@auckland.ac.nz 700 Internet Architecture Board 702 Email: iab@iab.org