Network Working Group H. Flanagan
Internet-Draft RFC Editor
Intended status: Informational October 1, 2014
Expires: April 4, 2015

Requirements for Plain-Text RFCs


In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format to XML. The high-level requirements for the format of RFCs were defined in RFC6949, "RFC Series Format Requirements and Future Development." Several different publication formats will be rendered from that canonical XML, including HTML, PDF, TXT, and EPUB. This draft documents the change in requirements and layout for the plain-text RFC publication format.

Editorial Note (To be removed by the RFC Editor)

Discussion of this draft takes place on the rfc-interest mailing list (, which has its home page at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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."

This Internet-Draft will expire on April 4, 2015.

Copyright Notice

Copyright (c) 2014 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 ( 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

The decision was made in May 2013 to shift from the plain-text, ASCII-only canonical format to XML [XML-ANNOUNCE]. The high-level requirements for the format of RFCs were defined in "RFC Series Format Requirements and Future Development" [RFC6949]. Several different publication formats will be rendered from that canonical XML, including HTML, PDF, TXT, and EPUB [I-D.flanagan-rfc-framework].

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 text interchange is commonly used between computer systems that do not share higher-level protocols." [unicode-glossary]

A plain-text output for RFCs will continue to be required for the foreseeable future. The details of what that means for RFCs in terms of which character encoding may be used, what the page layout will look like, how to handle figures and artwork, and how pagination will be handled, are documented in this memo.

The following assumptions drive the changes in the plain-text output for RFCs:

Where practical, the original guidance for the structure of a plain-text RFC has been kept, such as with line lengths, lines per page, etc. [INS2AUTH]

Note that this document provides guidance for plain-text RFCs; Internet-Drafts are out of scope.

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. The details regarding the guidance for how to include non-ASCII characters is under development and documented in "The Use of Non-ASCII Characters in RFCs" [I-D.flanagan-nonascii]. Please view the PDF version of that draft.

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.

3. Figures and Artwork

Authors may continue to include figures drawn with ASCII characters. 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 or 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 and category), and the back matter on the last page (the author's full names and contact information) will continue with the structure described in RFC 5741 [RFC5741], "RFC Streams, Headers, and Boilerplates". Given the removal of the pagination requirement, running headers and footers will no longer exist.

4.2. Table of Contents

Given the removal of the pagination requirement, the Table of Contents will list section and subsection numbers and 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). This limit includes any left-side indentation.

Note: A plain-text RFC is expected to be stored on a disk file using the EOL sequence of that system. For example, MS DOS-based systems use the two-character sequence: CR LF (Carriage Return followed by Line Feed), Unix systems use the single character LF for EOL, and EBCDIC systems use the single character NL (New Line).

Whenever an RFC is transmitted across the Internet, Internet protocol convention requires that each line of text be followed by the two-character EOL sequence CR LF (Carriage Return followed by Line Feed). A user level protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make the appropriate EOL transformation at each line end. Note that binary transmission of plain-text RFC files can cause the sender's EOL convention to "leak" into the receiver, causing confusion.

4.4. Line Spacing

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

4.5. Hyphenation

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

5. 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.

6. IANA Considerations

This memo includes no requests to IANA.

7. Security Considerations


8. Change Log for the Draft

8.1. -03 to -04

Change Log for the Draft: forgot to complete the change log between the various revisions of the draft

8.2. -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.

8.3. -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

9. References

9.1. Normative References

[I-D.flanagan-nonascii] Flanagan, H., "The Use of Non-ASCII Characters in RFCs", Internet-Draft draft-flanagan-nonascii-01, April 2014.
[I-D.flanagan-rfc-framework] Flanagan, H., "RFC Format Framework", Internet-Draft draft-flanagan-rfc-framework-01, September 2014.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC5741] Daigle, L., Kolkman, O. and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, May 2013.

9.2. Informative References

[INS2AUTH] RFC Editor, "Instructions to Request for Comments (RFC) Authors", August 2004.
[XML-ANNOUNCE] Flanagan, H., ""Subject: Direction of the RFC Format Development effort", message to the mailing list", May 2013.
[unicode-glossary] The Unicode Consortium, "Glossary of Unicode Terms", 2014.

Author's Address

Heather Flanagan RFC Editor EMail: