By: Heather Flanagan
Date: June 27, 2016
In March 2012, I attended my first IETF meeting as RFC Series Editor. It was my first opportunity to meet directly with the community and learn what they wanted from the RFC Series. The feedback was quite clear: the old ASCII-only format was no longer sufficiently meeting the needs and expectations of the community.
In fact, questions about the suitability of the ASCII-only format started at least a decade ago. With that much history around a desire for change, I wondered why it hadn’t happened sooner. The answer was quite simple—and it gave me a glimpse into just how challenging an effort this would be: many people wanted change, but there was no consensus on exactly what that change should be. Virtual wars were fought on mailing lists and in hallways as people promoted their preferred document format.
My first step, after determining the priority for such an effort, was to start gathering requirements. The rfc-interest mailing list became a hotbed of conversation, and several BoFs were held at subsequent IETF meetings to both review my understanding of the community’s requirements and collect more feedback. Between IETF meetings, I met with the RFC Production Center to ensure that editor requirements were also captured. The end result was the publication of RFC 6949, “RFC Series Format Requirements and Future Development.” This document captured the requirements at a high level, and set the stage for making the decision to target an XML format as the canonical RFC format, with other, more human-readable formats rendered from that XML. In addition, on 2 May 2013, the decision to allow non-ASCII characters and SVG artwork in a prescribed fashion was announced.
Many steps are needed to get from a declaration of intent to actual implementation. A design team was put together to help with the more detailed requirements necessary to write tools for authors and editors to create, edit, and publish documents in the new format. The team members include Nevil Brownlee (ISE), Heather Flanagan (RSE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.
Several Internet-Drafts have been created by design team members, including:
- The ‘XML2RFC’ version 2 Vocabulary (https://datatracker.ietf.org/doc/draft-reschke-xml2rfc/)
- The ‘XML2RFC’ version 3 Vocabulary (https://datatracker.ietf.org/doc/draft-hoffman-xml2rfc/)
- The Use of Non-ASCII Characters in RFCs (https://datatracker.ietf.org/doc/draft-flanagan-nonascii/)
- HyperText Markup Language Request For Comments Format (https://datatracker.ietf.org/doc/draft-hildebrand-html-rfc/)
- SVG Drawings for RFCs: SVG 1.2 RFC (https://datatracker.ietf.org/doc/draft-brownlee-svg-rfc/)
- PDF for an RFC Series Output Document Format (in progress)
Documenting the requirements in those drafts is a huge, critical piece of the new format effort. And there is still more to do—from prototyping code to test the requirements, to creating a digital preservation policy that describes how the RFC Editor will handle this new diversity in digital assets for future generations, to developing the actual production code that will generate the new formats. Changing a more than 40-year-old tradition of plain text documents is not something that can—or even should—happen without a great deal of planning and testing to ensure that RFCs remain a useful way to consume information on Internet standards, best practices, experiments, and information for decades to come.
Tune in to rfc-interest and the next format BoF for an update on the status of the format effort.