[rfc-i] Additional comments on draft-iab-rfcformatreq

Bernard Aboba bernard.aboba at gmail.com
Thu Dec 20 17:11:44 PST 2012

Find enclosed my review of draft-iab-rrfcformatreq.  While many of the
comments relate to terminology, there is one larger issue that struck
me, which is the need to define the backward compatibility
requirements that arise if the canonical format chosen represents an
input format to be processed by a tool, rather than an output format.
-------------- next part --------------

INTERNET-DRAFT                                               H. Flanagan
Intended Status: Informational                         RFC Series Editor
                                                             N. Brownlee
                                          Independent Submissions Editor
Expires: June 09, 2013                                 December 06, 2012

                     RFC Series Format Development 


   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.

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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright and License Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.


<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 1]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

   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.  Line art, aka 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 . . . . . . . . . . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13


<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 2]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

1  Introduction

   Over 40 years ago, the RFC Series began in an environment that
   included handwritten RFCs, typewritten RFCs, RFCs produced on
   mainframes, and more.  This resulted in an understanding that however
   they were published, a common format that could be read and revised
   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 in to 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

   Since the earliest days of the Series, 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

[BA] Is it intended for this document to update RFC 2223? 

   It also reviews recent requests for enhancements as
   understood from community discussion and various proposals for new
   formats including HTML, XML, PDF and EPUB.  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

[BA] Please include a definition of "Accessibility". 

   ASCII = Coded Character Set -- 7-bit American Standard Code for
   Information Interchange, ANSI X3.4-1986.

   Submission format = the format submitted to the RFC Editor for
   editorial revision and publication

      *  might not be the same as the canonical format (though it would
         make the workflow somewhat simpler for the RFC Editor if it

      *  will be converted to another format for further processing and

<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 3]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

         publication if necessary

      *  Currently: .txt (required), XML (optional), NROFF (optional) 

   Revisable format = the format that will provide the information for
   conversion into a Publication format; it is used or created by the
   RFC Editor

      *  Currently: XML (optional), NROFF (required)

   Publication format = display and distribution format as it may be
   read or printed after publication process has completed  

      *  Currently published by the RFC Editor: .txt, PDF, 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: .txt

   Metadata = Information associated with a document so as to provide,
   for example, definitions of its structure, or of elements within it
   such as it topic or author

2.  History and Goals

   Current RFC format rules as defined in [RFC2223] and clarified in

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


<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 4]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

      *  Do not do hyphenation of words at the right margin.        

      *  Do not use footnotes.  If such notes are necessary, put them at
         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.

   Precedent for multiple Publication formats is described in RFC 2223
   and has been used for a few RFCs:

[BA] Given some of the discussion that follows, it may be useful to summarize
the experience with alternative formats (including .pdf and .ps). In particular,
are existing alternative formats (such as .pdf and .ps) considered to be "consistent
and reliable"?

      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 find the strict limits of
   character encoding, line limits, and so on to be acceptable, others
   find those limitations a significant obstacle to their desire to
   communicate information via an RFC.  With a broader community of
   authors currently producing RFCs and a wider range of presentation
   devices, the issues driving change represent both critical
   deficiencies in the current Canonical format as well as strongly
   desirable changes on the part of some segments of the Internet

   While the specific points of concern vary, the main issues are:


<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 5]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

      *  Line art, also known as ASCII art

      *  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.  The
   potential requirements derived from these discussions are listed
   later in this document.

2.1.1.  Line art, aka ASCII art 

   Arguments in favor of keeping the current requirement for all
   diagrams, equations, tables, and charts include:

[BA] Not sure what "the current requirement" refers to, since 
Section 2 does not mention line art requirements.

      *  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

      *  Use of the ASCII character set forces design of diagrams that
         are simple and concise.

[BA] Presumably the above requirements apply to the text version of the
document, but not other formats, correct?  Please clarify. 

   Arguments in favor of replacing ASCII art with more complex diagrams

[BA] Please clarify what "replacing ASCII art" refers to.  Is this referring
to the canonical format (text), alternative formats (where complex diagrams
are already supported), etc.?  

      *  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 color to be introduced into the

<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 6]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012


   Two suggestions have been 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.

[BA] Please clarify the meaning of "Publication format".  For example, 
does this refer to the future canonical format,  or all formats? 

2.1.2.  Character encoding

   For most of the history of the RFC Series, the character encoding for
   RFCs has been ASCII.  

[BA] I assume that the above sentence is referring to the character
encoding supported in the canonical format, correct? 

   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

      *  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
         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

<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 7]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

         native character sets.

      *  Certain special characters in equations or quoted from other
         texts could be allowed.

      *  Citations of web pages using more international characters are 

   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 clear 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

2.1.4.  Reflowable text 

   Arguments against allowing for reflowable text:

      *  Reflowable text may impact the usability of graphics and tables
         within a document.

   Arguments for allowing reflowable text

      *  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 

   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

<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 8]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

   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 RFCs accessibility or readability, if other
   requirements are accepted, such as allowing UTF-8 in any part of an
   RFC, then having the ability to use metadata to provide an ASCII
   "translation" of the UTF-8 letters is also a requirement.

   Arguments for allowing metadata in the Canonical and Publication

      *  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

      *  Metadata adds additional overhead to the overall process of
         creating RFCs and may complicate future usability.

2.2.  Further considerations

   Some of the discussion beyond the issues described above went into
   potential solutions.  Those solutions and the debate around them
   added a few more points to the potential requirements for a change in
   RFC Format.  In particular, discussing 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

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.

      *  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:

<Brownlee & Flanagan>    Expires June 09, 2013                  [Page 9]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

      *  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 Publication format be in code 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 (so far in 2012, 66% of approved I-Ds were submitted with
   an XML file), this conversion is problematic in terms of time spent
   and data lost from XML.  Making this process more efficient is
   strongly desired by the RFC Editor.

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.

3.1.  Original requirements to be retained

   There are several components of the original format requirements that
   must be retained to ensure the ongoing continuity, reliability and
   readability of the Series:

      *  RFCs must not change, regardless of format, once published. 


<Brownlee & Flanagan>    Expires June 09, 2013                 [Page 10]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

      *  The Canonical format must be persistent and reliable across a
         large variety of devices, operating systems, and editing tools
         for the indefinite future.

[BA] Please provide more detail on the requirements for being "persistent and reliable".

If RFCs in various formats were to be produced by a tool taking as input
a canonical format that evolves over time, what requirements would be 
implied for the tool in order for the canonical format to be considered 
"consistent and reliable"?  

For example, are there backward compatibility requirements that apply
to the canonical format, to the tool itself, or to the output? 

      *  While several Publication formats must be allowed, the
         Publication formats must include support for plain-text

[BA] Please clarify the "plain text" requirement.  Would this apply to
the canonical format, the text format, or all formats?  Does "plain text"
mean ASCII here?

      *  The Boilerplate and overall structure of the RFC must be in
         accordance with current RFC and Style Guide requirements (see

   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.

      *  There must be support for Accessibility, including alternative
         text for images, limitations on color.  Appropriate authoring
         tools are highly desirable but focus on the creation of
         Internet-Drafts, a topic outside the scope of the RFC Editor.

      *  The official language of the RFC Series is English.  To respect
         international names and information, UTF-8/Unicode in the
         header and references must be allowed.  Romanized ASCII
         translations will be required and recorded in the metadata
         (that translation will be used in the ASCII text version of the
         RFC and to aid in basic searching).

      *  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 SVG line art.  Color will
         not be accepted; RFCs must correctly display in monochrome to
         allow for monochrome displays, black-and-white printing, and
         Accessibility issues.

      *  The Canonical format must be renderable in to self-contained
         Publication formats in order to be easily downloaded and read


<Brownlee & Flanagan>    Expires June 09, 2013                 [Page 11]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

      *  Fixed-width fonts are required for ASCII-art sections, source
         code examples, and other places where strict alignment is

   The requirements of the RFC Editor in considering how the formats for
   Submission and Publication should change 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

      *  In order to maintain the focus of the RFC Editor on editing for
         clarity and consistency rather than document layout details,
         the number of directly supported Publication formats must be

[BA] Can you clarify the meaning of "directly supported"?  Are you
referring to the number of canonical formats, or to the total number
of formats that are supported?  Are there any requirements for continued
support of existing alternative formats? 

      *  Tools must support error checking against document layout
         issues as well as other format details (diagrams, line breaks,
         variable and fixed width font layout) at the time of Submission
         for author review.

3.3.  Requirements to be retired

   Some of the original requirements may be removed from consideration:

      *  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

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

<Brownlee & Flanagan>    Expires June 09, 2013                 [Page 12]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

5.  IANA Considerations

         This document does not request entries in any IANA Registry.

6.  References

6.1.  Normative 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",
              RFC 2223, October 1997.

   [RFC5741]  Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
              Headers, and Boilerplates", RFC 5741, December 2009.

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


   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 at rfc-editor.org

   Nevil Brownlee
   Independent Submissions Editor


<Brownlee & Flanagan>    Expires June 09, 2013                 [Page 13]
INTERNET DRAFT      <RFC Series Format Development>    December 06, 2012

   Email rfc-ise at rfc-editor.org

<Brownlee & Flanagan>    Expires June 09, 2013                 [Page 14]

More information about the rfc-interest mailing list