]> RFC Editor

rse@rfc-editor.org http://orcid.org/0000-0002-2647-2220

RFC ASCII format plain-text plain text 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 in RFC 6949, "RFC Series Format Requirements and Future 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. This document 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.

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 . The high-level requirements that informed this change were defined in , "RFC Series Format Requirements and Future 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. This document 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" 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&nbhy;text interchange is commonly used between computer systems that do not share higher-level protocols." . 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 converting xml2rfc version 2 (xml2rfc v2) into text documents is well understood . We plan to rely on the practice to date to inform the requirements for converting xml2rfc version 3 (xml2rfc v3) to text . 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 be used; changes in the page layout; and changes in how figures, artwork, and pagination may be handled. For more details on general style, see "RFC Style Guide" . The following assumptions drive the changes in the plain-text output for RFCs: 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 . Additional publication formats -- for example, PDF, HTML -- will be available that will offer features such as markup and pretty printing. 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 a plain&nbhy;text RFC has been kept (e.g., with line lengths, with lines per page ). 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 the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document.

Plain-text files for RFCs will use the UTF-8 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 the plain text as per the guidance in "The Use of Non-ASCII Characters in RFCs"; please view the PDF version of that document. The plain-text file will include a Byte Order Mark (BOM) to provide text reader software with in-band information about the character encoding scheme used.

Artwork, such as network diagrams or performance graphs, must be tagged by the XML <artwork> element (see Section 2.5 of "The 'xml2rfc' Version 3 Vocabulary" . Where this artwork is comprised of an ASCII art diagram, it must be tagged as "type='ascii&nbhy;art'". The plain-text format will only include ASCII art. If the canonical format includes figures or artwork other than 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 include ASCII 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.

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.

The front matter on the front page (such as the RFC number and category) and the back matter on the last page (the authors' full names and contact information) will continue with the structure described in RFC 7841, "RFC Streams, Headers, and Boilerplates". Running headers and footers will no longer be added.

In order to retain similar content wherever possible between the various publication formats, the table of contents will list section and subsection numbers and titles but will not include page numbers.

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.

Use single-spaced text within a paragraph, and one blank line between paragraphs.

Hyphenated words (e.g., "Internet-Draft") should not be split across successive lines.

The plain-text formatter uses the relevant tags from the xml2rfc v3 source file to build a document conforming to the layout and structure described by the full RFC Style Guide (including the updates in the web portion of the Style Guide) .

The requirements of the plain-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, practice, or critical piece of information about a protocol.

&RFC3629; &RFC7841; &RFC6949; &RFC7322; &RFC7749; The Unicode Consortium RFC Editor RFC Editor Wikipedia

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

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.