]> Updates to RFC Publication Formats ICANN
paul.hoffman@icann.org
Internet-Draft draft-rswg-rfc7990-updates, the successor to RFC 7990, defines the definitive version of an RFC as a published RFC with is in RFCXML. It defines publication versions of the RFC as published RFCs in the publication formats such as PDF, plain text, and HTML. draft-rswg-xml2rfcv3-implemented is updating the specification for the RFCXML format. This document updates some of the publication formats, specifically updating RFC 7992, RFC 7994, RFC 7995, and RFC 8153. Because RFC 7990 mentions some of the features of the publication formats, this document also updates RFC 7990. There is a repository for this draft at https://github.com/paulehoffman/pub-format-updates.
Introduction This document updates the RFCs that define the publication formats for RFCs in plain-text and HTML formats. It updates "HTML Format for RFCs" (), "Requirements for Plain-Text RFCs" (), and two documents about the PDF format, "PDF Format for RFCs" () and "Digital Preservation Considerations for the RFC Series" (). Future versions of this draft might also update "Cascading Style Sheets (CSS) Requirements for RFCs" (), "SVG Drawings for RFCs: SVG 1.2 RFC" (), and "'xml2rfc' Version 3 Preparation Tool Description" (), but does not do so yet. Because mentions some of the features of the publication, this document also updates . It is important to note that this document does not update . That is, this document updates only some of the publication formats for RFCs, not the definitive format (RFCXML).
PDF Publication Format
Move Requirement from PDF/A-3 to PDF/A This document updates and by changing the requirement from using the PDF/A-3 standard to using the PDF/A standard, and by dropping the requirement that the XML be embedded in the PDF publication version. Other parts of , particularly the need to archive metadata about RFCs, are not changed.
HTML Publication Format
Additional Information about an RFC This document significantly changes Section 6 of to say that the front matter will contain significantly more information than is specified in . In specific, the HTML will include the metadata currently visible in the "HTMLized" version of RFCs seen in the IETF Datatracker. This includes links to the following:
  • The Datatracker page for the RFC
  • Errata for the RFC
  • How to report errata for the RFC
  • The Datatracker page(s) for the author(s) of the RFC
It will also include a link to the Datatracker page for the draft that became the RFC, links to including earlier versions of that draft, and the ability to comapre earlier version of the RFC with the RFC and with each other.
Plain Text Publication Format
Line Length Section 4.3 of says:
  • Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL).
This document updates that limit to 100 characters. The primary reason for this update is that the 72-character limit forced document authors to constrain the examples they use. With a wider maximum line limit, those authors can construct more accurate and more useful examples, and thus improve the quality of the RFC Series. Note that the 72-character limit was imposed when RFCs were all in the plain-text format and commonly printed on printers with an 80-character line limit. Printing from the plain-text format of modern RFCs happens tremendously less often than earlier. Even in cases where someone prints a plain-text publication format RFC with lines longer than what that can fit on the page, the reader will immediately see the problem and can instead read from the HTML or PDF format for the same RFC.
IANA Considerations This document has no IANA considerations.
Security Considerations Changing the formats for plain-text and HTML publication versions of RFCs is not expected to cause any security issues.
Acknowledgments This document is inspired by many suggestions from many people in the RSWG.
References Normative References RFC Format Framework In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan. HTML Format for RFCs In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft. Requirements for Plain-Text RFCs In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition. PDF Format for RFCs This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF. Digital Preservation Considerations for the RFC Series The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice. Informative References The "xml2rfc" version 3 Vocabulary as Implemented Standcore ICANN This document describes the "xml2rfc" version 3 vocabulary as implemented in xml2rfc tools at the time of publication. Editorial Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the rswg@rfc-editor.org mailing list, which has its home pags at <https://www.ietf.org/mailman/listinfo/rswg>. Source code and issues list for this draft can be found at <https://github.com/jrlevine/draft-rswg-xml2rfcv3-implemented>. Cascading Style Sheets (CSS) Requirements for RFCs The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992). SVG Drawings for RFCs: SVG 1.2 RFC This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams. "xml2rfc" Version 3 Preparation Tool Description This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.