draft-iab-rfcformatreq-00.txt   draft-iab-rfcformatreq-01.txt 
INTERNET-DRAFT H. Flanagan INTERNET-DRAFT H. Flanagan
Intended Status: Informational RFC Series Editor Intended Status: Informational RFC Series Editor
N. Brownlee N. Brownlee
Independent Submissions Editor Independent Submissions Editor
Expires: June 09, 2013 December 06, 2012 Expires: July 19, 2013 January 15, 2013
RFC Series Format Development RFC Series Format Development
draft-iab-rfcformatreq-00 draft-iab-rfcformatreq-01
Abstract Abstract
This document describes the current requirements and requests for This document describes the current requirements and requests for
enhancements for the format of the canonical version of RFCs. Terms enhancements for the format of the canonical version of RFCs. Terms
are defined to help clarify exactly which stages of document are defined to help clarify exactly which stages of document
production are under discussion for format changes. The requirements production are under discussion for format changes. The requirements
described in this document will determine what changes will be made described in this document will determine what changes will be made
to RFC format. to RFC format. This document updates RFC 2223.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. History and Goals . . . . . . . . . . . . . . . . . . . . . . 4 2. History and Goals . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Issues driving change . . . . . . . . . . . . . . . . . . 5 2.1. Issues driving change . . . . . . . . . . . . . . . . . . 5
2.1.1. Line art, aka ASCII art . . . . . . . . . . . . . . . 6 2.1.1. Line art, aka ASCII art . . . . . . . . . . . . . . . 6
2.1.2. Character encoding . . . . . . . . . . . . . . . . . . 7 2.1.2. Character encoding . . . . . . . . . . . . . . . . . . 7
2.1.3. Pagination . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Pagination . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Reflowable text . . . . . . . . . . . . . . . . . . . 8 2.1.4. Reflowable text . . . . . . . . . . . . . . . . . . . 8
2.1.5. Metadata and tagging . . . . . . . . . . . . . . . . . 8 2.1.5. Metadata and tagging . . . . . . . . . . . . . . . . . 8
2.2. Further considerations . . . . . . . . . . . . . . . . . . 9 2.2. Further considerations . . . . . . . . . . . . . . . . . . 9
2.2.1. Creation and use of RFC-specific tools . . . . . . . . 9 2.2.1. Creation and use of RFC-specific tools . . . . . . . . 9
2.2.2. Markup Language . . . . . . . . . . . . . . . . . . . 10 2.2.2. Markup language . . . . . . . . . . . . . . . . . . . 10
2.3. RFC Editor goals . . . . . . . . . . . . . . . . . . . . . 10 2.3. RFC Editor goals . . . . . . . . . . . . . . . . . . . . . 10
3. Format requirements . . . . . . . . . . . . . . . . . . . . . 10 3. Format Requirements . . . . . . . . . . . . . . . . . . . . . 10
3.1. Original requirements to be retained . . . . . . . . . . . 10 3.1. Original requirements to be retained . . . . . . . . . . . 10
3.2. Requirements to be added . . . . . . . . . . . . . . . . . 11 3.2. Requirements to be added . . . . . . . . . . . . . . . . . 11
3.3. Requirements to be retired . . . . . . . . . . . . . . . . 12 3.3. Requirements to be retired . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.1. Informative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1 Introduction 1 Introduction
Over 40 years ago, the RFC Series began in an environment that Over 40 years ago, the RFC Series began as a collection of memos in
included handwritten RFCs, typewritten RFCs, RFCs produced on an environment that included handwritten RFCs, typewritten RFCs, RFCs
mainframes, and more. This resulted in an understanding that however produced on mainframes with complicated layout tools, and more. As
they were published, a common format that could be read and revised the tools changed and some of the source formats became unreadable,
long in the future was required. US-ASCII was chosen for the the core individuals behind the Series realized that a common format
encoding of characters and after a period of variability, a well- that could be read, revised, and archived long in the future was
defined presentation format was settled upon. That format has proved required. US-ASCII was chosen for the encoding of characters and
to be persistent and reliable across a large variety of devices, after a period of variability, a well-defined presentation format was
operating systems, and editing tools. That stability has been a settled upon. That format has proved to be persistent and reliable
continuing strength of the Series. However, as new technology such across a large variety of devices, operating systems, and editing
as small devices and advances in display technology come in to common tools. That stability has been a continuing strength of the Series.
usage, there is a growing desire to see the format of the RFC Series However, as new technology such as small devices and advances in
adapt to take advantage of these different ways to communicate display technology come into common usage, there is a growing desire
information. to see the format of the RFC Series adapt to take advantage of these
different ways to communicate information.
Since the earliest days of the Series, authors and readers have Since the format stabilized, authors and readers have suggested
suggested enhancements to the format. However, no suggestion enhancements to the format. However, no suggestion developed clear
developed clear consensus in the Internet technical community. As consensus in the Internet technical community. As always, some
always, some individuals see no need for change while others press individuals see no need for change while others press strongly for
strongly for specific enhancements. specific enhancements.
This document takes a look at the current requirements for RFCs as This document takes a look at the current requirements for RFCs as
described in RFC 2223 [RFC2223] and more recently in 2223bis described in RFC 2223 [RFC2223] and more recently in 2223bis
[2223bis]. It also reviews recent requests for enhancements as [2223bis]. It also reviews recent requests for enhancements as
understood from community discussion and various proposals for new understood from community discussion and various proposals for new
formats including HTML, XML, PDF and EPUB. The focus of this formats including HTML, XML, PDF and EPUB. The focus of this
document is on the Canonical format of RFCs, but some mention of document is on the Canonical format of RFCs, but some mention of
other phases in the RFC publication process and the document formats other phases in the RFC publication process and the document formats
associated with these phases is also included. Terms are defined to associated with these phases is also included. Terms are defined to
help clarify exactly which stages of document production are under help clarify exactly which stages of document production are under
discussion for format changes. discussion for format changes.
1.1 Terminology 1.1 Terminology
ASCII = Coded Character Set -- 7-bit American Standard Code for ASCII = Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986. [ASCII]
Submission format = the format submitted to the RFC Editor for Submission format = the format submitted to the RFC Editor for
editorial revision and publication editorial revision and publication
* might not be the same as the canonical format (though it would * Currently: formatted plain text (required), XML (optional),
make the workflow somewhat simpler for the RFC Editor if it NROFF (optional)
were)
* will be converted to another format for further processing and
publication if necessary
* Currently: .txt (required), XML (optional), NROFF (optional)
Revisable format = the format that will provide the information for Revisable format = the format that will provide the information for
conversion into a Publication format; it is used or created by the conversion into a Publication format; it is used or created by the
RFC Editor RFC Editor (see Section 2.3 for an explanation of current practice)
* Currently: XML (optional), NROFF (required) * Currently: XML (optional), NROFF (required)
Publication format = display and distribution format as it may be Publication format = display and distribution format as it may be
read or printed after publication process has completed read or printed after the publication process has completed
* Currently published by the RFC Editor: .txt, PDF, PDF that * Currently published by the RFC Editor: formatted plain text,
contains figures (rare) PDF of the formatted plain text, PDF that contains figures
(rare)
* Currently made available by other sites: HTML, PDF, others * Currently made available by other sites: HTML, PDF, others
Canonical format = the authorized, recognized, accepted, and archived Canonical format = the authorized, recognized, accepted, and archived
version of the document version of the document
* Currently: .txt * Currently: formatted plain text
Metadata = Information associated with a document so as to provide, Metadata = Information associated with a document so as to provide,
for example, definitions of its structure, or of elements within it for example, definitions of its structure, or of elements within the
such as it topic or author document such as its topic or author
2. History and Goals 2. History and Goals
Current RFC format rules as defined in [RFC2223] and clarified in Below are the current RFC format rules as defined in [RFC2223] and
2223bis: clarified in 2223bis.
* The character codes are ASCII. * The character codes are ASCII.
* Each page must be limited to 58 lines followed by a form feed * Each page must be limited to 58 lines followed by a form feed
on a line by itself. on a line by itself.
* Each line must be limited to 72 characters followed by carriage * Each line must be limited to 72 characters followed by carriage
return and line feed. return and line feed.
* No overstriking (or underlining) is allowed. * No overstriking (or underlining) is allowed.
skipping to change at page 5, line 24 skipping to change at page 5, line 19
numbers on which various sections fall will likely change with numbers on which various sections fall will likely change with
reformatting. Thus cross references in the text by section reformatting. Thus cross references in the text by section
number usually are easier to keep consistent than cross number usually are easier to keep consistent than cross
references by page number. references by page number.
* RFCs in plain ASCII-text may be submitted to the RFC Editor in * RFCs in plain ASCII-text may be submitted to the RFC Editor in
e-mail messages (or as online files) in either the finished e-mail messages (or as online files) in either the finished
Publication format or in nroff. If you plan to submit a Publication format or in nroff. If you plan to submit a
document in nroff please consult the RFC Editor first. document in nroff please consult the RFC Editor first.
Precedent for multiple Publication formats is described in RFC 2223 The precedent for additional formats, specifically PostScript, is
and has been used for a few RFCs: 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 Note that since the ASCII text version of the RFC is the primary
version, the PostScript version must match the text version. The version, the PostScript version must match the text version. The
RFC Editor must decide if the PostScript version is "the same as" RFC Editor must decide if the PostScript version is "the same as"
the ASCII version before the PostScript version can be published. the ASCII version before the PostScript version can be published.
Neither RFC 2223 or 2223bis use the term 'metadata,' though the RFC Neither RFC 2223 or 2223bis use the term 'metadata,' though the RFC
Editor currently refers to components of the text such as the Stream, Editor currently refers to components of the text such as the Stream,
Status (e.g. Updates, Obsoletes), Category and ISSN as 'metadata.' Status (e.g., Updates, Obsoletes), Category and ISSN as 'metadata.'
2.1. Issues driving change 2.1. Issues driving change
While some authors and readers of RFCs find the strict limits of While some authors and readers of RFCs report that they find the
character encoding, line limits, and so on to be acceptable, others strict limits of character encoding, line limits, and so on to be
find those limitations a significant obstacle to their desire to acceptable, others claim to find those limitations a significant
communicate information via an RFC. With a broader community of obstacle to their desire to communicate and read the information via
authors currently producing RFCs and a wider range of presentation an RFC. With a broader community of authors currently producing RFCs
devices, the issues driving change represent both critical and a wider range of presentation devices, the issues being reported
deficiencies in the current Canonical format as well as strongly indicate limitations of the current Canonical format that must be
desirable changes on the part of some segments of the Internet reviewed and potentially incorporated in to the Canonical RFC format.
community.
While the specific points of concern vary, the main issues are: While the specific points of concern vary, the main issues discussed
are:
* Line art, also known as ASCII art * Line art, also known as ASCII art
* Character encoding * Character encoding
* Pagination * Pagination
* Reflowable text * Reflowable text
* Metadata * Metadata
Each area of concern has people in favor of change and people opposed Each area of concern has people in favor of change and people opposed
to it, all with reasonable concerns and requirements. Below is a to it, all with reasonable concerns and requirements. Below is a
summary of the arguments for and against each major issue. The summary of the arguments for and against each major issue. These
potential requirements derived from these discussions are listed points are not part of the list of requirements; they are the inputs
later in this document. that informed the requirements discussed in Section 3 of this
document.
2.1.1. Line art, aka ASCII art 2.1.1. Line art, aka ASCII art
Arguments in favor of keeping the current requirement for all Arguments in favor of limiting all diagrams, equations, tables and
diagrams, equations, tables, and charts include: charts to ASCII art depictions only include:
* Dependence on advanced diagrams (or any diagrams) causes * Dependence on advanced diagrams (or any diagrams) causes
accessibility issues. accessibility issues.
* Requiring ASCII art results in people often relying more on * Requiring ASCII art results in people often relying more on
clear written descriptions rather than just the diagram clear written descriptions rather than just the diagram
itself. itself.
* Use of the ASCII character set forces design of diagrams that * Use of the ASCII character set forces design of diagrams that
are simple and concise. are simple and concise.
Arguments in favor of replacing ASCII art with more complex diagrams Arguments in favor of allowing the use of more complex diagrams in
include: place of the current use of ASCII art include:
* State diagrams with multiple arrows in different directions and * State diagrams with multiple arrows in different directions and
labels on the lines will be more understandable. labels on the lines will be more understandable.
* Protocol flow diagrams where each step needs multiple lines of * Protocol flow diagrams where each step needs multiple lines of
description will be clearer. description will be clearer.
* Scenario descriptions that involve three or more parties with * Scenario descriptions that involve three or more parties with
communication flows between them will be clearer. communication flows between them will be clearer.
* Given the difficulties in expressing complex equations with * Given the difficulties in expressing complex equations with
common mathematical notation, allowing graphic art would allow common mathematical notation, allowing graphic art would allow
equations to be displayed properly. equations to be displayed properly.
* Complex art could allow for color to be introduced into the * Complex art could allow for color to be introduced into the
diagrams. diagrams.
Two suggestions have been been proposed regarding how graphics should Two suggestions have been proposed regarding how graphics should be
be included: one that would have graphic art referenced as a separate included: one that would have graphic art referenced as a separate
document to the Publication format, and one that would allow embedded document to the Publication format, and one that would allow embedded
graphics in the Publication format. graphics in the Publication format.
2.1.2. Character encoding 2.1.2. Character encoding
For most of the history of the RFC Series, the character encoding for 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 RFCs has been ASCII. Below are arguments for keeping ASCII as well
as arguments for expanding to UTF-8. as arguments for expanding to UTF-8.
Arguments for retaining the ASCII-only requirement Arguments for retaining the ASCII-only requirement
skipping to change at page 7, line 37 skipping to change at page 7, line 36
* If we expand beyond ASCII, it will be difficult to know where * If we expand beyond ASCII, it will be difficult to know where
to draw the line on what characters are and are not allowed. to draw the line on what characters are and are not allowed.
There will be issues with dependencies on local file systems There will be issues with dependencies on local file systems
and processors being configured to recognize any other and processors being configured to recognize any other
character set. character set.
* The IETF works in ASCII (and English). The Internet research, * The IETF works in ASCII (and English). The Internet research,
design and development communities function almost entirely in design and development communities function almost entirely in
English. That strongly suggests that an ASCII document can be English. That strongly suggests that an ASCII document can be
read by everyone in the communities and audiences of interest. properly rendered and read by everyone in the communities and
audiences of interest.
Arguments for expanding to allow UTF-8: Arguments for expanding to allow UTF-8:
* In discussions of internationalization, actually being able to * In discussions of internationalization, actually being able to
illustrate the issue is rather helpful, and you can't illustrate the issue is rather helpful, and you can't
illustrate a Unicode code point with "U+nnnn". illustrate a Unicode code point with "U+nnnn".
* Will provide the ability to denote protocol examples using the * Will provide the ability to denote protocol examples using the
character sets those examples support. character sets those examples support.
skipping to change at page 8, line 39 skipping to change at page 8, line 38
experience on a wider variety of devices, platforms, and experience on a wider variety of devices, platforms, and
browsers. browsers.
2.1.4. Reflowable text 2.1.4. Reflowable text
Arguments against allowing for reflowable text: Arguments against allowing for reflowable text:
* Reflowable text may impact the usability of graphics and tables * Reflowable text may impact the usability of graphics and tables
within a document. within a document.
Arguments for allowing reflowable text Arguments for allowing reflowable text:
* RFCs are more readable on a wider variety of devices and * RFCs are more readable on a wider variety of devices and
platforms, including mobile devices and a wide variety of platforms, including mobile devices and a wide variety of
screen layouts. screen layouts.
2.1.5. Metadata and tagging 2.1.5. Metadata and tagging
While metadata requirements are not part of RFC 2223, there is a While metadata requirements are not part of RFC 2223, there is a
request that descriptive metadata tags be added as part of a revision request that descriptive metadata tags be added as part of a revision
of the Canonical RFC format. These tags would allow for enhanced of the Canonical RFC format. These tags would allow for enhanced
content by embedding information like links, tags, or quick content by embedding information like links, tags, or quick
translations and could help control the look and feel of the translations and could help control the look and feel of the
Publication format. While the lack of metadata in the current RFCs Publication format. While the lack of metadata in the current RFCs
does not impact an RFCs accessibility or readability, if other does not impact an RFCs' accessibility or readability, several
requirements are accepted, such as allowing UTF-8 in any part of an individuals have indicated that allowing metadata within the RFC
RFC, then having the ability to use metadata to provide an ASCII would make their reading of the documents more efficient.
"translation" of the UTF-8 letters is also a requirement.
Arguments for allowing metadata in the Canonical and Publication Arguments for allowing metadata in the Canonical and Publication
formats: formats:
* Allowing metadata in the final Canonical and Publication format * Allowing metadata in the final Canonical and Publication format
allows readers to potentially get more detail out of a allows readers to potentially get more detail out of a
document. For example, if non-ASCII characters are allowed in document. For example, if non-ASCII characters are allowed in
the Author and Reference sections, Metadata must include the Author and Reference sections, Metadata must include
translations of that information. translations of that information.
Arguments against metadata in the final Canonical and Publication Arguments against metadata in the final Canonical and Publication
formats: formats:
* Metadata adds additional overhead to the overall process of * Metadata adds additional overhead to the overall process of
creating RFCs and may complicate future usability. creating RFCs and may complicate future usability as a result
of requiring backward compatibility for metadata tags.
2.2. Further considerations 2.2. Further considerations
Some of the discussion beyond the issues described above went into Some of the discussion beyond the issues described above went into a
potential solutions. Those solutions and the debate around them review of potential solutions. Those solutions and the debate around
added a few more points to the potential requirements for a change in them added a few more points to the list of potential requirements
RFC Format. In particular, discussing whether a change in format for a change in RFC Format. In particular, the discussion of tools
should also include the creation and ongoing support of specific RFC introduced the idea of whether a change in format should also include
authoring and/or rendering tools and whether the Canonical format the creation and ongoing support of specific RFC authoring and/or
should be a format that must go through a rendering agent to be rendering tools and whether the Canonical format should be a format
readable. that must go through a rendering agent to be readable.
2.2.1. Creation and use of RFC-specific tools 2.2.1. Creation and use of RFC-specific tools
Arguments against community-supported RFC-specific tools: Arguments against community-supported RFC-specific tools:
* We cannot be so unique in our needs that we can't use * We cannot be so unique in our needs that we can't use
commercial tools. commercial tools.
* Ongoing support for these tools adds a greater level of * Ongoing support for these tools adds a greater level of
instability to the ongoing availability of the RFC Series instability to the ongoing availability of the RFC Series
skipping to change at page 10, line 13 skipping to change at page 10, line 11
Arguments in support of community-supported RFC-specific tools: Arguments in support of community-supported RFC-specific tools:
* Given the community that would be creating and supporting these * Given the community that would be creating and supporting these
tools, there would be greater control and flexibility over the tools, there would be greater control and flexibility over the
tools and how they implement the RFC format requirements. tools and how they implement the RFC format requirements.
* Community supported tools currently exist and are in extensive * Community supported tools currently exist and are in extensive
use within the community, so it would be most efficient to use within the community, so it would be most efficient to
build on that base. build on that base.
2.2.2. Markup Language 2.2.2. Markup language
Arguments in support of a markup language as the Revisable format: Arguments in support of a markup language as the Revisable format:
* Having a markup language such as XML or HTML allows for greater * Having a markup language such as XML or HTML allows for greater
flexibility in creating a variety of Publication formats, with flexibility in creating a variety of Publication formats, with
a greater likelihood of similarity between them. a greater likelihood of similarity between them.
Arguments against a markup language as the Revisable format: Arguments against a markup language as the Revisable format:
* Having the Publication format be in code instead of in a simple * Having the Revisable format be in a markup language instead of
text-formatting structure ties us in to specific tools and/or in a simple text-formatting structure ties us in to specific
tool support going forward. tools and/or tool support going forward.
2.3. RFC Editor goals 2.3. RFC Editor goals
Today, each RFC has an nroff file created prior to publication. For Today, each RFC has an nroff file created prior to publication. For
RFCs revised using an XML file, this file is created by converting 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 XML to nroff at the final step. As more documents are submitted with
an XML file (so far in 2012, 66% of approved I-Ds were submitted with an XML file (so far in 2012, 66% of approved I-Ds were submitted with
an XML file), this conversion is problematic in terms of time spent an XML file), this conversion is problematic in terms of time spent
and data lost from XML. Making this process more efficient is and data lost from XML. Making this process more efficient is
strongly desired by the RFC Editor. strongly desired by the RFC Editor.
3. Format requirements 3. Format Requirements
Understanding the major pain points and balancing them with the Understanding the major pain points and balancing them with the
expectation of long-term viability of the documents brings us to a expectation of long-term viability of the documents brings us to a
review of what must be kept of the original requirements, what new review of what must be kept of the original requirements, what new
requirements may be added, and what requirements may be retired. requirements may be added, and what requirements may be retired.
3.1. Original requirements to be retained 3.1. Original requirements to be retained
There are several components of the original format requirements that There are several components of the original format requirements that
must be retained to ensure the ongoing continuity, reliability and must be retained to ensure the ongoing continuity, reliability and
readability of the Series: readability of the Series:
* RFCs must not change, regardless of format, once published. * The content of an RFC must not change, regardless of format,
once published.
* The Canonical format must be persistent and reliable across a * The Canonical format must be persistent and reliable across a
large variety of devices, operating systems, and editing tools large variety of devices, operating systems, and editing tools
for the indefinite future. 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, the * While several Publication formats must be allowed, in order to
Publication formats must include support for plain-text continue support for the most basic reading and search tools
printing. 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 * The Boilerplate and overall structure of the RFC must be in
accordance with current RFC and Style Guide requirements (see accordance with current RFC and Style Guide requirements (see
[RFC5741]). [RFC5741]).
Issues such as overstriking, page justification, hyphenation, and Issues such as overstriking, page justification, hyphenation, and
spacing will be defined in the RFC Style Guide. [Style] spacing will be defined in the RFC Style Guide. [Style]
3.2. Requirements to be added 3.2. Requirements to be added
In addition to those continuing requirements, discussions with In addition to those continuing requirements, discussions with
various members of the wider Internet Community have yielded the various members of the wider Internet Community have yielded the
following General Requirements for the RFC Series. following General Requirements for the RFC Series.
* There must be support for Accessibility, including alternative * The documents must be accessible to people with physical or
text for images, limitations on color. Appropriate authoring age-related disabilities, including alternative text for images
tools are highly desirable but focus on the creation of and limitations on color. See the W3C's Accessibility
Internet-Drafts, a topic outside the scope of the RFC Editor. documents [WCAG20] and the United Nations "Convention on the
[WCAG20] 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. To respect * The official language of the RFC Series is English. However,
international names and information, UTF-8/Unicode in the to respect international names and information, UTF-8/Unicode
header and references must be allowed. Romanized ASCII is allowed. All documents containing non-ASCII characters must
translations will be required and recorded in the metadata be readable and implementable without them. Author names and
(that translation will be used in the ASCII text version of the addresses will require an ASCII equivalent for indexing
RFC and to aid in basic searching). purposes.
* The Submission and Publication formats need to permit extending * The Submission and Publication formats need to permit extending
the set of metadata tags, for the addition of labeled metadata. the set of metadata tags, for the addition of labeled metadata.
A pre-defined set of metadata tags must be created to make use A pre-defined set of metadata tags must be created to make use
of metadata tags consistent for the life of the Series. of metadata tags consistent for the life of the Series.
* Graphics may include ASCII art and SVG line art. Color will * Graphics may include ASCII art and SVG line art. Color will
not be accepted; RFCs must correctly display in monochrome to not be accepted; RFCs must correctly display in monochrome to
allow for monochrome displays, black-and-white printing, and allow for monochrome displays, black-and-white printing, and
Accessibility issues. support for physical and age-related disabilities.
* The Canonical format must be renderable in to self-contained * The Canonical format must be renderable into self-contained
Publication formats in order to be easily downloaded and read Publication formats in order to be easily downloaded and read
offline. offline.
* Fixed-width fonts are required for ASCII-art sections, source * Fixed-width fonts and non-reflowable text are required for
code examples, and other places where strict alignment is ASCII-art sections, source code examples, and other places
required. where strict alignment is required.
The requirements of the RFC Editor in considering how the formats for * The Canonical format should be structured to enable easy
Submission and Publication should change include: 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 * The final conversion of all submitted documents to nroff should
be replaced by using an accepted Revisable format throughout be replaced by using an accepted Revisable format throughout
the process. the process.
* In order to maintain an efficient publication process, the RFC * In order to maintain an efficient publication process, the RFC
Editor must work with the minimal number of files required for Editor must work with the minimal number of files required for
each submission (not a tar ball of several discrete each submission (not a tar ball of several discrete
components). components).
* In order to maintain the focus of the RFC Editor on editing for * In order to maintain the focus of the RFC Editor on editing for
clarity and consistency rather than document layout details, clarity and consistency rather than document layout details,
the number of directly supported Publication formats must be the number of Publication formats produced by the RFC editor
limited. must be limited.
* Tools must support error checking against document layout * Tools must support error checking against document layout
issues as well as other format details (diagrams, line breaks, issues as well as other format details (diagrams, line breaks,
variable and fixed width font layout) at the time of Submission variable and fixed width font layout) at the time of RFC
for author review. Editor's request for author review (AUTH48).
3.3. Requirements to be retired 3.3. Requirements to be retired
Some of the original requirements may be removed from consideration: Some of the original requirements may be removed from consideration:
* Pagination ("Each page must be limited to 58 lines followed by * Pagination ("Each page must be limited to 58 lines followed by
a form feed on a line by itself.") a form feed on a line by itself.")
* Maximum line length ("Each line must be limited to 72 * Maximum line length ("Each line must be limited to 72
characters followed by carriage return and line feed.") characters followed by carriage return and line feed.")
skipping to change at page 13, line 11 skipping to change at page 13, line 19
formats, it does not concern interactions between Internet formats, it does not concern interactions between Internet
hosts. Therefore it does not have any specific Security hosts. Therefore it does not have any specific Security
Considerations. Considerations.
5. IANA Considerations 5. IANA Considerations
This document does not request entries in any IANA Registry. This document does not request entries in any IANA Registry.
6. References 6. References
6.1. Normative References 6.1. Informative References
[WCAG20] W3C, "Web Content Accessibility Guidelines (WCAG) 2.0",
December 11 2008, http://www.w3.org/TR/WCAG20/
6.2. Informative References
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997. RFC 2223, October 1997.
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
Headers, and Boilerplates", RFC 5741, December 2009. 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.
[2223bis] Reynolds, J. Bradon, R., "Instructions to Request for [2223bis] Reynolds, J. Bradon, R., "Instructions to Request for
Comments (RFC) Authors", Work In Progress, August 2004. Comments (RFC) Authors", Work In Progress, August 2004.
[Style] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work In [Style] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work In
Progress, draft-flanagan-style-00, October 2012. Progress, draft-flanagan-style-00, October 2012.
Acknowledgements [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 The authors received a great deal of helpful input from the community
in pulling together these requirements and wish to particularly in pulling together these requirements and wish to particularly
acknowledge the help of Joe Hildebrand, Paul Hoffman and John acknowledge the help of Joe Hildebrand, Paul Hoffman and John
Klensin, who each published an I-D on the topic of potential format Klensin, who each published an I-D on the topic of potential format
options before the IETF 84 BOF. options before the IETF 84 BOF.
Authors' Addresses Authors' Addresses
Heather Flanagan Heather Flanagan
RFC Series Editor RFC Series Editor
 End of changes. 51 change blocks. 
124 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/