RFC 6949

RFC Series Format Requirements and Future Development

📅 published May 2013, from ietf

RFC 6949: RFC Series Format Requirements and Future Development 🎀

Okay bestie, let's get into the basics first 💖 This is RFC 6949, titled "RFC Series Format Requirements and Future Development." It's Informational, not a standard, published in May 2013 📝 It came from the Internet Architecture Board (IAB), written by H. Flanagan (RFC Series Editor) and N. Brownlee (Independent Submissions Editor), with ISSN 2070-1721. The header lists one update, to RFC 2223, and no Obsoletes entry 🔥

Abstract ✨

This doc describes the current requirements and the requests for enhancements to the format of the canonical version of RFCs 🌸 It defines some terms so we can tell exactly which stages of document production are being discussed for format changes 🧚 The requirements in here will decide what changes get made to RFC format, and it updates RFC 2223 💜

Status of This Memo 📜

Not a standards-track spec, just published for info 🦋

This doc is a product of the Internet Architecture Board (IAB). It holds information the IAB thought was valuable enough to keep on the permanent record, and it represents the IAB's consensus. Docs the IAB approves for publication are not candidates for any level of Internet Standard, so see Section 2 of RFC 5741 if you want the details 👑

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6949 🔗

Copyright (c) 2013 IETF Trust and the people listed as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, bestie, because they spell out your rights and restrictions for this document 🫶

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. History and Goals ...............................................4
      2.1. Issues Driving Change ......................................5
           2.1.1. ASCII Art ...........................................5
           2.1.2. Character Encoding ..................................6
           2.1.3. Pagination ..........................................7
           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 ........................................13
   5. Informative References .........................................13
   6. Acknowledgements ...............................................13

1. Introduction 🦋

Over 40 years ago the RFC Series started out as a pile of memos made 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 source formats became unreadable, the core people behind the Series realized they needed a common format that could be read, revised, and archived far in the future 💅 US-ASCII was picked for character encoding, and after a stretch of variability, a well-defined presentation format got settled on 🌸 That format has proven persistent and reliable across a huge range of devices, operating systems, and editing tools, and that stability has been a continuing strength of the Series 👑

But new tech, like small devices and advances in display technology, is becoming common, so there's a growing desire for the RFC format to adapt and take advantage of these new ways to communicate information 🔥

Since the format stabilized, authors and readers have suggested enhancements. However, none of them built clear consensus in the Internet technical community. As always, some people see no need for change while others push hard for specific enhancements 💀

This document looks at the current RFC requirements as described in RFC 2223 [RFC2223] and, more recently, in 2223bis [2223bis]. Section 2 reviews recent requests for enhancements as understood from community discussion, plus various proposals for new formats including HTML, XML, PDF, and EPUB ✨ The actual requirements are captured in Section 3. The focus is on the Canonical format of RFCs, but there's also some mention of other phases in the RFC publication process and the document formats tied to them 🧚 Terms are defined to help clarify exactly which stages of production are under discussion for format changes 💜

1.1. Terminology 📚

  • ASCII: Coded Character Set, meaning 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986 [ASCII] 🔤
  • Canonical format: the authorized, recognized, accepted, and archived version of the document
    • Currently: formatted plain text
  • Metadata: information attached to a document to provide things like definitions of its structure, or of elements inside it such as its topic or author 🏷️
  • Publication format: the display and distribution format as it may be read or printed after the publication process is done
    • 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
  • Reflowable text: text that automatically wraps to the next line as the user changes the margins, either by resizing the window or changing the font size 🪞
  • Revisable format: the format that provides the information for conversion into a Publication format. It's used or created by the RFC Editor (see Section 2.3 for an explanation of current practice) 🛠️
    • Currently: XML (optional), nroff (required)
  • Submission format: the format submitted to the RFC Editor for editorial revision and publication 📨
    • Currently: formatted plain text (required), XML (optional), nroff (optional)

2. History and Goals 🕰️

Here are the current RFC format rules, as defined in [RFC2223] and clarified in 2223bis. Read them like a checklist, bestie 📋

  • 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 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 nor 2223bis uses 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 🌷

Some authors and readers of RFCs find the strict limits on character encoding, line length, and so on totally acceptable. Others say those limits are a big obstacle to communicating and reading information through an RFC 😤 With a broader community of authors producing RFCs and a wider range of devices showing them, the issues people report point to limits in the current Canonical format that must be reviewed and potentially addressed in the Canonical RFC format 💖

The specific concerns vary, but the main issues discussed are:

  • ASCII art
  • Character encoding
  • Pagination
  • Reflowable text
  • Metadata

Each area has people for change and people against 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're the inputs that informed the requirements in Section 3 of this document 🧠

2.1.1. ASCII Art 🎨

Arguments for 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 for allowing more complex diagrams in place of the current ASCII art include:

  • State diagrams with multiple arrows in different directions and labels on the lines will be more understandable. 🔀
  • Protocol flow diagrams in which 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 let equations be displayed properly. ➗
  • Complex art could allow grayscale or color to be introduced into the diagrams. 🌈

Two suggestions have been proposed for how graphics should be included: one where graphic art is referenced as a separate document to the Publication format, and one that allows embedded graphics in the Publication format 🦋

2.1.2. Character Encoding 🎀

okay so for basically the whole history of the RFC Series, RFCs have been written in ASCII 📝. Here's the case for keeping it, and the case for opening things up to UTF-8 🌈.

Arguments for retaining the ASCII-only requirement:

  • ASCII is the easiest thing to search and display across literally every platform 💅
  • if you ever have to retype or scan a hard copy (which was required in the past!!), ASCII is way easier to rescan while keeping all the original info. Nothing gets lost, like keywords or content tags 🔍
  • if we go beyond ASCII, it gets really hard to decide where to draw the line on which characters are allowed 🙈. There could also be problems with local file systems and processors that are set up to recognize some other character set 💀
  • the IETF works in ASCII (and English) 🇬🇧. The Internet research, design, and development communities basically run on English, so an ASCII document can be properly rendered and read by everyone in those communities and audiences 🫶

Arguments for expanding to allow UTF-8:

  • when you're talking about internationalization, being able to actually show the issue is SO helpful, and you can't illustrate a Unicode code point with "U+nnnn" 😭
  • it would let protocol examples be written in the character sets those examples actually support ✨
  • better support for international character sets, including letting authors spell their names in their own native character sets 🌸
  • certain special characters in equations, or quoted from other texts, could be allowed 🧮
  • citations of web pages with more international characters become possible 🌍

Arguments for strictly prescribed UTF-8 use:

  • to keep documents as searchable as possible, ASCII-only should be required for the main text of the document, with 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 makes for a smoother reading experience on a wider variety of devices, platforms, and browsers 📱
  • people end up using subsections rather than page numbers for reference, which forces what would otherwise be long sections to be broken into subsections. That 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 range of devices and platforms, including mobile devices and all kinds 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 such as 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 RFCs would make their reading of the documents more efficient 🤓.

Arguments for allowing metadata in the Canonical and Publication formats:

  • metadata potentially lets readers get more detail out of a document. For example, if non-ASCII characters are allowed in the Author's Address and Reference sections, metadata must include translations of that information 🌏

Arguments against metadata in the final Canonical and Publication formats:

  • metadata adds overhead to the whole RFC-creation process, and can make future usability trickier, since it means keeping backward compatibility for those 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 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 ⚡

Arguments against community-supported RFC-specific tools:

  • we can't 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 🥲

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 🎯

Currently, each RFC has an nroff file created prior to publication. For RFCs revised using an XML file, the nroff 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 🔒

Several components of the original format requirements must be retained to ensure the ongoing continuity, reliability, and readability of the Series 💜:

  1. The content of an RFC must not change, regardless of format, once published.
  2. 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 systems, and platforms for the foreseeable future 🧚.
  3. 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 📜.
  4. 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 ✨

okay so, after a bunch of chats with people across the wider Internet community, they came up with these extra general requirements for the RFC Series 🫶 bestie, these are important

  1. The documents must be made accessible to people with visual disabilities 👀 like, include alternative text for images and don't go overboard with color. Check out the W3C's accessibility docs [WCAG20] and the United Nations "Convention on the Rights of Persons with Disabilities" [UN2006] for guidance 💜 Good authoring tools are highly desirable, but the focus is on creating Internet-Drafts, which is a topic outside the scope of the RFC Editor 💅
  2. 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. Using non-ASCII characters, expressed in a standard Unicode Encoding Form (such as UTF-8), must receive explicit approval from the document stream manager, and it will be allowed after the rules for the common use cases are defined in the Style Guide ✨
  3. The Submission and Publication formats need to permit extending the set of metadata tags, so labeled metadata can be added 🏷️ A predefined set of metadata tags must be created so metadata tags stay consistent for the life of the Series 🌸
  4. 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, so they work on monochrome displays, black-and-white printing, and for visual disabilities 🖤
  5. The Canonical format must be renderable into self-contained Publication formats, so people can easily download and read them offline 📥🧚
  6. Fixed-width fonts and non-reflowable text are required for ASCII-art sections, source code examples, and other places where strict alignment is required 📐 no messing up the lines, periodt 💅
  7. At least one Publication format must support readable print to standard paper sizes 🖨️🍓
  8. The Canonical format should be structured so programs can easily identify and parse code or specifications, such as MIB modules and ABNF 🤖💖

The requirements of the RFC Editor regarding RFC format and the publication process include:

  1. The final conversion of all submitted documents to nroff should be replaced by using an accepted Revisable format throughout the process 🔄
  2. 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) 📁 not a whole pile of files, bestie 🙅‍♀️
  3. In order to keep the RFC Editor focused on editing for clarity and consistency rather than document layout details, the number of Publication formats produced by the RFC Editor must be limited 🎯
  4. Tools must support error checking against document layout issues as well as other format details (diagrams, line breaks, variable- and fixed-width fonts) 🔍 literally the glow-up we needed ✨

3.3. Requirements to Be Retired 🥀

okay so some of the original requirements are getting removed from consideration 😭 the detailed rules for how these changes will be put in place will be documented in a future RFC, so stay tuned 👀

  • 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 🔐💀

okay bestie, this part is serious 🚨 This document only sets out requirements for RFCs in their various formats. It does not concern interactions between Internet hosts, so it does not have any specific security considerations. Nothing to panic about here, but it's good to know exactly what this document covers and what it doesn't 🙈✨

5. Informative References 📚

these are the references that help explain things, and I'm keeping every single one exactly as written 🫶

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

[2223bis]  Reynolds, J. and R. Braden, "Instructions to Request for
           Comments (RFC) Authors", Work in Progress, August 2004.

[Style]    Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in
           Progress, October 2012.

[SVG]      Dahlstrom, E., Dengler, P., Grasso, A., Lilley, C.,
           McCormack, C., Schepers, D., and J. Watt, "Scalable Vector
           Graphics (SVG) 1.1 (Second Edition)", W3C Recommendation,
           16 August 2011, <http://www.w3.org/TR/SVG11/>.

[WCAG20]   Caldwell, B., Cooper, M., Reid, L., and G. Vanderheiden,
           "Web Content Accessibility Guidelines (WCAG) 2.0", 11
           December 2008, <http://www.w3.org/TR/WCAG20/>.

[UN2006]   United Nations, "Convention on the Rights of Persons with
           Disabilities", December 2006.

6. Acknowledgements 🙏💖

the authors got a ton of super helpful input from the community while pulling these requirements together 🥹 and they especially want to shout out Joe Hildebrand, Paul Hoffman, and John Klensin 👑 each of them published an Internet-Draft about possible 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
📦 where this page comes from