INTERNET-DRAFT H. Flanagan Intended Status: Informational RFC Series Editor N. Brownlee Independent Submissions Editor Expires: May 31, 2013 November 27, 2012 RFC Series Format Development draft-rfc-format-flanagan-02 Abstract This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Expires May 31, 2013 [Page 1] INTERNET DRAFT November 27, 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. History and Goals . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Issues driving change . . . . . . . . . . . . . . . . . . 5 2.1.1. Line art, aka ASCII art . . . . . . . . . . . . . . . 6 2.1.2. Character encoding . . . . . . . . . . . . . . . . . . 7 2.1.3. Pagination . . . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Reflowable text . . . . . . . . . . . . . . . . . . . 8 2.1.5. Metadata and tagging . . . . . . . . . . . . . . . . . 8 2.2. Further considerations . . . . . . . . . . . . . . . . . . 9 2.2.1. Creation and use of RFC-specific tools . . . . . . . . 9 2.2.2. Markup Language . . . . . . . . . . . . . . . . . . . 10 2.3. RFC Editor goals . . . . . . . . . . . . . . . . . . . . . 10 3. Format requirements . . . . . . . . . . . . . . . . . . . . . 10 3.1. Original requirements to be retained . . . . . . . . . . . 10 3.2. Requirements to be added . . . . . . . . . . . . . . . . . 11 3.3. Requirements to be retired . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Expires May 31, 2013 [Page 2] INTERNET DRAFT November 27, 2012 1 Introduction Over 40 years ago, the RFC Series began in an environment that included handwritten RFCs, typewritten RFCs, RFCs produced on mainframes, and more. This resulted in an understanding that however they were published, a common format that could be read and revised long in the future was required. US-ASCII was chosen as that format, and since that time that format has proved to be persistent and reliable across a large variety of devices, operating systems, and editing tools. That stability has been a continuing strength of the Series. However, as new technology such as small devices and advances in display technology come in to common usage, there is a growing desire to see the format of the RFC Series adapt to take advantage of these different ways to communicate information. Since the earliest days of the Series, authors and readers have suggested enhancements to the format. However, no suggestion developed clear consensus in the Internet technical community. As always, some individuals see no need for change while others press strongly for specific enhancements. This document takes a look at the current requirements for RFCs as described in RFC 2223 [RFC2223] and more recently in 2223bis [2223bis]. It also reviews recent requests for enhancements as understood from community discussion and various proposals for new formats including HTML, XML, PDF and EPUB. The focus of this document is on the Canonical format of RFCs, but some mention of other phases in the RFC publication process and the document formats associated with these phases is also included. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. 1.1 Terminology [ASCII] = Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986. Submission format = the format submitted to the RFC Editor for editorial revision and publication. * might not be the same as the canonical format (though it would make the workflow somewhat simpler for the RFC Editor if it were); * will be converted to another format for further processing and publication if necessary Expires May 31, 2013 [Page 3] INTERNET DRAFT November 27, 2012 * Currently: .txt (required), XML (optional), NROFF (optional) Revisable format = the format that will provide the information for conversion into an Publication format; it is used or created by the RFC Editor * Currently: XML (optional), NROFF (required) Publication format = display and distribution format as it may be read or printed after publication process has completed. * Currently published by the RFC Editor: .txt, PDF, PDF that contains figures (rare) * Currently made available by other sites: HTML, PDF, others Canonical format = the authorized, recognized, accepted, and archived version of the document. * Currently: .txt Metadata = Information associated with a document so as to provide, for example, definitions of its structure, or of elements within it such as it topic or author. 2. History and Goals Current RFC format rules as defined in [RFC2223] and clarified in 2223bis. * The character codes are ASCII. * Each page must be limited to 58 lines followed by a form feed on a line by itself. * Each line must be limited to 72 characters followed by carriage return and line feed. * No overstriking (or underlining) is allowed. * These "height" and "width" constraints include any headers, footers, page numbers, or left side indenting. * Do not fill the text with extra spaces to provide a straight right margin. * Do not do hyphenation of words at the right margin. Expires May 31, 2013 [Page 4] INTERNET DRAFT November 27, 2012 * Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document. * Use single spaced text within a paragraph, and one blank line between paragraphs. * Note that the number of pages in a document and the page numbers on which various sections fall will likely change with reformatting. Thus cross references in the text by section number usually are easier to keep consistent than cross references by page number. * RFCs in plain ASCII-text may be submitted to the RFC Editor in e-mail messages (or as online files) in either the finished Publication format or in nroff. If you plan to submit a document in nroff please consult the RFC Editor first. Precedent for multiple Publication formats is described in RFC 2223 and has been used for a few RFCs: Note that since the ASCII text version of the RFC is the primary version, the PostScript version must match the text version. The RFC Editor must decide if the PostScript version is "the same as" the ASCII version before the PostScript version can be published. Neither RFC 2223 or 2223bis use the term 'metadata,' though the RFC Editor currently refers to components of the text such as the Stream, Status (e.g. Updates, Obsoletes), Category and ISSN as 'metadata.' 2.1. Issues driving change While some authors and readers of RFCs find the strict limits of character encoding, line limits, and so on to be acceptable, others find those limitations a significant obstacle to their desire to communicate information via an RFC. With a broader community of authors currently producing RFCs and a wider range of presentation devices, the issues driving change represent both critical deficiencies in the current Canonical format as well as strongly desirable changes on the part of some segments of the Internet community. While the specific points of concern vary, the main issues are: * Line art, also known as ASCII art Expires May 31, 2013 [Page 5] INTERNET DRAFT November 27, 2012 * Character encoding * Pagination * Reflowable text * Metadata Each area of concern has people in favor of change and people opposed to it, all with reasonable concerns and requirements. Below is a summary of the arguments for and against each major issue. The potential requirements derived from these discussions are listed later in this document. 2.1.1. Line art, aka ASCII art Arguments in favor of keeping the current requirement for all diagrams, equations, tables, and charts include: * Dependence on advanced diagrams (or any diagrams) causes accessibility issues * Requiring ASCII art results in people often relying more on clear written descriptions rather than just the diagram itself. * Use of the ASCII character set forces design of diagrams that are simple and concise.. Arguments in favor of replacing ASCII art with more complex diagrams include: * State diagrams with multiple arrows in different directions and labels on the lines will be more understandable. * Protocol flow diagrams where each step needs multiple lines of description will be clearer. * Scenario descriptions that involve three or more parties with communication flows between them will be clearer. * Given the difficulties in expressing complex equations with common mathematical notation, allowing graphic art would allow equations to be displayed properly. * Complex art could allow for color to be introduced into the diagrams. Expires May 31, 2013 [Page 6] INTERNET DRAFT November 27, 2012 Two suggestions have been been proposed regarding how graphics should be included: one that would have graphic art referenced as a separate document to the Publication format, and one that would allow embedded graphics in the Publication format. 2.1.2. Character encoding For most of the history of the RFC Series, the character encoding for RFCs has been ASCII. Below are arguments for keeping ASCII as well as arguments for expanding to UTF-8. Arguments for retaining the ASCII-only requirement * Most easily searched and displayed across a variety of platforms. * In extreme cases of having to retype/scan hard copies of documents (it has been required in the past) ASCII is significantly easier to work with for rescanning and retaining all of the original information. There can be no loss of descriptive metadata such as keywords or content tags. * If we expand beyond ASCII, it will be difficult to know where to draw the line on what characters are and are not allowed. There will be issues with dependencies on local file systems and processors being configured to recognize any other character set. * The IETF works in ASCII (and English). The Internet research, design and development communities function almost entirely in English. That strongly suggests that an ASCII document can be read by everyone in the communities and audiences of interest. Arguments for expanding to allow UTF-8: * In discussions of internationalization, actually being able to illustrate the issue is rather helpful, and you can't illustrate a Unicode code point with "U+nnnn". * Will provide the ability to denote protocol examples using the character sets those examples support. * Will allow better support for international character sets, in particular allowing authors to spell their names in their native character sets. * Certain special characters in equations or quoted from other Expires May 31, 2013 [Page 7] INTERNET DRAFT November 27, 2012 texts could be allowed. * Citations of web pages using more international characters are possible. Arguments for strictly prescribed UTF-8 use: * In order to keep documents as searchable as possible, ASCII-only should be required for the main text of the document and some broader UTF-8 character set allowed under clearly prescribed circumstances (e.g. author names and references). 2.1.3. Pagination Arguments for continuing the use of discrete pages within RFCs: * Ease of reference and clear printing; referring to section numbers is too coarse a method Arguments for removing the pagination requirement: * Removing pagination will allow for a smoother reading experience on a wider variety of devices, platforms, and browsers 2.1.4. Reflowable text Arguments against allowing for reflowable text: * Reflowable text may impact the usability of graphics and tables within a document. Arguments for allowing reflowable text * RFCs are more readable on a wider variety of devices and platforms, including mobile devices and a wide variety of screen layouts. 2.1.5. Metadata and tagging While metadata requirements are not part of RFC 2223, there is a request that descriptive metadata tags be added as part of a revision of the Canonical RFC format. These tags would allow for enhanced content by embedding information like links, tags, or quick translations and could help control the look and feel of the Publication format. While the lack of metadata in the current RFCs does not impact an RFCs accessibility or readability, if other Expires May 31, 2013 [Page 8] INTERNET DRAFT November 27, 2012 requirements are accepted, such as allowing UTF-8 in any part of an RFC, then having the ability to use metadata to provide an ASCII "translation" of the UTF-8 letters is also a requirement. Arguments for allowing metadata in the Canonical and Publication formats: * Allowing metadata in the final Canonical and Publication format allows readers to potentially get more detail out of a document. For example, if non-ASCII characters are allowed in the Author and Reference sections, Metadata must include translations of that information. Arguments against metadata in the final Canonical and Publication formats: * Metadata adds additional overhead to the overall process of creating RFCs and may complicate future usability. 2.2. Further considerations Some of the discussion beyond the issues described above went into potential solutions. Those solutions and the debate around them added a few more points to the potential requirements for a change in RFC Format. In particular, discussing whether a change in format should also include the creation and ongoing support of specific RFC authoring and/or rendering tools and whether the Canonical format should be a format that must go through a rendering agent to be readable. 2.2.1. Creation and use of RFC-specific tools Arguments against community-supported RFC-specific tools: * We cannot be so unique in our needs that we can't use commercial tools. * Ongoing support for these tools adds a greater level of instability to the ongoing availability of the RFC Series through the decades. * The community that would support these tools cannot be relied on to be as stable and persistent as the Series itself. Arguments in support of community-supported RFC-specific tools: * Given the community that would be creating and supporting these tools, there would be greater control and flexibility over the Expires May 31, 2013 [Page 9] INTERNET DRAFT November 27, 2012 tools and how they implement the RFC format requirements. * Community supported tools currently exist and are in extensive use within the community, so it would be most efficient to build on that base. 2.2.2. Markup Language Arguments in support of a markup language as the Revisable format: * Having a markup language such as XML or HTML allows for greater flexibility in creating a variety of Publication formats, with a greater likelihood of similarity between them. Arguments against a markup language as the Revisable format: * Having the Publication format be in code instead of in a simple text-formatting structure ties us in to specific tools and/or tool support going forward. 2.3. RFC Editor goals Today, each RFC has an nroff file created prior to publication. For RFCs revised using an XML file, this file is created by converting XML to nroff at the final step. As more documents are submitted with an XML file (so far in 2012, 66% of approved I-Ds were submitted with an XML file), this conversion is problematic in terms of time spent and data lost from XML. Making this process more efficient is strongly desired by the RFC Editor. 3. Format requirements Understanding the major pain points and balancing them with the expectation of long-term viability of the documents brings us to a review of what must be kept of the original requirements, what new requirements may be added, and what requirements may be retired. 3.1. Original requirements to be retained There are several components of the original format requirements that must be retained to ensure the ongoing continuity, reliability and readability of the Series: * RFCs must not change, regardless of format, once published. * The Canonical format must be persistent and reliable across a large variety of devices, operating systems, and editing tools Expires May 31, 2013 [Page 10] INTERNET DRAFT November 27, 2012 for the indefinite future. * While several Publication formats must be allowed, the Publication formats must include support for plain-text printing. * The Boilerplate and overall structure of the RFC must be in accordance with current RFC and Style Guide requirements (see [RFC5741]). Issues such as overstriking, page justification, hyphenation, and spacing will be defined in the RFC Style Guide. [link required] 3.2. Requirements to be added In addition to those continuing requirements, discussions with various members of the wider Internet Community have yielded the following General Requirements for the RFC Series. * There must be support for Accessibility, including alternative text for images, limitations on color. Appropriate authoring tools are highly desirable but focus on the creation of Internet-Drafts, a topic outside the scope of the RFC Editor. [WCAG20] * The official language of the RFC Series is English. To respect international names and information, UTF-8/Unicode in the header and references must be allowed. Romanized ASCII translations will be required and recorded in the metadata (that translation will be used in the ASCII text version of the RFC and to aid in basic searching). * The Submission and Publication formats need to permit extensible encoding, for the addition of labeled metadata. A pre-defined set of metadata tags must be created to make use of metadata tags consistent for the life of the Series. * Graphics may include ASCII art and SVG line art. Color will not be accepted; RFCs must correctly display in monochrome to allow for monochrome displays, black-and-white printing, and Accessibility issues. * RFC must be readable self-contained (i.e. must not contain normative external links, figures, etc.) in order to be easily downloaded and read offline. * Fixed-width fonts are required for ASCII-art sections, source code examples, and other places where strict alignment is Expires May 31, 2013 [Page 11] INTERNET DRAFT November 27, 2012 required. The requirements of the RFC Editor in considering how the formats for Submission and Publication should change include: * The final conversion of all submitted documents to nroff should be replaced by using an accepted Revisable format throughout the process. * In order to maintain an efficient publication process, the RFC Editor must work with the minimal number of files required for each submission (not a tar ball of several discrete components). * In order to maintain the focus of the RFC Editor on editing for clarity and consistency rather than document layout details, the number of Publication formats must be limited. * Tools must support error checking against document layout issues as well as other format details (diagrams, line breaks, variable and fixed width font layout) at the time of Submission for author review. 3.3. Requirements to be retired Some of the original requirements may be removed from consideration: * Pagination ("Each page must be limited to 58 lines followed by a form feed on a line by itself.") * Maximum line length ("Each line must be limited to 72 characters followed by carriage return and line feed.") * Limitation to 100% ASCII text ("The character codes are ASCII.") 4. Security Considerations This document sets out requirements for RFCs in their various formats, it does not concern interactions between Internet hosts. Therefore it does not have any specific Security Considerations. 5. IANA Considerations Expires May 31, 2013 [Page 12] INTERNET DRAFT November 27, 2012 This document does not request entries in any IANA Registry. 6. References 6.1. Normative References [WCAG20] W3C, "Web Content Accessibility Guidelines (WCAG) 2.0", December 11 2008, http://www.w3.org/TR/WCAG20/ 6.2. Informative References [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009. [2223bis] Reynolds, J. Bradon, R., "Instructions to Request for Comments (RFC) Authors", Work In Progress, August 2004. Acknowledgements The authors received a great deal of helpful input from the community in pulling together these requirements and wish to particularly acknowledge the help of Joe Hildebrand, Paul Hoffman and John Klensin, who each published an I-D on the topic of potential format options before the IETF 84 BOF. Authors' Addresses Heather Flanagan RFC Series Editor Email: rse@rfc-editor.org Nevil Brownlee Independent Submissions Editor Email rfc-ise@rfc-editor.org Expires May 31, 2013 [Page 13]