Internet Architecture Board (IAB) H. FlanaganInternet-DraftRequest for Comments: 7994 RFC EditorIntended status:Category: InformationalMay 16, 2016 Expires: November 17,December 2016 ISSN: 2070-1721 Requirements for Plain-Text RFCsdraft-iab-rfc-plaintext-03Abstract In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined inRFC6949,RFC 6949, "RFC Series Format Requirements and FutureDevelopment."Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. Thisdraft documentsdocument outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.Editorial Note (To be removed by the RFC Editor) Discussion of this draft takes place on the rfc-interest mailing list (rfc-interest@rfc-editor.org), which has its home page at https://www.rfc-editor.org/mailman/listinfo/rfc-interest.Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the InternetEngineering Task Force (IETF). NoteArchitecture Board (IAB) and represents information thatother groups may also distribute working documents as Internet-Drafts. The listthe IAB has deemed valuable to provide for permanent record. It represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe Internet Architecture Board (IAB). Documents approved for publication by the IAB are not amaximumcandidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 17, 2016.http://www.rfc-editor.org/info/rfc7994. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 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....................................................2 2. Character Encoding. . . . . . . . . . . . . . . . . . . . . 4..............................................4 3. Figures and Artwork. . . . . . . . . . . . . . . . . . . . . 4.............................................4 4. General Page Format Layout. . . . . . . . . . . . . . . . . 5......................................4 4.1. Headers and Footers. . . . . . . . . . . . . . . . . . . 5........................................5 4.2. Table of Contents. . . . . . . . . . . . . . . . . . . . 5..........................................5 4.3. Line Width. . . . . . . . . . . . . . . . . . . . . . . 5.................................................5 4.4. Line Spacing. . . . . . . . . . . . . . . . . . . . . . 5...............................................5 4.5. Hyphenation. . . . . . . . . . . . . . . . . . . . . . . 5................................................5 5. Elements from the xml2rfc v3vocabulary . . . . . . . . . . . 6Vocabulary .........................5 6.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.Security Considerations. . . . . . . . . . . . . . . . . . . 6 9. Change Log for the Draft . . . . . . . . . . . . . . . . . . 6 9.1. draft-iab-rfc-plaintext-02 to -03 . . . . . . . . . . . . 6 9.2. draft-iab-rfc-plantext-01 to -02 . . . . . . . . . . . . 6 9.3. draft-iab-rfc-plaintext-00 to -01 . . . . . . . . . . . . 6 9.4. draft-flanagan-plaintext-09 to draft-iab-rfc-plaintext-00 7 9.5. -08 to -09 . . . . . . . . . . . . . . . . . . . . . . . 7 9.6. -07 to -08 . . . . . . . . . . . . . . . . . . . . . . . 7 9.7. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . 7 9.8. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 7 9.9. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 7 9.10. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 7 9.11. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 7 9.12. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 8 10..........................................6 7. References. . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1.......................................................6 7.1. Normative References. . . . . . . . . . . . . . . . . . 8 10.2........................................6 7.2. Informative References. . . . . . . . . . . . . . . . . 9.....................................7 IAB Members at the Time of Approval ................................8 Acknowledgements ...................................................8 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 9...................................................8 1. Introduction In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format [XML-ANNOUNCE]. The high-level requirements that informed this change were defined in [RFC6949], "RFC Series Format Requirements and FutureDevelopment."Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. Thisdraft documentsdocument outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition. The Unicode Consortium defines'plain text'"plain text" as "Computer-encoded text that consists only of a sequence of code points from a given standard, with no other formatting or structural information.Plain textPlain-text interchange is commonly used between computer systems that do not share higher-level protocols."[UNICODE-GLOSSARY][UNICODE-GLOSSARY]. In other words, plain-text files cannot include embedded character formatting or style information. The actual character encoding, however, is not limited to any particular sequence of code points. A plain-text output for RFCs will continue to be required for the foreseeable future. The process of convertingXML2RFCxml2rfc version 2 (xml2rfc v2) into text documents is well understood [RFC7749]. We plan to rely on the practice to date to inform the requirements for convertingXML2RFCxml2rfc version 3 (xml2rfc v3) to text[I-D.iab-xml2rfc].[RFC7991]. This document calls out those requirements that are changed from v2 or otherwise deserve special attention, such as the requirements around the character encoding that may beused,used; changes in the pagelayout,layout; and changes inhandlinghow figures, artwork, andpagination.pagination may be handled. For more details on general style, see"The RFC"RFC StyleGuide." [RFC7322]Guide" [RFC7322]. The following assumptions drive the changes in the plain-text output for RFCs: o The existing tools used by the RFC Editor and many members of the author community to create the text file are complicated to change and support; manual manipulation is often required for the final output. In particular, handling page breaks and associated widows and orphans for paginated output is tricky [WIDOWS]. o Additional publicationformats--for example:formats -- for example, PDF,HTML--willHTML -- will be available that will offer features such asmarkup,markup and prettyprinting, etc.printing. o There is an extensive tool chain in existence among the community to work with plain-text documents. Similar functionality may be possible with other publication formats, but the workflow that uses the existing tool chain should be supported as much as is considered practical. Where practical, the original guidance for the structure of aplain- textplain-text RFC has beenkept, such askept (e.g., with line lengths, with lines perpage, etc. [INS2AUTH]page [INS2AUTH]). Other publication formats, such as HTML and PDF, will include additional features that will not be present in the plain text (e.g., paragraph numbering, typographical emphasis). The details described in this document are expected to change based on experience gained in implementing theRFC production center's toolset.new publication toolsets. Revised documents will be published capturing those changes as thetoolset istoolsets are completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document. 2. Character Encoding Plain-text files for RFCs will use the UTF-8 [RFC3629] character encoding. That said, the use of non-ASCII characters will be only allowed in a limited and controlled fashion. Many elements within the xml2rfc v3 vocabulary have an attribute for the ASCII equivalent to a non-ASCII character string. The ASCII equivalent will be rendered within theplain-textplain text as per the guidance in "The Use of Non-ASCII Characters in RFCs"[I-D.iab-rfc-nonascii]. Please[RFC7997]; please view the PDF version of thatdraft.document. The plain-text file will include abyte order markByte Order Mark (BOM) to provide text reader software with in-band information about the character encoding scheme used. 3. Figures and Artwork Artwork, such as network diagrams or performance graphs, must be tagged by the XML <artwork> element (see Section 2.5 of "The'XML2RFC' version'xml2rfc' Version 3 Vocabulary"[I-D.iab-xml2rfc].[RFC7991]. Where this artwork is comprised of an ASCII art diagram, it must be tagged as'type=ascii-art'."type='ascii-art'". The plain-text format will only include ASCII art. If the canonical format includes figures or artwork other thanASCII-ASCII art, then the plain-text output must include a pointer to the relevant figure in the HTML version of the RFC to allow readers to see the relevant artwork. Authors who wish to includeASCII-artASCII art for the plain-text file and SVG art for the other outputs may do so, but they should be aware of the potential for confusion to individuals reading the RFC with two unique diagrams describing the same content. If there is conflicting information between the publication formats, please review the XML and PDF files to resolve the conflict. 4. General Page Format Layout One plain-text output will be created during the publication process with basic pagination that includes a form feed instruction every 58 lines at most, including blank lines. Instructions or a script will be made available by and for the community to strip out pagination as per individual preference. 4.1. Headers and Footers The front matter on the front page (such as the RFC number andcategory),category) and the back matter on the last page (theauthor'sauthors' full names and contact information) will continue with the structure described in RFC5741 [RFC5741],7841 [RFC7841], "RFC Streams, Headers, and Boilerplates". Running headers and footers will no longer be added. 4.2. Table of Contents In order to retain similar content wherever possible between the various publication formats, theTabletable ofContentscontents will list section and subsection numbers andtitles,titles but will not include page numbers. 4.3. Line Width Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). The EOL sequence used by the RFC Editor will be the two-character sequence CR LF (Carriage Return followed by Line Feed). This limit includes any left-side indentation. Note that the EOL used by the RFC Editor may change with different transports and as displayed in different display software. 4.4. Line Spacing Use single-spaced text within a paragraph, and one blank line between paragraphs. 4.5. Hyphenation Hyphenated words (e.g.,"Internet-Draft"),"Internet-Draft") should not be split across successive lines. 5. Elements from the xml2rfc v3vocabularyVocabulary The plain-text formatter uses the relevant tags from thexml2rfcv3xml2rfc v3 source file to build a document conforming to the layout and structure described by the full RFC Style Guide [RFC7322] (including the updates in the web portion of the StyleGuide). [STYLEWEB]Guide) [STYLEWEB]. 6.Acknowledgements This draft owes a great deal of thanks to the efforts of the RFC Format Design Team: Nevil Brownlee, Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks, and David Thaler. 7. IANA Considerations This memo includes no requests to IANA. 8.Security Considerations The requirements of theplaintextplain-text format involve no significant security considerations. As part of the larger format project, however, unintended changes to the text as a result of the transformation from the base XML file could in turn corrupt a standard,practicepractice, or critical piece of information about a protocol.9. Change Log for the Draft 9.1. draft-iab-rfc-plaintext-02 to -03 Figures and Artwork: clarified the state specifically around ASCII art Elements from the xml2rfc v3: removed confusing sentence that called out particular elements for creation of front/back matter 9.2. draft-iab-rfc-plantext-01 to -02 nits fixed 9.3. draft-iab-rfc-plaintext-00 to -01 Introduction: removed sentence restricting this format to RFCs only; clarified that plaintext will be based on existing practice (except where otherwise called out) Elements from the xml2rfc v3 vocabulary: clarified what xml2rfcv3 tags will render the front and back matter of a document. 9.4. draft-flanagan-plaintext-09 to draft-iab-rfc-plaintext-00 Figures and Artwork, Character Encoding: included additional detail regarding how these items will be flagged within the XML. 9.5. -08 to -09 Security Considerations: added text 9.6. -07 to -08 Change log: forgot to update the change log for the -06 to -07 changes. 9.7. -06 to -07 Introduction: updated to state that this document does not require backwards compatibility. 9.8. -05 to -06 Abstract: Changed "cut over" to "transition" Elements from xml2rfc v3: emphasized that doc structure is guided by the RFC Style Guide 9.9. -04 to -05 Abstract and Introduction: Revised for better readability; clarified the definition and implications of the term "plain-text" General Page Format Layout: Added explicit EOL detail and added some clarification regarding pagination Elements from the xml2rfc v3 vocabulary: section added 9.10. -03 to -04 Change Log for the Draft: forgot to complete the change log between the various revisions of the draft 9.11. -02 to -03 Abstract: expanded Introduction: adjusted language of assumptions Figures and Artwork: adjusted to indicate where to go in case information for the images conflicts between different formats General Page Layout: switched back to producing one basic paginated format, with an expectation of instructions and/or a script to create local, unpaginated copies for individual use. 9.12. -01 to -02 Introduction: added pointer to original page layout information Character encoding: clarified language around encoding and use of BOMs General Page Format Layout: removed increased line width requirement; added sections on Line Width, Line Spacing, and Hyphenation (pulled from 2223-bis 10.7. References10.1.7.1. Normative References[I-D.iab-rfc-nonascii] Flanagan, H., "The Use of Non-ASCII Characters in RFCs", draft-iab-rfc-nonascii-02 (work in progress), April 2016. [I-D.iab-xml2rfc] Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft- iab-xml2rfc-03 (work in progress), February 2016.[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, DOI 10.17487/RFC5741, December 2009, <http://www.rfc-editor.org/info/rfc5741>.[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <http://www.rfc-editor.org/info/rfc6949>. [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>. [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, <http://www.rfc-editor.org/info/rfc7749>.10.2.[RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, <http://www.rfc-editor.org/info/rfc7841>. [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>. [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <http://www.rfc-editor.org/info/rfc7997>. 7.2. Informative References [INS2AUTH] RFC Editor, "Instructions to Request for Comments (RFC) Authors", August 2004,<http://www.rfc-editor.org/rfc- editor/instructions2authors.txt>.<https://www.rfc-editor.org/ materials/instructions2authors.txt>. [STYLEWEB] RFC Editor, "Web Portion of the Style Guide",May 2015,February 2016, <http://www.rfc-editor.org/styleguide/part2/>. [UNICODE-GLOSSARY] The Unicode Consortium, "Glossary of Unicode Terms",2014,September 2016, <http://www.unicode.org/glossary/>. [WIDOWS] Wikipedia, "Widows and orphans",October 2014, <http://en.wikipedia.org/wiki/Widows_and_orphans>.September 2016, <https://en.wikipedia.org/w/ index.php?title=Widows_and_orphans&oldid=738356204>. [XML-ANNOUNCE] Flanagan, H., "Subject: Direction of the RFC Format Development effort", May 2013,<http://www.rfc- editor.org/pipermail/rfc-interest/2013-May/005584.html >.<http://www.rfc-editor.org/pipermail/ rfc-interest/2013-May/005584.html>. IAB Members at the Time of Approval The IAB members at the time this memo was approved were (in alphabetical order): Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf Acknowledgements This document owes a great deal of thanks to the efforts of the RFC Format Design Team: Nevil Brownlee, Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks, and David Thaler. Author's Address Heather Flanagan RFC Editor Email: rse@rfc-editor.org URI: http://orcid.org/0000-0002-2647-2220