[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09
draft-iab-rfc-plaintext
Network Working Group H. Flanagan
Internet-Draft RFC Editor
Intended status: Informational September 11, 2014
Expires: March 15, 2015
Requirements for Plain-Text RFCs
draft-flanagan-plaintext-02
Abstract
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
(rfc-interest@rfc-editor.org), which has its home page at
https://www.rfc-editor.org/mailman/listinfo/rfc-interest.
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 http://datatracker.ietf.org/drafts/current/.
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 March 15, 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
(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
Flanagan Expires March 15, 2015 [Page 1]
Internet-Draft Abbreviated Title September 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Character Encoding . . . . . . . . . . . . . . . . . . . . . 3
3. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 3
4. General Page Format Layout . . . . . . . . . . . . . . . . . 4
4.1. Headers and Footers . . . . . . . . . . . . . . . . . . . 4
4.2. Table of Contents . . . . . . . . . . . . . . . . . . . . 4
4.3. Line Width . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. Line Spacing . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Hyphenation . . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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 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.
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 draft.
The following assumptions drive the changes in the plain-text output
for RFCs:
Flanagan Expires March 15, 2015 [Page 2]
Internet-Draft Abbreviated Title September 2014
o The existing tools used by the RFC Editor and many members of the
author community to create the text file are extremely sensitive;
manual manipulation is required in the final output. In
particular, handling page breaks and associated widows and orphans
for paginated output is tricky.
o Additional publication formats--for example: PDF, HTML-- will be
available that will offer features such as markup, pretty
printing, etc.
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 must be supported as much as is
considered practical.
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 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.
Flanagan Expires March 15, 2015 [Page 3]
Internet-Draft Abbreviated Title September 2014
4. General Page Format Layout
Arguments both in favor of and against pagination have been offered
by members of the community and summarized in RFC 6949. After
further discussion, two plain-text outputs will be created during the
publication process - one with basic pagination that includes a form
feed instruction every 58 lines at most, including blank lines,
depending on the text and artwork layout, and a second with no
pagination at all. This will allow for both easier cut and paste
from the plain-text file, uninterupted diff output, disambiguation
between page breaks that may also be paragraph breaks, and a better
printing experience for those working with the plain-text output .
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.
Flanagan Expires March 15, 2015 [Page 4]
Internet-Draft Abbreviated Title September 2014
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
TBD.
8. References
8.1. Normative References
[I-D.flanagan-nonascii]
Flanagan, H., "The Use of Non-ASCII Characters in RFCs",
draft-flanagan-nonascii-03 (work in progress), July 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.
8.2. Informative References
[INS2AUTH]
RFC Editor, "Instructions to Request for Comments (RFC)
Authors", August 2004, <http://www.rfc-editor.org/rfc-
editor/instructions2authors.txt>.
Flanagan Expires March 15, 2015 [Page 5]
Internet-Draft Abbreviated Title September 2014
[XML-ANNOUNCE]
Flanagan, H., ""Subject: Direction of the RFC Format
Development effort", message to the rfc-interest@rfc-
editor.org mailing list", May 2013, <http://www.rfc-
editor.org/pipermail/rfc-interest/2013-May/005584.html >.
[unicode-glossary]
The Unicode Consortium, "Glossary of Unicode Terms", 2014,
<http://www.unicode.org/glossary/>.
Author's Address
Heather Flanagan
RFC Editor
Email: rse@rfc-editor.org
Flanagan Expires March 15, 2015 [Page 6]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/