RFC Format Change FAQ – 27 January 2021

See also: Infographic about the v3 RFC Format

  • “Where can I read a summary of requirements, documents, and changes?”
    The framework of the RFC format work has been documented in RFC 7990.

 

  • “Where were 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.

 

  • “Where can I use non-ASCII characters in RFCs?”
    UTF-8 characters are permitted in xml2rfc v3. For more details, see RFC 7997 and the xml2rfc FAQ.

 

  • “What encodings does the RFC Editor accept?”
    The RFC Editor accepts files encoded as ASCII or as UTF-8.

 

  • “What do these changes mean for xml2rfc?”
    The RFC Editor is now using xml2rfc v3. The v3 XML vocabulary is documented in RFC 7991 and the schema documentation. Authors with v2 drafts can mechanically translate them to v3 using xml2rfc --v2v3.

 

 

  • “What publication formats are available now that we’ve transitioned to v3?”
    HTML, TXT, and PDF are the first publication formats available. EPUB is also expected, and may 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. We provide HTMLized versions of pre-v3 RFCs (created mechanically using rfc2html). This allows proper linking from the text of a v3 RFC to an earlier RFC.

 

  • “How are images 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. We are providing the ability to refer to specific locations within the document through other mechanisms. The PDF versions of RFCs are naturally paginated, while other file formats are not. Authors and readers should refer to section numbers when referring to specific text within an RFC. Paragraph numbers (in addition to section numbers) can be generated in the v3 HTML and PDF output formats for more granular reference targets.

 

  • “How are non-ASCII characters handled when rendering the plain text version of an RFC?”
    The RFC Editor follows the guidance provided in RFC 7997.

 

 

  • “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 the xml2rfc FAQ. Please note that the RFC Editor will not directly edit SVG images.

 

 


Advanced Search
  翻译：