User Tools

Site Tools


design:format-and-content-rfcs

The v3 vocabulary will be used as part of the new RFC series format described in RFC 6949. See draft-hoffman-xml2rfc for more information about the v3 vocabulary.

RFCs will have multiple representations: the canonical document will be in XML using the v3 format, and many non- canonical representations (such as HTML and text) will be generated as well. The discussion of the design and content of RFCs is part of the overall discussion of the RFC framework.

Canonical RFCs

The canonical RFCs will not have any markup that uses a feature that is deprecated in the v3 vocabulary. The RFC processor will have a “convert with warnings” mode that will convert a v2 XML document to a v3 XML document and converts deprecated features wherever possible, issuing warnings for where it cannot convert. The processor will also have a “strict” mode that will issue errors if any deprecated features are in the input.

The canonical format for RFCs have a number of restrictions that the RFC Processor needs to enforce before a document can be published in its final form. In this “final” mode, the processor will give a hard error when an input XML file has:

  • any element or attribute listed as “deprecated” in the v3 vocabulary
  • XML comments
  • XML Processor Instructions
  • an external DTD
  • ENTITYs that have a SYSTEM component
  • <artwork> elements with a “src” attribute that points to a URI with a scheme other than “data:”
  • <cref> elements
  • any TAB characters

The RFC Processor will have a mode that gives hard errors on all of the above other than <cref> elements. This exception is to allow the RPC to insert <cref> elements in the working XML for notes to authors in AUTH 48, notes to IANA, and so on.

The RFC Processor will also generate values for the “boilerplateText” attribute in <rfc>, and “sectionNumber” in <section>, “figureNumber” in <figure>, and “partNumber” attributes in the many elements that can have it. These will be filled in by the RFC processor so that the canonical XML file has all of the same information as the non-canonical representations.

Non-canonical RFC Representations

As described in RFC 6949, the RFC Editor will publish non-canonical representations of RFCs. Those non-canonical representations will be derived from the canonical XML. The generation of these non-canonical representations means that there will be much more emphasis put on the RFC Processor.

The following sections list the current Internet Drafts on the non-canonical formats. At this time (October 2014), these drafts are still in active development, with significant changes still being made.

RFCs in HTML

draft-hildebrand-html-rfc describes the HTML representation of RFCs.

RFCs in PDF

draft-hansen-rfc-use-of-pdf describes the PDF representation of RFCs.

RFCs in Text

draft-flanagan-plaintext describes the plain text representation of RFCs.

design/format-and-content-rfcs.txt · Last modified: 2014/10/25 21:58 by paul