idnits 2.17.1 draft-rfc-format-flanagan-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 491 has weird spacing: '...ensible encod...' -- The document date (November 27, 2012) is 4167 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ASCII' is mentioned on line 117, but not defined -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Flanagan 3 Intended Status: Informational RFC Series Editor 4 N. Brownlee 5 Independent Submissions Editor 6 Expires: May 31, 2013 November 27, 2012 8 RFC Series Format Development 9 draft-rfc-format-flanagan-02 11 Abstract 13 This document describes the current requirements and requests for 14 enhancements for the format of the canonical version of RFCs. Terms 15 are defined to help clarify exactly which stages of document 16 production are under discussion for format changes. The requirements 17 described in this document will determine what changes will be made 18 to RFC format. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. History and Goals . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Issues driving change . . . . . . . . . . . . . . . . . . 5 62 2.1.1. Line art, aka ASCII art . . . . . . . . . . . . . . . 6 63 2.1.2. Character encoding . . . . . . . . . . . . . . . . . . 7 64 2.1.3. Pagination . . . . . . . . . . . . . . . . . . . . . . 8 65 2.1.4. Reflowable text . . . . . . . . . . . . . . . . . . . 8 66 2.1.5. Metadata and tagging . . . . . . . . . . . . . . . . . 8 67 2.2. Further considerations . . . . . . . . . . . . . . . . . . 9 68 2.2.1. Creation and use of RFC-specific tools . . . . . . . . 9 69 2.2.2. Markup Language . . . . . . . . . . . . . . . . . . . 10 70 2.3. RFC Editor goals . . . . . . . . . . . . . . . . . . . . . 10 71 3. Format requirements . . . . . . . . . . . . . . . . . . . . . 10 72 3.1. Original requirements to be retained . . . . . . . . . . . 10 73 3.2. Requirements to be added . . . . . . . . . . . . . . . . . 11 74 3.3. Requirements to be retired . . . . . . . . . . . . . . . . 12 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1 Introduction 85 Over 40 years ago, the RFC Series began in an environment that 86 included handwritten RFCs, typewritten RFCs, RFCs produced on 87 mainframes, and more. This resulted in an understanding that however 88 they were published, a common format that could be read and revised 89 long in the future was required. US-ASCII was chosen as that format, 90 and since that time that format has proved to be persistent and 91 reliable across a large variety of devices, operating systems, and 92 editing tools. That stability has been a continuing strength of the 93 Series. However, as new technology such as small devices and 94 advances in display technology come in to common usage, there is a 95 growing desire to see the format of the RFC Series adapt to take 96 advantage of these different ways to communicate information. 98 Since the earliest days of the Series, authors and readers have 99 suggested enhancements to the format. However, no suggestion 100 developed clear consensus in the Internet technical community. As 101 always, some individuals see no need for change while others press 102 strongly for specific enhancements. 104 This document takes a look at the current requirements for RFCs as 105 described in RFC 2223 [RFC2223] and more recently in 2223bis 106 [2223bis]. It also reviews recent requests for enhancements as 107 understood from community discussion and various proposals for new 108 formats including HTML, XML, PDF and EPUB. The focus of this 109 document is on the Canonical format of RFCs, but some mention of 110 other phases in the RFC publication process and the document formats 111 associated with these phases is also included. Terms are defined to 112 help clarify exactly which stages of document production are under 113 discussion for format changes. 115 1.1 Terminology 117 [ASCII] = Coded Character Set -- 7-bit American Standard Code for 118 Information Interchange", ANSI X3.4-1986. 120 Submission format = the format submitted to the RFC Editor for 121 editorial revision and publication. 123 * might not be the same as the canonical format (though it would 124 make the workflow somewhat simpler for the RFC Editor if it 125 were); 127 * will be converted to another format for further processing and 128 publication if necessary 130 * Currently: .txt (required), XML (optional), NROFF (optional) 132 Revisable format = the format that will provide the information for 133 conversion into an Publication format; it is used or created by the 134 RFC Editor 136 * Currently: XML (optional), NROFF (required) 138 Publication format = display and distribution format as it may be 139 read or printed after publication process has completed. 141 * Currently published by the RFC Editor: .txt, PDF, PDF that 142 contains figures (rare) 144 * Currently made available by other sites: HTML, PDF, others 146 Canonical format = the authorized, recognized, accepted, and archived 147 version of the document. 149 * Currently: .txt 151 Metadata = Information associated with a document so as to provide, 152 for example, definitions of its structure, or of elements within it 153 such as it topic or author. 155 2. History and Goals 157 Current RFC format rules as defined in [RFC2223] and clarified in 158 2223bis. 160 * The character codes are ASCII. 162 * Each page must be limited to 58 lines followed by a form feed 163 on a line by itself. 165 * Each line must be limited to 72 characters followed by carriage 166 return and line feed. 168 * No overstriking (or underlining) is allowed. 170 * These "height" and "width" constraints include any headers, 171 footers, page numbers, or left side indenting. 173 * Do not fill the text with extra spaces to provide a straight 174 right margin. 176 * Do not do hyphenation of words at the right margin. 178 * Do not use footnotes. If such notes are necessary, put them at 179 the end of a section, or at the end of the document. 181 * Use single spaced text within a paragraph, and one blank line 182 between paragraphs. 184 * Note that the number of pages in a document and the page 185 numbers on which various sections fall will likely change with 186 reformatting. Thus cross references in the text by section 187 number usually are easier to keep consistent than cross 188 references by page number. 190 * RFCs in plain ASCII-text may be submitted to the RFC Editor in 191 e-mail messages (or as online files) in either the finished 192 Publication format or in nroff. If you plan to submit a 193 document in nroff please consult the RFC Editor first. 195 Precedent for multiple Publication formats is described in RFC 2223 196 and has been used for a few RFCs: 198 Note that since the ASCII text version of the RFC is the primary 199 version, the PostScript version must match the text version. The 200 RFC Editor must decide if the PostScript version is "the same as" 201 the ASCII version before the PostScript version can be published. 203 Neither RFC 2223 or 2223bis use the term 'metadata,' though the RFC 204 Editor currently refers to components of the text such as the Stream, 205 Status (e.g. Updates, Obsoletes), Category and ISSN as 'metadata.' 207 2.1. Issues driving change 209 While some authors and readers of RFCs find the strict limits of 210 character encoding, line limits, and so on to be acceptable, others 211 find those limitations a significant obstacle to their desire to 212 communicate information via an RFC. With a broader community of 213 authors currently producing RFCs and a wider range of presentation 214 devices, the issues driving change represent both critical 215 deficiencies in the current Canonical format as well as strongly 216 desirable changes on the part of some segments of the Internet 217 community. 219 While the specific points of concern vary, the main issues are: 221 * Line art, also known as ASCII art 222 * Character encoding 224 * Pagination 226 * Reflowable text 228 * Metadata 230 Each area of concern has people in favor of change and people opposed 231 to it, all with reasonable concerns and requirements. Below is a 232 summary of the arguments for and against each major issue. The 233 potential requirements derived from these discussions are listed 234 later in this document. 236 2.1.1. Line art, aka ASCII art 238 Arguments in favor of keeping the current requirement for all 239 diagrams, equations, tables, and charts include: 241 * Dependence on advanced diagrams (or any diagrams) causes 242 accessibility issues 244 * Requiring ASCII art results in people often relying more on 245 clear written descriptions rather than just the diagram 246 itself. 248 * Use of the ASCII character set forces design of diagrams that 249 are simple and concise.. 251 Arguments in favor of replacing ASCII art with more complex diagrams 252 include: 254 * State diagrams with multiple arrows in different directions and 255 labels on the lines will be more understandable. 257 * Protocol flow diagrams where each step needs multiple lines of 258 description will be clearer. 260 * Scenario descriptions that involve three or more parties with 261 communication flows between them will be clearer. 263 * Given the difficulties in expressing complex equations with 264 common mathematical notation, allowing graphic art would allow 265 equations to be displayed properly. 267 * Complex art could allow for color to be introduced into the 268 diagrams. 270 Two suggestions have been been proposed regarding how graphics should 271 be included: one that would have graphic art referenced as a separate 272 document to the Publication format, and one that would allow embedded 273 graphics in the Publication format. 275 2.1.2. Character encoding 277 For most of the history of the RFC Series, the character encoding for 278 RFCs has been ASCII. Below are arguments for keeping ASCII as well 279 as arguments for expanding to UTF-8. 281 Arguments for retaining the ASCII-only requirement 283 * Most easily searched and displayed across a variety of 284 platforms. 286 * In extreme cases of having to retype/scan hard copies of 287 documents (it has been required in the past) ASCII is 288 significantly easier to work with for rescanning and retaining 289 all of the original information. There can be no loss of 290 descriptive metadata such as keywords or content tags. 292 * If we expand beyond ASCII, it will be difficult to know where 293 to draw the line on what characters are and are not allowed. 294 There will be issues with dependencies on local file systems 295 and processors being configured to recognize any other 296 character set. 298 * The IETF works in ASCII (and English). The Internet research, 299 design and development communities function almost entirely in 300 English. That strongly suggests that an ASCII document can be 301 read by everyone in the communities and audiences of interest. 303 Arguments for expanding to allow UTF-8: 305 * In discussions of internationalization, actually being able to 306 illustrate the issue is rather helpful, and you can't 307 illustrate a Unicode code point with "U+nnnn". 309 * Will provide the ability to denote protocol examples using the 310 character sets those examples support. 312 * Will allow better support for international character sets, in 313 particular allowing authors to spell their names in their 314 native character sets. 316 * Certain special characters in equations or quoted from other 317 texts could be allowed. 319 * Citations of web pages using more international characters are 320 possible. 322 Arguments for strictly prescribed UTF-8 use: 324 * In order to keep documents as searchable as possible, ASCII-only 325 should be required for the main text of the document and some 326 broader UTF-8 character set allowed under clearly prescribed 327 circumstances (e.g. author names and references). 329 2.1.3. Pagination 331 Arguments for continuing the use of discrete pages within RFCs: 333 * Ease of reference and clear printing; referring to section 334 numbers is too coarse a method 336 Arguments for removing the pagination requirement: 338 * Removing pagination will allow for a smoother reading 339 experience on a wider variety of devices, platforms, and 340 browsers 342 2.1.4. Reflowable text 344 Arguments against allowing for reflowable text: 346 * Reflowable text may impact the usability of graphics and tables 347 within a document. 349 Arguments for allowing reflowable text 351 * RFCs are more readable on a wider variety of devices and 352 platforms, including mobile devices and a wide variety of 353 screen layouts. 355 2.1.5. Metadata and tagging 357 While metadata requirements are not part of RFC 2223, there is a 358 request that descriptive metadata tags be added as part of a revision 359 of the Canonical RFC format. These tags would allow for enhanced 360 content by embedding information like links, tags, or quick 361 translations and could help control the look and feel of the 362 Publication format. While the lack of metadata in the current RFCs 363 does not impact an RFCs accessibility or readability, if other 364 requirements are accepted, such as allowing UTF-8 in any part of an 365 RFC, then having the ability to use metadata to provide an ASCII 366 "translation" of the UTF-8 letters is also a requirement. 368 Arguments for allowing metadata in the Canonical and Publication 369 formats: 371 * Allowing metadata in the final Canonical and Publication format 372 allows readers to potentially get more detail out of a 373 document. For example, if non-ASCII characters are allowed in 374 the Author and Reference sections, Metadata must include 375 translations of that information. 377 Arguments against metadata in the final Canonical and Publication 378 formats: 380 * Metadata adds additional overhead to the overall process of 381 creating RFCs and may complicate future usability. 383 2.2. Further considerations 385 Some of the discussion beyond the issues described above went into 386 potential solutions. Those solutions and the debate around them 387 added a few more points to the potential requirements for a change in 388 RFC Format. In particular, discussing whether a change in format 389 should also include the creation and ongoing support of specific RFC 390 authoring and/or rendering tools and whether the Canonical format 391 should be a format that must go through a rendering agent to be 392 readable. 394 2.2.1. Creation and use of RFC-specific tools 396 Arguments against community-supported RFC-specific tools: 398 * We cannot be so unique in our needs that we can't use 399 commercial tools. 401 * Ongoing support for these tools adds a greater level of 402 instability to the ongoing availability of the RFC Series 403 through the decades. 405 * The community that would support these tools cannot be relied 406 on to be as stable and persistent as the Series itself. 408 Arguments in support of community-supported RFC-specific tools: 410 * Given the community that would be creating and supporting these 411 tools, there would be greater control and flexibility over the 412 tools and how they implement the RFC format requirements. 414 * Community supported tools currently exist and are in extensive 415 use within the community, so it would be most efficient to 416 build on that base. 418 2.2.2. Markup Language 420 Arguments in support of a markup language as the Revisable format: 422 * Having a markup language such as XML or HTML allows for greater 423 flexibility in creating a variety of Publication formats, with 424 a greater likelihood of similarity between them. 426 Arguments against a markup language as the Revisable format: 428 * Having the Publication format be in code instead of in a simple 429 text-formatting structure ties us in to specific tools and/or 430 tool support going forward. 432 2.3. RFC Editor goals 434 Today, each RFC has an nroff file created prior to publication. For 435 RFCs revised using an XML file, this file is created by converting 436 XML to nroff at the final step. As more documents are submitted with 437 an XML file (so far in 2012, 66% of approved I-Ds were submitted with 438 an XML file), this conversion is problematic in terms of time spent 439 and data lost from XML. Making this process more efficient is 440 strongly desired by the RFC Editor. 442 3. Format requirements 444 Understanding the major pain points and balancing them with the 445 expectation of long-term viability of the documents brings us to a 446 review of what must be kept of the original requirements, what new 447 requirements may be added, and what requirements may be retired. 449 3.1. Original requirements to be retained 451 There are several components of the original format requirements that 452 must be retained to ensure the ongoing continuity, reliability and 453 readability of the Series: 455 * RFCs must not change, regardless of format, once published. 457 * The Canonical format must be persistent and reliable across a 458 large variety of devices, operating systems, and editing tools 459 for the indefinite future. 461 * While several Publication formats must be allowed, the 462 Publication formats must include support for plain-text 463 printing. 465 * The Boilerplate and overall structure of the RFC must be in 466 accordance with current RFC and Style Guide requirements (see 467 [RFC5741]). 469 Issues such as overstriking, page justification, hyphenation, and 470 spacing will be defined in the RFC Style Guide. [link required] 472 3.2. Requirements to be added 473 In addition to those continuing requirements, discussions with 474 various members of the wider Internet Community have yielded the 475 following General Requirements for the RFC Series. 477 * There must be support for Accessibility, including alternative 478 text for images, limitations on color. Appropriate authoring 479 tools are highly desirable but focus on the creation of 480 Internet-Drafts, a topic outside the scope of the RFC Editor. 481 [WCAG20] 483 * The official language of the RFC Series is English. To respect 484 international names and information, UTF-8/Unicode in the 485 header and references must be allowed. Romanized ASCII 486 translations will be required and recorded in the metadata 487 (that translation will be used in the ASCII text version of the 488 RFC and to aid in basic searching). 490 * The Submission and Publication formats need to permit 491 extensible encoding, for the addition of labeled metadata. A 492 pre-defined set of metadata tags must be created to make use of 493 metadata tags consistent for the life of the Series. 495 * Graphics may include ASCII art and SVG line art. Color will 496 not be accepted; RFCs must correctly display in monochrome to 497 allow for monochrome displays, black-and-white printing, and 498 Accessibility issues. 500 * RFC must be readable self-contained (i.e. must not contain 501 normative external links, figures, etc.) in order to be easily 502 downloaded and read offline. 504 * Fixed-width fonts are required for ASCII-art sections, source 505 code examples, and other places where strict alignment is 506 required. 508 The requirements of the RFC Editor in considering how the formats for 509 Submission and Publication should change include: 511 * The final conversion of all submitted documents to nroff should 512 be replaced by using an accepted Revisable format throughout 513 the process. 515 * In order to maintain an efficient publication process, the RFC 516 Editor must work with the minimal number of files required for 517 each submission (not a tar ball of several discrete 518 components). 520 * In order to maintain the focus of the RFC Editor on editing for 521 clarity and consistency rather than document layout details, 522 the number of Publication formats must be limited. 524 * Tools must support error checking against document layout 525 issues as well as other format details (diagrams, line breaks, 526 variable and fixed width font layout) at the time of Submission 527 for author review. 529 3.3. Requirements to be retired 531 Some of the original requirements may be removed from consideration: 533 * Pagination ("Each page must be limited to 58 lines followed by 534 a form feed on a line by itself.") 536 * Maximum line length ("Each line must be limited to 72 537 characters followed by carriage return and line feed.") 539 * Limitation to 100% ASCII text ("The character codes are 540 ASCII.") 542 4. Security Considerations 544 This document sets out requirements for RFCs in their various 545 formats, it does not concern interactions between Internet 546 hosts. Therefore it does not have any specific Security 547 Considerations. 549 5. IANA Considerations 550 This document does not request entries in any IANA Registry. 552 6. References 554 6.1. Normative References 556 [WCAG20] W3C, "Web Content Accessibility Guidelines (WCAG) 2.0", 557 December 11 2008, http://www.w3.org/TR/WCAG20/ 559 6.2. Informative References 561 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 562 RFC 2223, October 1997. 564 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 565 Headers, and Boilerplates", RFC 5741, December 2009. 567 [2223bis] Reynolds, J. Bradon, R., "Instructions to Request for 568 Comments (RFC) Authors", Work In Progress, August 2004. 570 Acknowledgements 572 The authors received a great deal of helpful input from the community 573 in pulling together these requirements and wish to particularly 574 acknowledge the help of Joe Hildebrand, Paul Hoffman and John 575 Klensin, who each published an I-D on the topic of potential format 576 options before the IETF 84 BOF. 578 Authors' Addresses 580 Heather Flanagan 581 RFC Series Editor 583 Email: rse@rfc-editor.org 585 Nevil Brownlee 586 Independent Submissions Editor 588 Email rfc-ise@rfc-editor.org