RFC Format Change FAQ – 13 May 2019
See also: Infographic about the v3 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 are available now that we’ve transitioned to v3?
- 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 tools do you recommend to create SVG files?
- What documents are related to the RFC format effort?
- Are these RFCs the final say on the format changes?
- What is the transition plan for moving from v2 to v3?
- “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 are permitted and are now being used in xml2rfc v3. 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 to the core code base, 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 using id2xml. See also “What does this mean for authors who don’t use xml2rfc?“
- “What publication formats are available now that we’ve transitioned to v3?”
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. That said, there will be HTMLized RFCs (created using rfc2html) for all pre-v3 RFCs. This will allow proper linking from the text of a v3 RFC to an earlier RFC.
- “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 pointing to the HTML version. All artwork and figures should have a complete written description to support assisted reader technology.
- “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) will be generated in the v3 HTML and PDF output formats 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, have been developed through the usual IETF tools process. All tools have been released to the community. A list of the tools is available on the Format Tools Plan.
- “What tools do you recommend to create SVG files?”
The author of RFC 7996, “SVG Drawings for RFCs: SVG 1.2 RFC” has made a few recommendations available here. See also xml2rfc Frequently Asked Questions. Please note that the RFC Editor will not directly edit SVG images.
- “What documents are related to the RFC format effort?”
The RFC Format effort 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.
- “What is the transition plan for moving from v2 to v3?”
There will be a clean cutover to the v3 format. The AUTH48 queue will be drained, and new documents delayed being moved into AUTH48 so that the RFC Editor can avoid having simultaneous v2 and v3 processes. The current target date range for the cutover is August 2019; all dates will be clearly communicated when established.