Internet DRAFT - draft-iab-rfcformatreq
draft-iab-rfcformatreq
INTERNET-DRAFT H. Flanagan
Intended Status: Informational RFC Series Editor
Updates: 2223 N. Brownlee
Independent Submissions Editor
Expires: September 12, 2013 March 11, 2013
RFC Series Format Requirements and Future Development
draft-iab-rfcformatreq-03
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. This document updates RFC 2223.
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) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Brownlee & Flanagan Expires September 12, 2013 [Page 1]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
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. 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 . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Informative References . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Brownlee & Flanagan Expires September 12, 2013 [Page 2]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
1 Introduction
Over 40 years ago, the RFC Series began as a collection of memos in
an environment that included handwritten RFCs, typewritten RFCs, RFCs
produced on mainframes with complicated layout tools, and more. As
the tools changed and some of the source formats became unreadable,
the core individuals behind the Series realized that a common format
that could be read, revised, and archived long in the future was
required. US-ASCII was chosen for the encoding of characters and
after a period of variability, a well-defined presentation format was
settled upon. 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 into 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 format stabilized, 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]. Section 2 reviews recent requests for enhancements as
understood from community discussion and various proposals for new
formats including HTML, XML, PDF and EPUB. The actual requirements
are then captured in Section 3. 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. [ASCII]
Submission format = the format submitted to the RFC Editor for
editorial revision and publication
* Currently: formatted plain text (required), XML (optional),
NROFF (optional)
Brownlee & Flanagan Expires September 12, 2013 [Page 3]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
Revisable format = the format that will provide the information for
conversion into a Publication format; it is used or created by the
RFC Editor (see Section 2.3 for an explanation of current practice)
* Currently: XML (optional), NROFF (required)
Publication format = display and distribution format as it may be
read or printed after the publication process has completed
* Currently published by the RFC Editor: formatted plain text,
PDF of the formatted plain text, 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: formatted plain text
Metadata = Information associated with a document so as to provide,
for example, definitions of its structure, or of elements within the
document such as its topic or author
2. History and Goals
Below are the 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.
* Do not use footnotes. If such notes are necessary, put them at
Brownlee & Flanagan Expires September 12, 2013 [Page 4]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
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.
The precedent for additional formats, specifically PostScript, is
described in RFC 2223 and has been used for a small number of 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 report that they find the
strict limits of character encoding, line limits, and so on to be
acceptable, others claim to find those limitations a significant
obstacle to their desire to communicate and read the information via
an RFC. With a broader community of authors currently producing RFCs
and a wider range of presentation devices, the issues being reported
indicate limitations of the current Canonical format that must be
reviewed and potentially incorporated in to the Canonical RFC format.
While the specific points of concern vary, the main issues discussed
are:
* ASCII art
Brownlee & Flanagan Expires September 12, 2013 [Page 5]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
* 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. These
points are not part of the list of requirements; they are the inputs
that informed the requirements discussed in Section 3 of this
document.
2.1.1. ASCII art
Arguments in favor of limiting all diagrams, equations, tables and
charts to ASCII art depictions only 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 allowing the use of more complex diagrams in
place of the current use of ASCII art 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 grayscale or color to be introduced
into the diagrams.
Brownlee & Flanagan Expires September 12, 2013 [Page 6]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
Two suggestions have 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
properly rendered and 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.
Brownlee & Flanagan Expires September 12, 2013 [Page 7]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
* Certain special characters in equations or quoted from other
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 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.
* Removing pagination results in people often using subsections
rather than page number for reference purposes, forcing what
would otherwise be long sections to be broken into subsections.
This would encourage documents that are better organized and
simpler.
2.1.4. Reflowable text
Arguments against requiring text to be reflowable:
* Reflowable text may impact the usability of graphics and tables
within a document.
Arguments for requiring text to be reflowable:
* 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
Brownlee & Flanagan Expires September 12, 2013 [Page 8]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
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 RFC's accessibility or readability, several
individuals have indicated that allowing metadata within the RFC
would make their reading of the documents more efficient.
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 as a result
of requiring backward compatibility for metadata tags.
2.2. Further considerations
Some of the discussion beyond the issues described above went into a
review of potential solutions. Those solutions and the debate around
them added a few more points to the list of potential requirements
for a change in RFC Format. In particular, the discussion of tools
introduced the idea of 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.
Brownlee & Flanagan Expires September 12, 2013 [Page 9]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
* 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
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 Revisable format be in a markup language 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 (of the RFCs published in 2012, approximately 65% were
submitted with an XML file), this conversion is problematic in terms
of time spent and data lost from XML. Making the publication process
for the RFC Editor more efficient is strongly desired.
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.
Detailed rules regarding how these changes will be implemented will
be documented in a future RFC.
3.1. Original requirements to be retained
Brownlee & Flanagan Expires September 12, 2013 [Page 10]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
There are several components of the original format requirements that
must be retained to ensure the ongoing continuity, reliability and
readability of the Series:
* The content of an RFC 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
for the indefinite future. This means the format must be both
readable and editable across commonly used devices, operating
system systems and platforms for the foreseeable future.
* While several Publication formats must be allowed, in order to
continue support for the most basic reading and search tools
and to provide continuity for the Series, at least one
Publication format must be plain-text.
* 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. [Style]
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.
* The documents must be accessible to people with physical or
age-related disabilities, including alternative text for images
and limitations on color. See the W3C's Accessibility
documents [WCAG20] and the United Nations "Convention on the
Rights of Persons with Disabilities" [UN2006] for guidance.
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. ASCII is
required for all text that must be read to understand or
implement the technology described in the RFC. Use of non-
ASCII characters, expressed in a standard Unicode Encoding Form
(such as UTF-8), must receive explicit approval from the
document stream manager and will be allowed after the rules for
the common use cases are defined in the Style Guide.
Brownlee & Flanagan Expires September 12, 2013 [Page 11]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
* The Submission and Publication formats need to permit extending
the set of metadata tags, 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 a more complex form to be
defined, such as SVG line art [SVG]. Color and grayscale will
not be accepted; RFCs must correctly display in monochromatic
black-and-white to allow for monochrome displays, black-and-
white printing, and support for physical and age-related
disabilities.
* The Canonical format must be renderable into self-contained
Publication formats in order to be easily downloaded and read
offline.
* Fixed-width fonts and non-reflowable text are required for
ASCII-art sections, source code examples, and other places
where strict alignment is required.
* At least one Publication format must support readable print to
standard paper sizes.
* The Canonical format should be structured to enable easy
program identification and parsing of code or specifications,
such as MIB, ABNF, etc.
The requirements of the RFC Editor regarding RFC format and the
publication process 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 produced by the RFC editor
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).
Brownlee & Flanagan Expires September 12, 2013 [Page 12]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
3.3. Requirements to be retired
Some of the original requirements will be removed from consideration,
but detailed rules regarding how these changes will be implemented
will be documented in a future RFC.
* 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
This document does not request entries in any IANA Registry.
6. References
6.1. 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.
[ASCII] American National Standard for Information Systems - Coded
Character Sets - 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII), ANSI X3.4-1986,
American National Standards Institute, Inc., March 26,
1986.
Brownlee & Flanagan Expires September 12, 2013 [Page 13]
INTERNET DRAFT RFC Series Format Requirements March 11, 2013
[2223bis] Reynolds, J. Bradon, R., "Instructions to Request for
Comments (RFC) Authors", Work In Progress, August 2004.
[Style] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work In
Progress, draft-flanagan-style-00, October 2012.
[SVG] W3C, "Scalable Vector Graphics (SVG) 1.1 (Second Edition)",
August 16, 2011, http://www.w3.org/TR/SVG11/
[WCAG20] W3C, "Web Content Accessibility Guidelines (WCAG) 2.0",
December 11, 2008, http://www.w3.org/TR/WCAG20/
[UN2006] United Nations, "Convention on the Rights of Persons with
Disabilities", December 2006.
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
Brownlee & Flanagan Expires September 12, 2013 [Page 14]
