RFC v3 Format – LIVE
For the past 50 years, the RFC series has documented technical and organizational aspects of the Internet, including the specifications and policy documents produced by four streams: the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), and Independent Submissions. Some of you may have heard that the RFC Editor has been working with (primarily) the IETF community on evolving the format for RFCs. This project began in 2012 and reached an enormous milestone on 7 October 2019 with RFC 8651, which was published using a new document format. The new format will allow RFC authors to express their ideas more clearly, consumers to read RFCs more easily, and the RFCs themselves to serve archival purposes better.
When the RFC Format project started, there were a variety of goals, concerns, and requirements. In fact, the IETF community had been discussing if and how to evolve the format of RFCs for at least 20 years prior to the start of this project. Over the fifty-year history of the series, the publication format of RFCs had very limited changes. Originally, the documents were typed on paper, then shortly thereafter were in some of the few, basic digital formats available at the time. Eventually, RFCs were created using an NROFF source file to generate a text file. Now, we are using an XML source file to generate various publication formats, including HTML.
As requirements were gathered for the current RFC Format project, some members of the community were looking for long-term stability above all else, while others wanted documents easily viewed on all devices large and small. Some people were most interested in being able to use non-ASCII characters either in their name or in their examples for specifications. Others felt strongly about being able to create and publish complex artwork (e.g., network models). People wanted to be able to automatically extract code such as YANG modules, codecs, MIBS, and so on, without having to cut and paste and deal with page break headers and footers. There was no consensus on the requirements, and much concern about how change would impact the archival nature of the series.
As a result of several info-gathering sessions during IETF meetings and the specifications drafted by a design team, a set of RFCs were published (RFCs 7990-7998) that described the initial requirements for a change in format. It was clear at the time of publication that some of those requirements were likely to change over the course of actual implementation, and so updates to all those documents are considered a required part of the project.
Authors of RFCs will find they have far more options available to express information in their documents. New features include the ability to create more readable, flexible diagrams, linking to specific sections in other RFCs, and the ability to display names and examples outside the limited ASCII character set. Of course, with this wealth of new options comes a learning curve for both authors and editors as we all gain familiarity on how to use those features properly and to best effect. Authors are likely to find the new xml2rfc FAQ to be particularly useful in offering information on how to use the new features available to the v3 format.
Consumers of RFCs will likely find reading RFCs significantly easier. Plain text remains available, but the star of the show for consumers is the new HTML version, which features a responsive design that displays well on devices both big and small. WCAG2.1 compliance has been a design goal as well, which means these documents should be easily consumed by assisted reader devices.
Historians also gain something in the new format world, and that is the existence of a format specifically designed for archiving: PDF/A. The PDF/A documents are entirely self contained, in that everything from the content to the font choices to the XML used to generate the documents are all contained in one file. The goal of the design committee for PDF/A was (and is) to have an electronic document that would be consumable far into the future.
All RFCs from 8650 on will be published in the new format, and the info page for each new RFC will include icons that link to the associated new publication format. The XML itself will also be available for direct download; this will be of use in particular for authors and working groups creating revisions of new format RFCs. The IETF Datatracker will also be pointing to the new formats.
Work is not entirely done – the requirement specifications for the new format need to be updated to reflect what we ended up with as a result of our implementation experience, and some consumers of RFCs have indicated a desire to see EPUB as an additional output format. But as a start, this is a huge step for the RFC Series and the people that write and consume these documents.
This work could not have been accomplished without the engagement of the RFC Series community, the RFC Format design team, and the RFC Production Center staff.
— by Heather Flanagan, RFC Series Editor