RFC Format Change FAQ - 28-October-2014
"Where can I read a summary of requirements, drafts,
and expected changes?"
The RFC format work has been documented in
draft. This draft is still in progress.
"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
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
"How soon can authors start using non-ASCII
characters in RFCs?"
Several questions remain regarding the inclusion of non-ASCII characters
within RFCs. While we are moving ahead with the intent of permitting
non-ASCII, UTF-8 encoded characters, these characters will only be allowed
in RFCs after the details of where and how new characters will be supported
have been determined, when we have tools that can support those characters
deployed, and the RFC Production Center is trained in the handling of such
characters. Guidance on the use of non-ASCII characters in RFCs is being
developed and documented
"What encodings will the RFC Editor
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 being
and the proposed v3 XML
vocabulary is being documented
"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
"What publication formats be available when the
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
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
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
Use of Non-ASCII Characters in RFCs".
That draft will remain in draft form until the RFC Editor feels confident we
have captured the necessary requirements and guidance needed for handling
non-ASCII characters in RFCs.
"What are the Internet-Drafts related to the
RFC format effort?"
- Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", Work in
- Flanagan, H., "RFC Format Framework", Work in
- Flanagan, H., "Requirements for Plain Text RFCs", Work in
- Flanagan, H., "The Use of Non-ASCII Characters in RFCs", Work in Progress,
- Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC Series Output
Document Format", Work in
- Hildebrand, J. and H. Flanagan, Ed., "HyperText Markup Language Request
For Comments Format", Work in
- Hoffman, P., "The 'XML2RFC' version 3 Vocabulary", Work in
- Reschke, J., "The 'XML2RFC' version 2 Vocabulary", Work in
This page was last updated on 28 October 2014