Format FAQ - 26-February-2014

  • "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 community.

  • "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 in draft-flanagan-nonascii.

  • 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 being documented in draft-reschke-xml2rfc-latest, and the proposed v3 XML vocabulary is being documented in draft-hoffman-xml2rfc.

  • "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 cutover starts?"
    HTML, TXT, and PDF will be the first publication formats available. EPUB is also expected, but is likely to 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 current thinking is that RFCs with images will include a written description and a reference to the PDF or HTML version. This is similar to current practice.

  • "How will non-ASCII characters be handled when rendering the plain text version of an RFC?"
    Since the question of where and when non-ASCII 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 "é").

  • "What are the Internet-Drafts related to the RFC format effort?"
    And look for "PDF for an RFC Series Output Document Format" coming soon.

  • This page was last updated on 26 February 2014