RFC Format Change FAQ – 25 January 2017
See also: Infographic about Future RFC Format
- Where can I read a summary of requirements, documents, and expected changes?
- Where are the high-level requirements for a change to the RFC Format published?
- What does this mean for authors who don’t use xml2rfc?
- How soon can authors start using non-ASCII characters in RFCs?
- What encodings will the RFC Editor accept?
- What do these changes mean for xml2rfc?
- What happens if an author wants to provide a plain text file rather than an XML file?
- What publication formats will be available when the cutover happens?
- Will you republish any RFCs in to the new Canonical format?
- How will images be handled for the plain text version of an RFC?
- What happens to paginated output?
- How will UTF-8 characters be handled when rendering the plain text version of an RFC?
- Where are the tools coming from to make all this happen?
- What documents are related to the RFC format effort?
- Are these RFCs the final say on the format changes?
- “Where can I read a summary of requirements, documents, and expected changes?”
The framework of the RFC format work has been documented in RFC 7990.
- “Where are the high-level requirements for a change to the RFC format published?”
The high-level requirements were captured in RFC 6949, “RFC Series Format Requirements and Future Development.”
- “What does this mean for authors who don’t use xml2rfc?”
Authors will continue to be able to submit their final I-Ds (those already approved by the streams) as a text or XML file. Authors can expect additional questions regarding potential metadata and element tags as we explore a broader use of XML.
Long-term implications for authors who do not use xml2rfc will be better understood after we have explored the full implication of tool changes and determined what seems to work most effectively for the RFC Editor and the community.
- “How soon can authors start using non-ASCII characters in RFCs?”
UTF-8 characters will be allowed once the v3 tools have been fully tested and moved into the RPC’s production tool chain. While a few exceptions (RFCs 8187, 8264, 8265, and 8266) were published before the v3 tools were available, these were used as test cases to fully understand the requirements for allowing UTF-8 in RFCs. For more details, see the mail from the RFC Series Editor on this topic.
- “What encodings will the RFC Editor accept?”
The RFC Editor will only accept files encoded as UTF-8.
- “What do these changes mean for xml2rfc?”
Several things, including (but not limited to) further encouraging the deprecation of xml2rfc v1, code enhancements for v2, some new or changed element definitions, and the archiving of different versions of the tool by the RFC Publisher after major updates. The v2 XML vocabulary is documented in RFC 7749, and the v3 XML vocabulary is documented in RFC 7991.
- “What happens if an author wants to provide a plain text file rather than an XML file?”
Authors will be allowed to submit a plain text file. It will have to be converted to a basic XML file prior to publication, and a tool that will assist with that is necessary for both the RFC Editor and the authors. See also “What does this mean for authors who don’t use xml2rfc?“
- “What publication formats be available when the transition happens?”
HTML, TXT, and PDF will be the first publication formats available. EPUB is also expected, and will be offered at a later date.
- “Will you republish any RFCs in the new Canonical format?”
No. No changes will be made to already-published RFCs.
- “How will images be handled for the plain text version of an RFC?”
The RFC Editor will accept both ASCII art and SVG. If only ASCII art is provided, it will be included in all publication formats. If ASCII art and SVG are both provided, ASCII art will be included in the plain text, and SVG in all other outputs. A note indicating alternative artwork is available is strongly advised. If only SVG is provided, a URI will be included in the plain-text publication format (destination TBD). All artwork and figures should have a complete written description.
- “What happens to paginated output?”
RFC 6949 retires the requirement for pagination. Pagination conflicts with the requirement for reflowable text, which is considered a more urgent requirement given the variety of devices and preferences of the readers and the ability to refer to specific locations within a document through other mechanisms. While some formats such as PDF are naturally paginated, other file formats such as HTML are not. Authors and readers are encouraged to refer to section numbers when referring to specific text within an RFC. Paragraph numbers (in addition to section numbers) are being discussed as a possibility for more granular reference targets.
- “How will non-ASCII characters be handled when rendering the plain text version of an RFC?”
The RFC Editor will be following the guidance provided in “The Use of Non-ASCII Characters in RFCs” (read the PDF).
- “Where are the tools coming from to make all this happen?”
The tools needed to create the publication outputs, to update idnits, to check the SVG, and more, are being created through the usual IETF tools process. SeanTek will develop the RFClint, svgcheck, and XML Diff tools, while Elf Tools will develop the IDNITS, Publication Formatter, and Text Submission tools. The SOWs for the tools are online at IAOC RFPs under “Archived RFPs”.
- “What documents are related to the RFC format effort?”
The RFC Format is a large project that has required several documents to capture the requirements found in each aspect of the work. The documents depend on each other, and they moved through the community review and publication process as a set to help keep those relationships intact. Several documents require understanding a separate document for full comprehension of the material. Below is the suggested reading order for the documents that describe the new RFC format requirements. The design team has done a great job in pulling all of this together, and many members of the community have reviewed these in parts and offered targeted feedback. The documents were published as Informational RFCs within the IAB stream (except for the last one under “Workflow and tools”).
- The big picture
- [RFC7990] Flanagan, H., “RFC Format Framework”, RFC 7990, DOI 10.17487/RFC7990, December 2016, http://www.rfc-editor.org/info/rfc7990.
- The underlying vocabulary
- [RFC7991] Hoffman, P., “The ‘xml2rfc’ Version 3 Vocabulary”, RFC 7991, DOI 10.17487/RFC7991, December 2016, http://www.rfc-editor.org/info/rfc7991.
- The outputs
- [RFC7992] Hildebrand, J. and P. Hoffman, “HTML Format for RFCs”, RFC 7992, DOI 10.17487/RFC7992, December 2016, http://www.rfc-editor.org/info/rfc7992.
- [RFC7993] Flanagan, H. “Cascading Style Sheets (CSS) Requirements for RFCs”, RFC 7993, DOI 10.17487/RFC7993, December 2016, http://www.rfc-editor.org/info/rfc7993.
- [RFC7994] Flanagan, H., “Requirements for Plain-Text RFCs”, RFC 7994, DOI 10.17487/RFC7994, December 2016, http://www.rfc-editor.org/info/rfc7994.
- [RFC7995] Hansen, T., Masinter, L., and M. Hardy, “PDF Format for RFCs”, RFC 7995, DOI 10.17487/RFC7995, December 2016, http://www.rfc-editor.org/info/rfc7995.
- [RFC7996] Brownlee, N., “SVG Drawings for RFCs: SVG 1.2 RFC”, RFC 7996, DOI 10.17487/RFC7996, December 2016, http://www.rfc-editor.org/info/rfc7996.
- Generalized requirements
- [RFC7997] Flanagan, H., “The Use of Non-ASCII Characters in RFCs”, RFC 7997, DOI 10.17487/RFC7997, December 2016, http://www.rfc-editor.org/info/rfc7997.
- Workflow and tools
- [RFC7998] Hildebrand, J. and P. Hoffman, “‘xml2rfc’ Version 3 Preparation Tool Description”, RFC 7998, DOI 10.17487/RFC7998, December 2016, http://www.rfc-editor.org/info/rfc7998.
- Hoffman, P. and T. Hansen, “Examples of the ‘XML2RFC’ Version 2 and 3 Vocabularies”, Work in Progress, draft-hoffman-rfcexamples-04, May 2015. Not to be published as an RFC.
- The Statements of Work
- available from the IAOC RFPs page
- The big picture
- “Are these RFCs the final say on the format changes?”
The published RFCs (RFCs 7990 through 7998) are the design documents as created by the RFC Format Design Team. As these designs are implemented and tested, we expect that the RFCs will need to be updated to capture what is practical and how the features are actually implemented. Issues and suggestions as offered by the community and the format tools developers will be tracked in the following GitHub repository: https://github.com/rfc-format. It is up to the project managers, Heather Flanagan (RSE) and Robert Sparks, to discuss the issues and suggestions with the community and then offer clear direction back to the developers as to what should be implemented. When the development and testing are complete, a set of -bis documents that capture the “as built” description for the format requirements will be drafted.