Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7994 RFC Editor
Category: Informational December 2016
ISSN: 2070-1721
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7994 RFC Editor
Category: Informational December 2016
ISSN: 2070-1721
Requirements for Plain-Text RFCs
纯文本RFC的要求
Abstract
摘要
In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.
2013年，在社区进行了大量讨论后，决定将RFC的纯文本、仅ASCII标准格式转换为XML标准格式，并使用该XML呈现更具可读性的格式。RFC 6949“RFC系列格式要求和未来开发”中定义了通知此变更的高级需求。对于IETF社区中的许多人来说，纯文本仍然是一种重要的格式，它将是从XML呈现的发布格式之一。本文档概述了纯文本RFC发布格式的呈现要求。这些要求不适用于格式转换之前发布的纯文本RFC。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7994.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7994.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Character Encoding ..............................................4
3. Figures and Artwork .............................................4
4. General Page Format Layout ......................................4
4.1. Headers and Footers ........................................5
4.2. Table of Contents ..........................................5
4.3. Line Width .................................................5
4.4. Line Spacing ...............................................5
4.5. Hyphenation ................................................5
5. Elements from the xml2rfc v3 Vocabulary .........................5
6. Security Considerations .........................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................7
IAB Members at the Time of Approval ................................8
Acknowledgements ...................................................8
Author's Address ...................................................8
1. Introduction ....................................................2
2. Character Encoding ..............................................4
3. Figures and Artwork .............................................4
4. General Page Format Layout ......................................4
4.1. Headers and Footers ........................................5
4.2. Table of Contents ..........................................5
4.3. Line Width .................................................5
4.4. Line Spacing ...............................................5
4.5. Hyphenation ................................................5
5. Elements from the xml2rfc v3 Vocabulary .........................5
6. Security Considerations .........................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................7
IAB Members at the Time of Approval ................................8
Acknowledgements ...................................................8
Author's Address ...................................................8
In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format [XML-ANNOUNCE]. The high-level requirements that informed this change were defined in [RFC6949], "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.
2013年，经过大量社区讨论，决定将RFC的纯文本、仅ASCII标准格式转换为XML标准格式[XML-1]。[RFC6949]，“RFC系列格式要求和未来发展”中定义了通知此变更的高级要求。对于IETF社区中的许多人来说，纯文本仍然是一种重要的格式，它将是从XML呈现的发布格式之一。本文档概述了纯文本RFC发布格式的呈现要求。这些要求不适用于格式转换之前发布的纯文本RFC。
The Unicode Consortium defines "plain text" as "Computer-encoded text that consists only of a sequence of code points from a given standard, with no other formatting or structural information.
Unicode联盟将“纯文本”定义为“计算机编码的文本，仅由给定标准的一系列代码点组成，没有其他格式或结构信息。
Plain-text interchange is commonly used between computer systems that do not share higher-level protocols." [UNICODE-GLOSSARY]. In other words, plain-text files cannot include embedded character formatting or style information. The actual character encoding, however, is not limited to any particular sequence of code points.
纯文本交换通常用于不共享高级协议的计算机系统之间。“[UNICODE-GLOSSARY]。换句话说，纯文本文件不能包含嵌入的字符格式或样式信息。但是，实际的字符编码不限于任何特定的码点序列。
A plain-text output for RFCs will continue to be required for the foreseeable future. The process of converting xml2rfc version 2 (xml2rfc v2) into text documents is well understood [RFC7749]. We plan to rely on the practice to date to inform the requirements for converting xml2rfc version 3 (xml2rfc v3) to text [RFC7991]. This document calls out those requirements that are changed from v2 or otherwise deserve special attention, such as the requirements around the character encoding that may be used; changes in the page layout; and changes in how figures, artwork, and pagination may be handled. For more details on general style, see "RFC Style Guide" [RFC7322].
在可预见的未来，将继续需要RFC的纯文本输出。将xml2rfc版本2（xml2rfc v2）转换为文本文档的过程是众所周知的[RFC7749]。我们计划根据迄今为止的实践，告知将xml2rfc版本3（xml2rfc v3）转换为文本[RFC7991]的要求。本文件提出了从v2更改的要求或需要特别注意的要求，如可能使用的字符编码要求；页面布局的变化；以及如何处理图形、艺术品和分页的变化。有关常规样式的更多详细信息，请参阅“RFC样式指南”[RFC7322]。
The following assumptions drive the changes in the plain-text output for RFCs:
以下假设导致RFC的纯文本输出发生变化：
o The existing tools used by the RFC Editor and many members of the author community to create the text file are complicated to change and support; manual manipulation is often required for the final output. In particular, handling page breaks and associated widows and orphans for paginated output is tricky [WIDOWS].
o RFC编辑器和作者社区的许多成员用于创建文本文件的现有工具很难更改和支持；最终输出通常需要手动操作。特别是，为分页输出处理分页符和相关的孤岛和孤岛非常棘手[widows]。
o Additional publication formats -- for example, PDF, HTML -- will be available that will offer features such as markup and pretty printing.
o 其他出版物格式——例如PDF、HTML——将提供标记和漂亮打印等功能。
o There is an extensive tool chain in existence among the community to work with plain-text documents. Similar functionality may be possible with other publication formats, but the workflow that uses the existing tool chain should be supported as much as is considered practical.
o 社区中有一个广泛的工具链，用于处理纯文本文档。其他出版物格式也可能具有类似的功能，但应尽可能支持使用现有工具链的工作流。
Where practical, the original guidance for the structure of a plain-text RFC has been kept (e.g., with line lengths, with lines per page [INS2AUTH]). Other publication formats, such as HTML and PDF, will include additional features that will not be present in the plain text (e.g., paragraph numbering, typographical emphasis).
在可行的情况下，保留了纯文本RFC结构的原始指南（例如，行长、每页行数[INS2AUTH]）。其他出版物格式，如HTML和PDF，将包括纯文本中不会出现的附加功能（例如段落编号、排版强调）。
The details described in this document are expected to change based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document.
本文档中描述的详细信息预计将根据在实施新发布工具集过程中获得的经验进行更改。修订后的文档将在工具集完成后发布，以捕获这些更改。其他实施者不得期望这些更改与本文档中描述的细节保持向后兼容。
Plain-text files for RFCs will use the UTF-8 [RFC3629] character encoding. That said, the use of non-ASCII characters will be only allowed in a limited and controlled fashion.
RFC的纯文本文件将使用UTF-8[RFC3629]字符编码。这就是说，非ASCII字符的使用将只允许以有限和受控的方式进行。
Many elements within the xml2rfc v3 vocabulary have an attribute for the ASCII equivalent to a non-ASCII character string. The ASCII equivalent will be rendered within the plain text as per the guidance in "The Use of Non-ASCII Characters in RFCs" [RFC7997]; please view the PDF version of that document.
xml2rfc v3词汇表中的许多元素都有一个ASCII属性，相当于非ASCII字符串。根据“RFC中非ASCII字符的使用”[RFC7997]中的指南，将在纯文本中呈现ASCII等效字符；请查看该文档的PDF版本。
The plain-text file will include a Byte Order Mark (BOM) to provide text reader software with in-band information about the character encoding scheme used.
纯文本文件将包括一个字节顺序标记（BOM），以向文本阅读器软件提供有关所用字符编码方案的带内信息。
Artwork, such as network diagrams or performance graphs, must be tagged by the XML <artwork> element (see Section 2.5 of "The 'xml2rfc' Version 3 Vocabulary" [RFC7991]. Where this artwork is comprised of an ASCII art diagram, it must be tagged as "type='ascii-art'". The plain-text format will only include ASCII art. If the canonical format includes figures or artwork other than ASCII art, then the plain-text output must include a pointer to the relevant figure in the HTML version of the RFC to allow readers to see the relevant artwork.
艺术品，如网络图或性能图，必须由XML<Artwork>元素标记（参见“xml2rfc”版本3词汇表[RFC7991]第2.5节）。如果此艺术品由ASCII艺术图组成，则必须将其标记为“type='ASCII-art'”。纯文本格式将仅包括ASCII艺术。如果规范格式包括ASCII艺术以外的图形或艺术品，则纯文本输出必须包括指向RFC HTML版本中相关图形的指针，以允许读者查看相关艺术品。
Authors who wish to include ASCII art for the plain-text file and SVG art for the other outputs may do so, but they should be aware of the potential for confusion to individuals reading the RFC with two unique diagrams describing the same content. If there is conflicting information between the publication formats, please review the XML and PDF files to resolve the conflict.
希望在纯文本文件中包含ASCII art，在其他输出中包含SVG art的作者可以这样做，但他们应该意识到阅读RFC的个人可能会对描述相同内容的两个独特图表产生混淆。如果发布格式之间存在冲突信息，请查看XML和PDF文件以解决冲突。
One plain-text output will be created during the publication process with basic pagination that includes a form feed instruction every 58 lines at most, including blank lines. Instructions or a script will be made available by and for the community to strip out pagination as per individual preference.
在发布过程中，将使用基本分页创建一个纯文本输出，该分页最多每58行（包括空行）包含一条换页指令。社区将根据个人喜好提供说明或脚本，以去除分页。
The front matter on the front page (such as the RFC number and category) and the back matter on the last page (the authors' full names and contact information) will continue with the structure described in RFC 7841 [RFC7841], "RFC Streams, Headers, and Boilerplates". Running headers and footers will no longer be added.
首页的首页内容（如RFC编号和类别）和最后一页的背面内容（作者的全名和联系信息）将继续采用RFC 7841[RFC7841]，“RFC流、标题和样板”中描述的结构。将不再添加正在运行的页眉和页脚。
In order to retain similar content wherever possible between the various publication formats, the table of contents will list section and subsection numbers and titles but will not include page numbers.
为了尽可能保留不同出版格式之间的类似内容，目录将列出章节号、小节号和标题，但不包括页码。
Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). The EOL sequence used by the RFC Editor will be the two-character sequence CR LF (Carriage Return followed by Line Feed). This limit includes any left-side indentation.
每行必须限制为72个字符，后跟表示行尾（EOL）的字符序列。RFC编辑器使用的下线序列为两字符序列CR LF（回车后换行）。此限制包括任何左侧压痕。
Note that the EOL used by the RFC Editor may change with different transports and as displayed in different display software.
请注意，RFC编辑器使用的下线可能会随着不同的传输和显示软件的不同而变化。
Use single-spaced text within a paragraph, and one blank line between paragraphs.
在段落内使用单间距文本，段落之间使用一个空行。
Hyphenated words (e.g., "Internet-Draft") should not be split across successive lines.
连字符的单词（例如，“Internet草稿”）不应在连续的行中拆分。
The plain-text formatter uses the relevant tags from the xml2rfc v3 source file to build a document conforming to the layout and structure described by the full RFC Style Guide [RFC7322] (including the updates in the web portion of the Style Guide) [STYLEWEB].
纯文本格式化程序使用xml2rfc v3源文件中的相关标记来构建符合完整RFC样式指南[RFC7322]（包括样式指南web部分中的更新）[STYLEWEB]所述布局和结构的文档。
The requirements of the plain-text format involve no significant security considerations. As part of the larger format project, however, unintended changes to the text as a result of the transformation from the base XML file could in turn corrupt a standard, practice, or critical piece of information about a protocol.
纯文本格式的要求不涉及重大的安全考虑。但是，作为更大格式项目的一部分，由于从基本XML文件转换而对文本进行的意外更改可能反过来破坏协议的标准、实践或关键信息。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <http://www.rfc-editor.org/info/rfc6949>.
[RFC6949]Flanagan，H.和N.Brownlee，“RFC系列格式要求和未来发展”，RFC 6949，DOI 10.17487/RFC6949，2013年5月<http://www.rfc-editor.org/info/rfc6949>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322]Flanagan，H.和S.Ginoza，“RFC风格指南”，RFC 7322，DOI 10.17487/RFC7322，2014年9月<http://www.rfc-editor.org/info/rfc7322>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, <http://www.rfc-editor.org/info/rfc7749>.
[RFC7749]Reschke，J.“xml2rfc”版本2词汇表”，RFC 7749，DOI 10.17487/RFC7749，2016年2月<http://www.rfc-editor.org/info/rfc7749>.
[RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, <http://www.rfc-editor.org/info/rfc7841>.
[RFC7841]Halpern，J.，Ed.，Daigle，L.，Ed.，和O.Kolkman，Ed.，“RFC流，标题和样板”，RFC 7841，DOI 10.17487/RFC78412016年5月<http://www.rfc-editor.org/info/rfc7841>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>.
[RFC7991]Hoffman，P.“xml2rfc”版本3词汇表”，RFC 7991，DOI 10.17487/RFC7991，2016年12月<http://www.rfc-editor.org/info/rfc7991>.
[RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <http://www.rfc-editor.org/info/rfc7997>.
[RFC7997]Flanagan，H.，Ed.，“RFC中非ASCII字符的使用”，RFC 7997，DOI 10.17487/RFC7997，2016年12月<http://www.rfc-editor.org/info/rfc7997>.
[INS2AUTH] RFC Editor, "Instructions to Request for Comments (RFC) Authors", August 2004, <https://www.rfc-editor.org/ materials/instructions2authors.txt>.
[INS2AUTH]RFC编辑，“征求意见（RFC）作者须知”，2004年8月<https://www.rfc-editor.org/ 资料/说明2authors.txt>。
[STYLEWEB] RFC Editor, "Web Portion of the Style Guide", February 2016, <http://www.rfc-editor.org/styleguide/part2/>.
[STYLEWEB]RFC编辑器，“样式指南的Web部分”，2016年2月<http://www.rfc-editor.org/styleguide/part2/>.
[UNICODE-GLOSSARY] The Unicode Consortium, "Glossary of Unicode Terms", September 2016, <http://www.unicode.org/glossary/>.
[UNICODE-GLOSSARY]UNICODE联盟，“UNICODE术语表”，2016年9月<http://www.unicode.org/glossary/>.
[WIDOWS] Wikipedia, "Widows and orphans", September 2016, <https://en.wikipedia.org/w/ index.php?title=Widows_and_orphans&oldid=738356204>.
[寡妇]维基百科，“寡妇和孤儿”，2016年9月<https://en.wikipedia.org/w/ index.php？title=寡妇和孤儿&oldid=738356204>。
[XML-ANNOUNCE] Flanagan, H., "Subject: Direction of the RFC Format Development effort", May 2013, <http://www.rfc-editor.org/pipermail/ rfc-interest/2013-May/005584.html>.
[XML-ANNOUNCE]Flanagan，H.，“主题：RFC格式开发工作的方向”，2013年5月<http://www.rfc-editor.org/pipermail/ rfc利息/2013年5月/005584.html>。
IAB Members at the Time of Approval
批准时的IAB成员
The IAB members at the time this memo was approved were (in alphabetical order):
本备忘录批准时，IAB成员为（按字母顺序排列）：
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
贾里·阿克科·拉尔夫·德罗姆斯·泰德·哈迪·乔·希尔德布兰德·罗斯·霍斯利·李·霍华德·埃里克·诺德马克·罗伯特·斯帕克斯·安德鲁·沙利文·戴夫·泰勒·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
This document owes a great deal of thanks to the efforts of the RFC Format Design Team: Nevil Brownlee, Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks, and David Thaler.
本文档非常感谢RFC格式设计团队的努力：Nevil Brownlee、Tony Hansen、Joe Hildebrand、Paul Hoffman、Ted Lemon、Julian Reschke、Adam Roach、Alice Russo、Robert Sparks和David Thaler。
Author's Address
作者地址
Heather Flanagan RFC Editor
希瑟·弗拉纳根RFC编辑
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220