by Marshall T. Rose, Dover Beach Consulting, Inc. and Carl Malamud, Public Resource, Inc.
What is the work product of the Internet Engineering Task Force (IETF)? Some cynical observers might suggest "many fine lunches or dinners," but we argue that those niceties are merely the means to an end. The goal of the IETF is to provide open standards for the Internet community, and those standards are memorialized as written documents called Request For Comments (RFCs).
In general, two organizations control the publication of documents as RFCs:
For a more detailed discussion of the interaction between these two organizations, consult RFC 3932 .
As an organization, the IETF excels at "eating its own dog food," including its work product: just as a protocol specification describes interactions on the wire but does not dictate the programming language used for implementation, so too, the IETF has not really cared which document preparation tools are used. The IESG worries about technical quality, and the RFC Editor worries about stylistic consistency (and, to be fair, technical quality as well). This policy works because of the careful choices made by the early Internet community, and in particular the RFC Editor, with respect to the "final form" footprint of the documents. (A discussion of these design decisions is far beyond the scope of this short article—for now, we note that it is hard to argue with success.)
An unfortunate side effect of this focus on stylistic consistency is that, for many years, the RFC Editor has had to recode documents for consistent formatting. Internally, the RFC Editor used nroff  for this purpose, and sophisticated authors wishing to minimize RFC Editor "downtime" tended to use the same nroff boilerplate. The nroff text-formatting program has many strengths, but it can also be fairly viewed as a textual "assembly language," with the result that authors spent a lot of time dealing with low-level formatting concerns.
In some limited cases, the high degree of formatting-specific expertise is warranted, but for the vast majority of documents, the high entry cost is not.
From Assembly Language to Markup
In early 1999 we were working at a startup company, and we needed a way to organize, search, and retrieve information from documents. We decided to use a markup language for this purpose. We also decided to use the RFC series as one of the testing grounds for the technology, because this series was one we were familiar with. Although today everyone knows what the Extensible Markup Language (XML) is, then there were only two widely known markup languages for authoring: SGML and HTML.
The "SG" in SGML is an abbreviation for Standard Generalized and not Simple Generic. SGML is used for the formatting of a great many books; further, it is used in large projects with long lifetimes. Although truly excellent from an "enumerate every possibility" standpoint, it has a very high cost of entry, making it difficult to use for anything other than specialized applications.
In contrast, the Hypertext Markup Language (HTML) embodies elegance of design, but (in the absence of Cascading Style Sheets [CSS]), is a presentation language, not unlike nroff in many respects. In other words, we needed something with the structural richness of SGML and the elegant simplicity of HTML. The newly invented XML seemed to meet the requirements.
This process led us to develop a language based on XML, which captured high-level RFC constructs (for example, authorship information) and largely ignored presentational concerns. The result is called the 2629 format  (also known as the "xml2rfc format," named after the initial processor for this language).
The Advantages of Markup
To understand the advantages of this approach, let's look at one example: references. Like most archival series, the RFC Editor has a very rigorous, yet unstructured, syntax for citations. Although this consistency is good for readers of RFCs, achieving consistency of references using tools such as nroff was often the hardest part of creating a new document. With the 2629 format, the <reference> element contains a small number of subordinate elements that capture all the semantics of the reference. The XML processor takes this information and produces a properly formatted document.
Further, because this information is structured, it is possible to develop automated bibliographic databases for a wide range of data sources. In fact, using the XML "include" mechanism, a document author usually includes just a pointer to the reference, and lets the processor do all the complicated work.
A second advantage is that processors can produce different kinds of output. Some people prefer to view their documents in HTML rather than the canonical textual format. Julian Reschke has written a library of XSLT files that convert to various HTML formats (Strict, Transitional, XHTML, and so on). For example, references are hyperlinked in line, allowing for easy traversal of citations. Still others prefer the Portable Document Format (PDF) for printing. By using one of Julian's XSLT scripts and the truly excellent Prince  XML/CSS processor, the result is high-quality, printer-ready output.
However, the primary advantage is that the "high-level" approach allows the author to focus more on content and less on format: a processor can enforce the vast majority of the esoterica associated with the RFC Editorial style, including:
To Infinity and Beyond
After publishing RFC 2629, an unexpected result occurred: people outside the IETF started using the 2629 format for their projects. Most credit for this side effect goes to the universality of the canonical textual format. However, some authors are using the 2629 format when writing books (they convert the 2629 format to SGML, which is sent to the publisher), business plans, and software documentation—and even to create a new series of non-IETF technical documents. The constituency here seems to revolve around having a simple yet structured way to author documents.
For the last few years, a large number of XML editing programs have been deployed, and many of these support the 2629 format. These editors offer two advantages: first, they provide a natural paradigm for editing nested content; and, second, sophisticated editors can be integrated into an automated work flow. (Having said that, the authors still use Emacs and vi for their XML editors.)
A good example of the use of XML editors is a "plug-in" for the XMLMind Editor . This plug-in, written by Bill Fenner, provides a variety of services to the author, such as graphical editing of sections, templates for common constructs, and validation of references.
Over the last 10 years, the 2629 format has evolved in true IETF fashion, based on running code and a rough consensus. Originally created by the authors for our own convenience, we have been more than pleased to see this format used first by an informal community of developers and writers, and more recently by the IETF secretariat, tools team, and administrative entity and by the RFC Editor.
Today, many people use a common high-level markup language for writing RFCs. The next step in this natural evolution will be making the repository of XML-tagged RFCs available to those involved in document distribution, so that RFC repositories will be able to take advantage of the meta-data in the creation of search engine, alternative formats, and any other value-added constructs that would be of use to the community. (At present the RFC Editor prefers input in the 2629 format, but ultimately runs a processor that generates nroff for "tweaking"—in the near future, we hope that the xml2rfc textual output can be tuned to avoid this final step.)
To find out more, go to the xml2rfc Website  or visit the official directory of IETF authoring tools .