Format FAQ - 1-May-2013
What does this mean for authors who don't use xml2rfc?
How soon can authors start using non-ASCII characters in UTF-8?
What do these changes mean for xml2rfc?
What happens if an author wants to provide a plain text file rather than an XML file?
Will you republish any RFCs in to the new Canonical format?
How will images be handled for the plain text version of an RFC?
How will UTF-8 characters be handled when rendering the plain text version of an RFC?
"What does this mean for authors who don't use xml2rfc?"
In the short term, authors will continue to be able to submit their final
I-Ds (those already approved by the streams) in text, nroff, or XML.
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 UTF-8?"
Several questions remain regarding the inclusion of UTF-8 characters
within RFCs. While we are moving ahead with the intent of permitting UTF-8
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 UTF-8 characters deployed, and the RFC
Production Center is trained in the handling of such characters.
"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.
"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 day 1?"
This is still under discussion.
"Will you republish any RFCs in the new Canonical format?"
No changes will be made to published RFCs. However metadata
will likely be added to the RFC info pages to indicate what
tools are needed to view or edit the canonical version of the
"How will images be handled for the plain text version of an RFC?"
The current thinking is that RFCs with images will include a written
description and a reference to the PDF version. This is similar current
"How will UTF-8 characters be handled when rendering the plain text version of an RFC?"
Since the question of where and when UTF-8 characters should be permitted
is still under discussion, it is difficult to provide a definitive answer
to this question at this time. Current thinking (subject to change as we learn
more) is to require an ASCII version of the author names and contact
information for indexing and common reading purposes. Both versions of the
author's name would be displayed in the Authors' Addresses section, with
the ASCII plain text version in the header. Within an RFC, if the subject of
the RFC requires non-ASCII characters for implementation and understanding, a
Unicode code point may be required (see RFC 5895 as an example of how ASCII
and Unicode could be used). If non-ASCII characters are used in examples or
other non-normative texts, the ASCII version of the RFC will likely either
point to the HTML/PDF version OR a simple substitution will be made (if
possible) based on a published table of such substitutions (e.g., "e" for
This page was last updated on 1 May 2013