idnits 2.17.1 draft-iab-rfcformatreq-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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC2223, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 147 has weird spacing: '...rmatted plain...' == Line 488 has weird spacing: '... and limit...' -- The document date (January 31, 2013) is 4074 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) == Outdated reference: A later version (-03) exists of draft-flanagan-style-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: August 4, 2013 January 31, 2013 8 RFC Series Format Requirements and Future Development 9 draft-iab-rfcformatreq-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. This document updates RFC 2223. 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 . . . . . . . . . . . . . . . . . . . 13 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Informative References . . . . . . . . . . . . . . . . . . 13 79 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 1 Introduction 84 Over 40 years ago, the RFC Series began as a collection of memos in 85 an environment that included handwritten RFCs, typewritten RFCs, RFCs 86 produced on mainframes with complicated layout tools, and more. As 87 the tools changed and some of the source formats became unreadable, 88 the core individuals behind the Series realized that a common format 89 that could be read, revised, and archived long in the future was 90 required. US-ASCII was chosen for the encoding of characters and 91 after a period of variability, a well-defined presentation format was 92 settled upon. That format has proved to be persistent and reliable 93 across a large variety of devices, operating systems, and editing 94 tools. That stability has been a continuing strength of the Series. 95 However, as new technology such as small devices and advances in 96 display technology come into common usage, there is a growing desire 97 to see the format of the RFC Series adapt to take advantage of these 98 different ways to communicate information. 100 Since the format stabilized, authors and readers have suggested 101 enhancements to the format. However, no suggestion developed clear 102 consensus in the Internet technical community. As always, some 103 individuals see no need for change while others press strongly for 104 specific enhancements. 106 This document takes a look at the current requirements for RFCs as 107 described in RFC 2223 [RFC2223] and more recently in 2223bis 108 [2223bis]. Section 2 reviews recent requests for enhancements as 109 understood from community discussion and various proposals for new 110 formats including HTML, XML, PDF and EPUB. The actual requirements 111 are then captured in Section 3. The focus of this document is on the 112 Canonical format of RFCs, but some mention of other phases in the RFC 113 publication process and the document formats associated with these 114 phases is also included. Terms are defined to help clarify exactly 115 which stages of document production are under discussion for format 116 changes. 118 1.1 Terminology 120 ASCII = Coded Character Set -- 7-bit American Standard Code for 121 Information Interchange, ANSI X3.4-1986. [ASCII] 123 Submission format = the format submitted to the RFC Editor for 124 editorial revision and publication 126 * Currently: formatted plain text (required), XML (optional), 127 NROFF (optional) 129 Revisable format = the format that will provide the information for 130 conversion into a Publication format; it is used or created by the 131 RFC Editor (see Section 2.3 for an explanation of current practice) 133 * Currently: XML (optional), NROFF (required) 135 Publication format = display and distribution format as it may be 136 read or printed after the publication process has completed 138 * Currently published by the RFC Editor: formatted plain text, 139 PDF of the formatted plain text, PDF that contains figures 140 (rare) 142 * Currently made available by other sites: HTML, PDF, others 144 Canonical format = the authorized, recognized, accepted, and archived 145 version of the document 147 * Currently: formatted plain text 149 Metadata = Information associated with a document so as to provide, 150 for example, definitions of its structure, or of elements within the 151 document such as its topic or author 153 2. History and Goals 155 Below are the current RFC format rules as defined in [RFC2223] and 156 clarified in 2223bis. 158 * The character codes are ASCII. 160 * Each page must be limited to 58 lines followed by a form feed 161 on a line by itself. 163 * Each line must be limited to 72 characters followed by carriage 164 return and line feed. 166 * No overstriking (or underlining) is allowed. 168 * These "height" and "width" constraints include any headers, 169 footers, page numbers, or left side indenting. 171 * Do not fill the text with extra spaces to provide a straight 172 right margin. 174 * Do not do hyphenation of words at the right margin. 176 * Do not use footnotes. If such notes are necessary, put them at 177 the end of a section, or at the end of the document. 179 * Use single spaced text within a paragraph, and one blank line 180 between paragraphs. 182 * Note that the number of pages in a document and the page 183 numbers on which various sections fall will likely change with 184 reformatting. Thus cross references in the text by section 185 number usually are easier to keep consistent than cross 186 references by page number. 188 * RFCs in plain ASCII-text may be submitted to the RFC Editor in 189 e-mail messages (or as online files) in either the finished 190 Publication format or in nroff. If you plan to submit a 191 document in nroff please consult the RFC Editor first. 193 The precedent for additional formats, specifically PostScript, is 194 described in RFC 2223 and has been used for a small number of RFCs: 196 Note that since the ASCII text version of the RFC is the primary 197 version, the PostScript version must match the text version. The 198 RFC Editor must decide if the PostScript version is "the same as" 199 the ASCII version before the PostScript version can be published. 201 Neither RFC 2223 or 2223bis use the term 'metadata,' though the RFC 202 Editor currently refers to components of the text such as the Stream, 203 Status (e.g., Updates, Obsoletes), Category and ISSN as 'metadata.' 205 2.1. Issues driving change 207 While some authors and readers of RFCs report that they find the 208 strict limits of character encoding, line limits, and so on to be 209 acceptable, others claim to find those limitations a significant 210 obstacle to their desire to communicate and read the information via 211 an RFC. With a broader community of authors currently producing RFCs 212 and a wider range of presentation devices, the issues being reported 213 indicate limitations of the current Canonical format that must be 214 reviewed and potentially incorporated in to the Canonical RFC format. 216 While the specific points of concern vary, the main issues discussed 217 are: 219 * Line art, also known as ASCII art 220 * Character encoding 222 * Pagination 224 * Reflowable text 226 * Metadata 228 Each area of concern has people in favor of change and people opposed 229 to it, all with reasonable concerns and requirements. Below is a 230 summary of the arguments for and against each major issue. These 231 points are not part of the list of requirements; they are the inputs 232 that informed the requirements discussed in Section 3 of this 233 document. 235 2.1.1. Line art, aka ASCII art 237 Arguments in favor of limiting all diagrams, equations, tables and 238 charts to ASCII art depictions only include: 240 * Dependence on advanced diagrams (or any diagrams) causes 241 accessibility issues. 243 * Requiring ASCII art results in people often relying more on 244 clear written descriptions rather than just the diagram 245 itself. 247 * Use of the ASCII character set forces design of diagrams that 248 are simple and concise. 250 Arguments in favor of allowing the use of more complex diagrams in 251 place of the current use of ASCII art include: 253 * State diagrams with multiple arrows in different directions and 254 labels on the lines will be more understandable. 256 * Protocol flow diagrams where each step needs multiple lines of 257 description will be clearer. 259 * Scenario descriptions that involve three or more parties with 260 communication flows between them will be clearer. 262 * Given the difficulties in expressing complex equations with 263 common mathematical notation, allowing graphic art would allow 264 equations to be displayed properly. 266 * Complex art could allow for color to be introduced into the 267 diagrams. 269 Two suggestions have been proposed regarding how graphics should be 270 included: one that would have graphic art referenced as a separate 271 document to the Publication format, and one that would allow embedded 272 graphics in the Publication format. 274 2.1.2. Character encoding 276 For most of the history of the RFC Series, the character encoding for 277 RFCs has been ASCII. Below are arguments for keeping ASCII as well 278 as arguments for expanding to UTF-8. 280 Arguments for retaining the ASCII-only requirement 282 * Most easily searched and displayed across a variety of 283 platforms. 285 * In extreme cases of having to retype/scan hard copies of 286 documents (it has been required in the past) ASCII is 287 significantly easier to work with for rescanning and retaining 288 all of the original information. There can be no loss of 289 descriptive metadata such as keywords or content tags. 291 * If we expand beyond ASCII, it will be difficult to know where 292 to draw the line on what characters are and are not allowed. 293 There will be issues with dependencies on local file systems 294 and processors being configured to recognize any other 295 character set. 297 * The IETF works in ASCII (and English). The Internet research, 298 design and development communities function almost entirely in 299 English. That strongly suggests that an ASCII document can be 300 properly rendered and read by everyone in the communities and 301 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 * Removing pagination results in people often using subsections 343 rather than page number for reference purposes, forcing what 344 would otherwise be long sections to be broken into subsections. 345 This would encourage documents that are better organized and 346 simpler. 348 2.1.4. Reflowable text 350 Arguments against requiring text to be reflowable: 352 * Reflowable text may impact the usability of graphics and tables 353 within a document. 355 Arguments for requiring text to be reflowable: 357 * RFCs are more readable on a wider variety of devices and 358 platforms, including mobile devices and a wide variety of 359 screen layouts. 361 2.1.5. Metadata and tagging 362 While metadata requirements are not part of RFC 2223, there is a 363 request that descriptive metadata tags be added as part of a revision 364 of the Canonical RFC format. These tags would allow for enhanced 365 content by embedding information like links, tags, or quick 366 translations and could help control the look and feel of the 367 Publication format. While the lack of metadata in the current RFCs 368 does not impact an RFC's accessibility or readability, several 369 individuals have indicated that allowing metadata within the RFC 370 would make their reading of the documents more efficient. 372 Arguments for allowing metadata in the Canonical and Publication 373 formats: 375 * Allowing metadata in the final Canonical and Publication format 376 allows readers to potentially get more detail out of a 377 document. For example, if non-ASCII characters are allowed in 378 the Author and Reference sections, Metadata must include 379 translations of that information. 381 Arguments against metadata in the final Canonical and Publication 382 formats: 384 * Metadata adds additional overhead to the overall process of 385 creating RFCs and may complicate future usability as a result 386 of requiring backward compatibility for metadata tags. 388 2.2. Further considerations 390 Some of the discussion beyond the issues described above went into a 391 review of potential solutions. Those solutions and the debate around 392 them added a few more points to the list of potential requirements 393 for a change in RFC Format. In particular, the discussion of tools 394 introduced the idea of whether a change in format should also include 395 the creation and ongoing support of specific RFC authoring and/or 396 rendering tools and whether the Canonical format should be a format 397 that must go through a rendering agent to be readable. 399 2.2.1. Creation and use of RFC-specific tools 401 Arguments against community-supported RFC-specific tools: 403 * We cannot be so unique in our needs that we can't use 404 commercial tools. 406 * Ongoing support for these tools adds a greater level of 407 instability to the ongoing availability of the RFC Series 408 through the decades. 410 * The community that would support these tools cannot be relied 411 on to be as stable and persistent as the Series itself. 413 Arguments in support of community-supported RFC-specific tools: 415 * Given the community that would be creating and supporting these 416 tools, there would be greater control and flexibility over the 417 tools and how they implement the RFC format requirements. 419 * Community supported tools currently exist and are in extensive 420 use within the community, so it would be most efficient to 421 build on that base. 423 2.2.2. Markup language 425 Arguments in support of a markup language as the Revisable format: 427 * Having a markup language such as XML or HTML allows for greater 428 flexibility in creating a variety of Publication formats, with 429 a greater likelihood of similarity between them. 431 Arguments against a markup language as the Revisable format: 433 * Having the Revisable format be in a markup language instead of 434 in a simple text-formatting structure ties us in to specific 435 tools and/or tool support going forward. 437 2.3. RFC Editor goals 439 Today, each RFC has an nroff file created prior to publication. For 440 RFCs revised using an XML file, this file is created by converting 441 XML to nroff at the final step. As more documents are submitted with 442 an XML file (so far in 2012, 66% of approved I-Ds were submitted with 443 an XML file), this conversion is problematic in terms of time spent 444 and data lost from XML. Making this process more efficient is 445 strongly desired by the RFC Editor. 447 3. Format Requirements 449 Understanding the major pain points and balancing them with the 450 expectation of long-term viability of the documents brings us to a 451 review of what must be kept of the original requirements, what new 452 requirements may be added, and what requirements may be retired. 454 3.1. Original requirements to be retained 456 There are several components of the original format requirements that 457 must be retained to ensure the ongoing continuity, reliability and 458 readability of the Series: 460 * The content of an RFC must not change, regardless of format, 461 once published. 463 * The Canonical format must be persistent and reliable across a 464 large variety of devices, operating systems, and editing tools 465 for the indefinite future. This means the format must be both 466 readable and editable across commonly used devices, operating 467 system systems and platforms for the foreseeable future. 469 * While several Publication formats must be allowed, in order to 470 continue support for the most basic reading and search tools 471 and to provide continuity for the Series, at least one 472 Publication format must be plain-text. 474 * The Boilerplate and overall structure of the RFC must be in 475 accordance with current RFC and Style Guide requirements (see 476 [RFC5741]). 478 Issues such as overstriking, page justification, hyphenation, and 479 spacing will be defined in the RFC Style Guide. [Style] 481 3.2. Requirements to be added 482 In addition to those continuing requirements, discussions with 483 various members of the wider Internet Community have yielded the 484 following General Requirements for the RFC Series. 486 * The documents must be accessible to people with physical or 487 age-related disabilities, including alternative text for images 488 and limitations on color. See the W3C's Accessibility 489 documents [WCAG20] and the United Nations "Convention on the 490 Rights of Persons with Disabilities" [UN2006] for guidance. 491 Appropriate authoring tools are highly desirable but focus on 492 the creation of Internet-Drafts, a topic outside the scope of 493 the RFC Editor. [WCAG20] 495 * The official language of the RFC Series is English. However, 496 to respect international names and information, UTF-8/Unicode 497 is allowed. All documents containing non-ASCII characters must 498 be readable and implementable without them. Author names and 499 addresses will require an ASCII equivalent for indexing 500 purposes. 502 * The Submission and Publication formats need to permit extending 503 the set of metadata tags, for the addition of labeled metadata. 505 A pre-defined set of metadata tags must be created to make use 506 of metadata tags consistent for the life of the Series. 508 * Graphics may include ASCII art and SVG line art. Color will 509 not be accepted; RFCs must correctly display in monochrome to 510 allow for monochrome displays, black-and-white printing, and 511 support for physical and age-related disabilities. 513 * The Canonical format must be renderable into self-contained 514 Publication formats in order to be easily downloaded and read 515 offline. 517 * Fixed-width fonts and non-reflowable text are required for 518 ASCII-art sections, source code examples, and other places 519 where strict alignment is required. 521 * The Canonical format should be structured to enable easy 522 program identification and parsing of code or specifications, 523 such as MIB, ABNF, etc. 525 The requirements of the RFC Editor regarding RFC format and the 526 publication process include: 528 * The final conversion of all submitted documents to nroff should 529 be replaced by using an accepted Revisable format throughout 530 the process. 532 * In order to maintain an efficient publication process, the RFC 533 Editor must work with the minimal number of files required for 534 each submission (not a tar ball of several discrete 535 components). 537 * In order to maintain the focus of the RFC Editor on editing for 538 clarity and consistency rather than document layout details, 539 the number of Publication formats produced by the RFC editor 540 must be limited. 542 * Tools must support error checking against document layout 543 issues as well as other format details (diagrams, line breaks, 544 variable and fixed width font layout). 546 3.3. Requirements to be retired 548 Some of the original requirements are removed from consideration: 550 * Pagination ("Each page must be limited to 58 lines followed by 551 a form feed on a line by itself.") 553 * Maximum line length ("Each line must be limited to 72 554 characters followed by carriage return and line feed.") 556 * Limitation to 100% ASCII text ("The character codes are 557 ASCII.") 559 4. Security Considerations 561 This document sets out requirements for RFCs in their various 562 formats, it does not concern interactions between Internet 563 hosts. Therefore it does not have any specific Security 564 Considerations. 566 5. IANA Considerations 568 This document does not request entries in any IANA Registry. 570 6. References 572 6.1. Informative References 574 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 575 RFC 2223, October 1997. 577 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 578 Headers, and Boilerplates", RFC 5741, December 2009. 580 [ASCII] American National Standard for Information Systems - Coded 581 Character Sets - 7-Bit American National Standard Code for 582 Information Interchange (7-Bit ASCII), ANSI X3.4-1986, 583 American National Standards Institute, Inc., March 26, 584 1986. 586 [2223bis] Reynolds, J. Bradon, R., "Instructions to Request for 587 Comments (RFC) Authors", Work In Progress, August 2004. 589 [Style] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work In 590 Progress, draft-flanagan-style-00, October 2012. 592 [WCAG20] W3C, "Web Content Accessibility Guidelines (WCAG) 2.0", 593 December 11 2008, http://www.w3.org/TR/WCAG20/ 595 [UN2006] United Nations, "Convention on the Rights of Persons with 596 Disabilities", December 2006. 598 Acknowledgements 600 The authors received a great deal of helpful input from the community 601 in pulling together these requirements and wish to particularly 602 acknowledge the help of Joe Hildebrand, Paul Hoffman and John 603 Klensin, who each published an I-D on the topic of potential format 604 options before the IETF 84 BOF. 606 Authors' Addresses 608 Heather Flanagan 609 RFC Series Editor 611 Email: rse@rfc-editor.org 613 Nevil Brownlee 614 Independent Submissions Editor 616 Email rfc-ise@rfc-editor.org