Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 6949 RFC Series Editor
Updates: 2223 N. Brownlee
Category: Informational Independent Submissions Editor
ISSN: 2070-1721 May 2013
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 6949 RFC Series Editor
Updates: 2223 N. Brownlee
Category: Informational Independent Submissions Editor
ISSN: 2070-1721 May 2013
RFC Series Format Requirements and Future Development
RFC系列格式要求及未来发展
Abstract
摘要
This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.
本文档描述了RFCs规范版本格式的当前要求和增强请求。术语的定义有助于明确文档生成的哪些阶段正在讨论格式更改。本文件中描述的要求将决定对RFC格式进行哪些更改。本文件更新了RFC 2223。
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 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第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/rfc6949.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6949.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
1.1. Terminology ................................................3
2. History and Goals ...............................................4
2.1. Issues Driving Change ......................................5
2.1.1. ASCII Art ...........................................5
2.1.2. Character Encoding ..................................6
2.1.3. Pagination ..........................................7
2.1.4. Reflowable Text .....................................8
2.1.5. Metadata and Tagging ................................8
2.2. Further Considerations .....................................9
2.2.1. Creation and Use of RFC-Specific Tools ..............9
2.2.2. Markup Language ....................................10
2.3. RFC Editor Goals ..........................................10
3. Format Requirements ............................................10
3.1. Original Requirements to Be Retained ......................10
3.2. Requirements to Be Added ..................................11
3.3. Requirements to Be Retired ................................12
4. Security Considerations ........................................13
5. Informative References .........................................13
6. Acknowledgements ...............................................13
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. History and Goals ...............................................4
2.1. Issues Driving Change ......................................5
2.1.1. ASCII Art ...........................................5
2.1.2. Character Encoding ..................................6
2.1.3. Pagination ..........................................7
2.1.4. Reflowable Text .....................................8
2.1.5. Metadata and Tagging ................................8
2.2. Further Considerations .....................................9
2.2.1. Creation and Use of RFC-Specific Tools ..............9
2.2.2. Markup Language ....................................10
2.3. RFC Editor Goals ..........................................10
3. Format Requirements ............................................10
3.1. Original Requirements to Be Retained ......................10
3.2. Requirements to Be Added ..................................11
3.3. Requirements to Be Retired ................................12
4. Security Considerations ........................................13
5. Informative References .........................................13
6. Acknowledgements ...............................................13
1 Introduction
1导言
Over 40 years ago, the RFC Series began as a collection of memos in an environment that included handwritten RFCs, typewritten RFCs, RFCs produced on mainframes with complicated layout tools, and more. As the tools changed and some of the source formats became unreadable, the core individuals behind the Series realized that a common format that could be read, revised, and archived long in the future was required. US-ASCII was chosen for the encoding of characters, and after a period of variability, a well-defined presentation format was settled upon. That format has proved to be persistent and reliable across a large variety of devices, operating systems, and editing tools. That stability has been a continuing strength of the Series. However, as new technology, such as small devices and advances in display technology, comes into common usage, there is a growing desire to see the format of the RFC Series adapt to take advantage of these different ways to communicate information.
40多年前，RFC系列开始于一个备忘录的收集环境，其中包括手写RFC、打字RFC、大型机上使用复杂布局工具生成的RFC等。随着工具的改变，一些源格式变得不可读，该系列的核心人物意识到，需要一种在未来很长时间内可以读取、修改和存档的通用格式。字符编码选择US-ASCII，经过一段时间的变化后，确定了定义良好的表示格式。事实证明，这种格式在各种设备、操作系统和编辑工具中都是持久和可靠的。这种稳定性一直是该系列的持续优势。然而，随着诸如小型设备和显示技术的进步等新技术的普遍使用，人们越来越希望看到RFC系列的格式能够适应这些不同的信息通信方式。
Since the format stabilized, authors and readers have suggested enhancements to the format. However, no suggestion developed clear consensus in the Internet technical community. As always, some individuals see no need for change, while others press strongly for specific enhancements.
由于格式稳定，作者和读者建议对格式进行增强。然而，没有任何建议在互联网技术界形成明确的共识。和往常一样，一些人认为没有必要进行更改，而另一些人则强烈要求进行特定的增强。
This document takes a look at the current requirements for RFCs as described in RFC 2223 [RFC2223] and more recently in 2223bis [2223bis]. Section 2 reviews recent requests for enhancements as understood from community discussion and various proposals for new formats including HTML, XML, PDF, and EPUB. The actual requirements are then captured in Section 3. The focus of this document is on the Canonical format of RFCs, but some mention of other phases in the RFC publication process and the document formats associated with these phases is also included. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes.
本文件介绍了RFC 2223[RFC2223]以及最近的2223bis[2223bis]中所述的RFC的当前要求。第2节回顾了社区讨论和各种新格式建议（包括HTML、XML、PDF和EPUB）中了解到的最近的增强请求。第3节将介绍实际需求。本文档的重点是RFC的规范格式，但也包括RFC发布过程中的其他阶段以及与这些阶段相关的文档格式。术语的定义有助于明确文档生成的哪些阶段正在讨论格式更改。
ASCII: Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986 [ASCII]
ASCII：编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986[ASCII]
Canonical format: the authorized, recognized, accepted, and archived version of the document * Currently: formatted plain text
规范格式：文档的授权、识别、接受和存档版本*当前：格式化纯文本
Metadata: information associated with a document so as to provide, for example, definitions of its structure, or of elements within the document such as its topic or author
元数据：与文档相关联的信息，例如提供文档结构或文档中元素（如主题或作者）的定义
Publication format: display and distribution format as it may be read or printed after the publication process has completed * Currently published by the RFC Editor: formatted plain text, PDF of the formatted plain text, PDF that contains figures (rare) * Currently made available by other sites: HTML, PDF, others
出版格式：出版过程完成后可阅读或打印的显示和分发格式*目前由RFC编辑器发布：格式化纯文本、格式化纯文本的PDF、包含数字的PDF（罕见）*目前由其他网站提供：HTML、PDF、其他
Reflowable text: text that automatically wraps to the next line in a document as the user moves the margins of the text, either by resizing the window or changing the font size
可回流文本：当用户移动文本边距时，通过调整窗口大小或更改字体大小，自动换行到文档中的下一行的文本
Revisable format: the format that will provide the information for conversion into a Publication format; it is used or created by the RFC Editor (see Section 2.3 for an explanation of current practice) * Currently: XML (optional), nroff (required)
可修改格式：提供信息以转换为出版物格式的格式；它由RFC编辑器使用或创建（有关当前实践的解释，请参见第2.3节）*当前：XML（可选）、nroff（必需）
Submission format: the format submitted to the RFC Editor for editorial revision and publication * Currently: formatted plain text (required), XML (optional), nroff (optional)
提交格式：提交给RFC编辑器进行编辑修订和发布的格式*当前：格式化纯文本（必需）、XML（可选）、nroff（可选）
Below are the current RFC format rules as defined in [RFC2223] and clarified in 2223bis.
以下是[RFC2223]中定义并在2223bis中阐明的当前RFC格式规则。
* The character codes are ASCII.
* 字符代码是ASCII码。
* Each page must be limited to 58 lines followed by a form feed on a line by itself.
* 每个页面必须限制为58行，然后在一行上单独添加一个表单提要。
* Each line must be limited to 72 characters followed by carriage return and line feed.
* 每行必须限制为72个字符，后跟回车符和换行符。
* No overstriking (or underlining) is allowed.
* 不允许过度拉伸（或划线）。
* These "height" and "width" constraints include any headers, footers, page numbers, or left-side indenting.
* 这些“高度”和“宽度”约束包括任何页眉、页脚、页码或左侧缩进。
* Do not fill the text with extra spaces to provide a straight right margin.
* 不要用额外的空格填充文本以提供直接的右页边距。
* Do not do hyphenation of words at the right margin.
* 不要在右边距处使用连字符。
* Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document.
* 不要使用脚注。如果需要这些注释，请将它们放在章节末尾或文档末尾。
* Use single spaced text within a paragraph, and one blank line between paragraphs.
* 在段落内使用单间距文本，段落之间使用一个空行。
* Note that the number of pages in a document and the page numbers on which various sections fall will likely change with reformatting. Thus, cross-references in the text by section number usually are easier to keep consistent than cross-references by page number.
* 请注意，文档中的页数以及各节所在的页码可能会随着格式的更改而改变。因此，文本中按章节编号的交叉引用通常比按页码的交叉引用更容易保持一致。
* RFCs in plain ASCII text may be submitted to the RFC Editor in e-mail messages (or as online files) in either the finished Publication format or in nroff. If you plan to submit a document in nroff please consult the RFC Editor first.
* 纯ASCII文本的RFC可通过电子邮件（或在线文件）以完成的出版物格式或nroff格式提交给RFC编辑器。如果您计划在nroff中提交文档，请先咨询RFC编辑器。
The precedent for additional formats, specifically PostScript, is described in RFC 2223 and has been used for a small number of RFCs:
RFC 2223中描述了附加格式（特别是PostScript）的先例，并已用于少量RFC：
Note that since the ASCII text version of the RFC is the primary version, the PostScript version must match the text version. The RFC Editor must decide if the PostScript version is "the same as" the ASCII version before the PostScript version can be published.
请注意，由于RFC的ASCII文本版本是主版本，因此PostScript版本必须与文本版本匹配。在发布PostScript版本之前，RFC编辑器必须确定PostScript版本是否与ASCII版本“相同”。
Neither RFC 2223 nor 2223bis uses the term 'metadata', though the RFC Editor currently refers to components of the text such as the Stream, Status (e.g., Updates, Obsoletes), Category, and ISSN as 'metadata'.
RFC 2223和2223bis均未使用术语“元数据”，尽管RFC编辑器目前将文本的组件（如流、状态（例如更新、淘汰）、类别和ISSN）称为“元数据”。
While some authors and readers of RFCs report that they find the strict limits of character encoding, line limits, and so on to be acceptable, others claim to find those limitations a significant obstacle to their desire to communicate and read the information via an RFC. With a broader community of authors currently producing RFCs and a wider range of presentation devices in use, the issues being reported by the community indicate limitations of the current Canonical format that must be reviewed and potentially addressed in the Canonical RFC format.
虽然一些RFC的作者和读者报告说，他们发现字符编码、行限制等的严格限制是可以接受的，但其他人声称，这些限制是他们希望通过RFC交流和阅读信息的一个重大障碍。由于目前有更广泛的作者群体在制作RFC，并且有更广泛的演示设备在使用，该群体报告的问题表明了当前规范格式的局限性，必须对其进行审查，并可能以规范RFC格式加以解决。
While the specific points of concern vary, the main issues discussed are:
虽然具体关注点各不相同，但讨论的主要问题是：
* ASCII art
* ASCII码艺术
* Character encoding
* 字符编码
* Pagination
* 标页码
* Reflowable text
* 可回流文本
* Metadata
* 元数据
Each area of concern has people in favor of change and people opposed to it, all with reasonable concerns and requirements. Below is a summary of the arguments for and against each major issue. These points are not part of the list of requirements; they are the inputs that informed the requirements discussed in Section 3 of this document.
每一个关注的领域都有赞成变革的人和反对变革的人，他们都有合理的关注点和要求。以下是支持和反对每个主要问题的论点摘要。这些要点不属于要求清单的一部分；它们是通知本文件第3节中讨论的要求的输入。
Arguments in favor of limiting all diagrams, equations, tables, and charts to ASCII art depictions only include:
支持将所有图表、方程式、表格和图表限制为ASCII艺术描述的论点仅包括：
* Dependence on advanced diagrams (or any diagrams) causes accessibility issues.
* 依赖高级图表（或任何图表）会导致可访问性问题。
* Requiring ASCII art results in people often relying more on clear written descriptions rather than just the diagram itself.
* 由于需要ASCII art，人们往往更依赖于清晰的书面描述，而不仅仅是图表本身。
* Use of the ASCII character set forces design of diagrams that are simple and concise.
* ASCII字符集的使用迫使图表的设计变得简单和简洁。
Arguments in favor of allowing the use of more complex diagrams in place of the current use of ASCII art include:
支持使用更复杂的图表代替当前使用ASCII art的论点包括：
* State diagrams with multiple arrows in different directions and labels on the lines will be more understandable.
* 在不同方向上有多个箭头的状态图和线条上的标签将更容易理解。
* Protocol flow diagrams in which each step needs multiple lines of description will be clearer.
* 协议流程图中的每个步骤都需要多行描述，这将更加清晰。
* Scenario descriptions that involve three or more parties with communication flows between them will be clearer.
* 涉及三方或三方以上且三方之间有通信流的场景描述将更加清晰。
* Given the difficulties in expressing complex equations with common mathematical notation, allowing graphic art would allow equations to be displayed properly.
* 考虑到用普通数学符号表达复杂方程的困难，允许图形艺术将允许正确显示方程。
* Complex art could allow for grayscale or color to be introduced into the diagrams.
* 复杂的艺术可以将灰度或颜色引入到图表中。
Two suggestions have been proposed regarding how graphics should be included: one that would have graphic art referenced as a separate document to the Publication format, and one that would allow embedded graphics in the Publication format.
关于如何包括图形，提出了两项建议：一项建议将图形艺术作为出版物格式的单独文件引用，另一项建议将允许在出版物格式中嵌入图形。
For most of the history of the RFC Series, the character encoding for RFCs has been ASCII. Below are arguments for keeping ASCII as well as arguments for expanding to UTF-8.
在RFC系列的大部分历史中，RFC的字符编码都是ASCII码。下面是保留ASCII的参数以及扩展到UTF-8的参数。
Arguments for retaining the ASCII-only requirement:
保留仅ASCII要求的参数：
* It is the most easy to search and display across a variety of platforms.
* 它是最容易在各种平台上搜索和显示的。
* In extreme cases of having to retype or scan hard copies of documents (it has been required in the past), ASCII is significantly easier to work with for rescanning and retaining all of the original information. There can be no loss of descriptive metadata such as keywords or content tags.
* 在必须重新键入或扫描文档硬拷贝的极端情况下（在过去是必需的），使用ASCII重新扫描和保留所有原始信息要容易得多。不能丢失描述性元数据，例如关键字或内容标记。
* If we expand beyond ASCII, it will be difficult to know where to draw the line on which characters are and are not allowed. There will be issues with dependencies on local file systems and processors being configured to recognize any other character set.
* 如果我们扩展到ASCII之外，就很难知道在哪里划出允许和不允许使用字符的界限。将本地文件系统和处理器配置为识别任何其他字符集时，会出现依赖关系问题。
* The IETF works in ASCII (and English). The Internet research, design, and development communities function almost entirely in English. That strongly suggests that an ASCII document can be properly rendered and read by everyone in the communities and audiences of interest.
* IETF使用ASCII（和英语）工作。互联网研究、设计和开发社区几乎完全用英语运作。这强烈表明，ASCII文档可以被社区中的每个人和感兴趣的受众正确呈现和阅读。
Arguments for expanding to allow UTF-8:
扩展以允许UTF-8的参数：
* In discussions of internationalization, actually being able to illustrate the issue is rather helpful, and you can't illustrate a Unicode code point with "U+nnnn".
* 在关于国际化的讨论中，实际上能够说明这个问题是相当有帮助的，并且不能用“U+nnnn”来说明Unicode代码点。
* It will provide the ability to denote protocol examples using the character sets those examples support.
* 它将提供使用这些示例支持的字符集表示协议示例的能力。
* It will allow better support for international character sets, in particular, allowing authors to spell their names in their native character sets.
* 它将允许更好地支持国际字符集，特别是允许作者在本地字符集中拼写自己的名字。
* Certain special characters in equations or quoted from other texts could be allowed.
* 方程式中的某些特殊字符或从其他文本中引用的字符是允许的。
* Citations of web pages using more international characters are possible.
* 引用使用更多国际字符的网页是可能的。
Arguments for strictly prescribed UTF-8 use:
严格规定UTF-8使用的理由：
* In order to keep documents as searchable as possible, ASCII-only should be required for the main text of the document, and some broader UTF-8 character set allowed under clearly prescribed circumstances (e.g., author names and references).
* 为了尽可能保持文档的可搜索性，应仅对文档的主要文本要求ASCII，并且在明确规定的情况下（例如，作者姓名和参考文献），允许使用一些更广泛的UTF-8字符集。
Arguments for continuing the use of discrete pages within RFCs:
在RFC中继续使用离散页面的参数：
* Ease of reference and printing; referring to section numbers is too coarse a method.
* 易于参考和打印；参考章节编号的方法过于粗糙。
Arguments for removing the pagination requirement:
删除分页要求的参数：
* Removing pagination will allow for a smoother reading experience on a wider variety of devices, platforms, and browsers.
* 删除分页将允许在更广泛的设备、平台和浏览器上获得更流畅的阅读体验。
* Removing pagination results in people often using subsections rather than page number for reference purposes, forcing what would otherwise be long sections to be broken into subsections. This would encourage documents that are better organized and simpler.
* 删除分页会导致人们经常使用小节而不是页码作为参考，迫使原本很长的部分被分成小节。这将鼓励更好地组织和更简单的文件。
Arguments against requiring text to be reflowable:
反对要求文本可回流的论点：
* Reflowable text may impact the usability of graphics and tables within a document.
* 可回流文本可能会影响文档中图形和表格的可用性。
Arguments for requiring text to be reflowable:
要求文本可回流的参数：
* RFCs are more readable on a wider variety of devices and platforms, including mobile devices and assorted screen layouts.
* RFC在更广泛的设备和平台上更具可读性，包括移动设备和各种屏幕布局。
While metadata requirements are not part of RFC 2223, there is a request that descriptive metadata tags be added as part of a revision of the Canonical RFC format. These tags would allow for enhanced content by embedding information such as links, tags, or quick translations and could help control the look and feel of the Publication format. While the lack of metadata in the current RFCs does not impact an RFC's accessibility or readability, several individuals have indicated that allowing metadata within the RFCs would make their reading of the documents more efficient.
虽然元数据要求不是RFC 2223的一部分，但有一个请求，即作为规范RFC格式修订版的一部分添加描述性元数据标记。这些标签可以通过嵌入链接、标签或快速翻译等信息来增强内容，并有助于控制出版物格式的外观。虽然当前RFC中缺少元数据不会影响RFC的可访问性或可读性，但一些人表示，允许RFC中使用元数据将提高他们阅读文档的效率。
Arguments for allowing metadata in the Canonical and Publication formats:
允许元数据采用规范格式和发布格式的参数：
* Metadata potentially allows readers to get more detail out of a document. For example, if non-ASCII characters are allowed in the Author's Address and Reference sections, metadata must include translations of that information.
* 元数据可能允许读者从文档中获取更多细节。例如，如果作者的地址和引用部分允许使用非ASCII字符，则元数据必须包含该信息的翻译。
Arguments against metadata in the final Canonical and Publication formats:
针对最终规范格式和发布格式的元数据的参数：
* Metadata adds additional overhead to the overall process of creating RFCs and may complicate future usability as a result of requiring backward compatibility for metadata tags.
* 元数据为创建RFC的整个过程增加了额外的开销，并且由于需要元数据标记的向后兼容性，可能会使未来的可用性变得复杂。
Some of the discussion beyond the issues described above went into a review of potential solutions. Those solutions and the debate around them added a few more points to the list of potential requirements for a change in RFC Format. In particular, the discussion of tools introduced the idea of whether a change in format should also include the creation and ongoing support of specific RFC authoring and/or rendering tools and whether the Canonical format should be a format that must go through a rendering agent to be readable.
上述问题之外的一些讨论进入了对潜在解决方案的审查。这些解决方案和围绕它们的辩论在RFC格式变更的潜在需求列表中又增加了几点。特别是，对工具的讨论引入了以下概念：格式更改是否还应包括特定RFC创作和/或呈现工具的创建和持续支持，以及规范格式是否应是必须通过呈现代理才能读取的格式。
Arguments in support of community-supported RFC-specific tools:
支持社区支持的RFC特定工具的参数：
* Given the community that would be creating and supporting these tools, there would be greater control and flexibility over the tools and how they implement the RFC format requirements.
* 鉴于将创建和支持这些工具的社区，将对这些工具以及它们如何实现RFC格式要求有更大的控制和灵活性。
* Community-supported tools currently exist and are in extensive use within the community, so it would be most efficient to build on that base.
* 社区支持的工具目前已经存在，并在社区中广泛使用，因此在这个基础上进行构建将是最有效的。
Arguments against community-supported RFC-specific tools:
反对社区支持的RFC特定工具的论点：
* We cannot be so unique in our needs that we can't use commercial tools.
* 我们的需求不能如此独特，以至于我们不能使用商业工具。
* Ongoing support for these tools adds a greater level of instability to the ongoing availability of the RFC Series through the decades.
* 几十年来，对这些工具的持续支持为RFC系列的持续可用性增加了更大程度的不稳定性。
* The community that would support these tools cannot be relied on to be as stable and persistent as the Series itself.
* 支持这些工具的社区不能像系列本身那样稳定和持久。
Arguments in support of a markup language as the Revisable format:
支持标记语言作为可修改格式的参数：
* Having a markup language such as XML or HTML allows for greater flexibility in creating a variety of Publication formats, with a greater likelihood of similarity between them.
* 使用XML或HTML等标记语言可以更灵活地创建各种发布格式，它们之间的相似性更大。
Arguments against a markup language as the Revisable format:
反对将标记语言作为可修改格式的参数：
* Having the Revisable format be in a markup language instead of in a simple text-formatting structure ties us in to specific tools and/or tool support going forward.
* 使可修改的格式采用标记语言而不是简单的文本格式结构将我们与特定的工具和/或未来的工具支持联系起来。
Currently, each RFC has an nroff file created prior to publication. For RFCs revised using an XML file, the nroff file is created by converting XML to nroff at the final step. As more documents are submitted with an XML file (of the RFCs published in 2012, approximately 65% were submitted with an XML file), this conversion is problematic in terms of time spent and data lost from XML. Making the publication process for the RFC Editor more efficient is strongly desired.
目前，每个RFC都有一个在发布之前创建的nroff文件。对于使用XML文件修订的RFC，nroff文件是通过在最后一步将XML转换为nroff来创建的。随着越来越多的文档使用XML文件提交（在2012年发布的RFC中，大约65%是使用XML文件提交的），这种转换在时间和XML数据丢失方面存在问题。强烈希望使RFC编辑器的发布过程更加高效。
Understanding the major pain points and balancing them with the expectation of long-term viability of the documents brings us to a review of what must be kept of the original requirements, what new requirements may be added, and what requirements may be retired. Detailed rules regarding how these changes will be implemented will be documented in a future RFC.
理解主要难点并将其与文件的长期可行性预期相平衡，使我们能够审查原始需求中必须保留的内容、可能添加的新需求以及可能失效的需求。关于如何实施这些变更的详细规则将记录在未来的RFC中。
Several components of the original format requirements must be retained to ensure the ongoing continuity, reliability, and readability of the Series:
必须保留原始格式要求的几个组成部分，以确保本系列的连续性、可靠性和可读性：
1. The content of an RFC must not change, regardless of format, once published.
1. RFC的内容在发布后不得更改，无论其格式如何。
2. The Canonical format must be persistent and reliable across a large variety of devices, operating systems, and editing tools for the indefinite future. This means the format must be both readable and editable across commonly used devices, operating systems, and platforms for the foreseeable future.
2. 规范格式必须在各种各样的设备、操作系统和编辑工具中保持持久性和可靠性，以适应不确定的未来。这意味着在可预见的未来，格式必须在常用设备、操作系统和平台上可读和可编辑。
3. While several Publication formats must be allowed, in order to continue support for the most basic reading and search tools and to provide continuity for the Series, at least one Publication format must be plain text.
3. 虽然必须允许多种出版物格式，但为了继续支持最基本的阅读和搜索工具，并为本系列提供连续性，至少必须有一种出版物格式为纯文本。
4. The boilerplate and overall structure of the RFC must be in accordance with current RFC and Style Guide requirements (see [RFC5741]).
4. RFC的样板和整体结构必须符合当前RFC和样式指南要求（见[RFC5741]）。
Issues such as overstriking, page justification, hyphenation, and spacing will be defined in the RFC Style Guide [Style].
RFC样式指南[Style]中将定义诸如超链接、页面对齐、连字符和间距等问题。
In addition to those continuing requirements, discussions with various members of the wider Internet community have yielded the following general requirements for the RFC Series.
除了这些持续的要求外，与更广泛的互联网社区的不同成员进行的讨论产生了以下RFC系列的一般要求。
5. The documents must be made accessible to people with visual disabilities through such means as including alternative text for images and limiting the use of color. See the W3C's accessibility documents [WCAG20] and the United Nations "Convention on the Rights of Persons with Disabilities" [UN2006] for guidance. Appropriate authoring tools are highly desirable but focus on the creation of Internet-Drafts, a topic outside the scope of the RFC Editor.
5. 必须通过包括图像替代文本和限制颜色使用等方式，使视觉残疾人士能够访问这些文件。请参阅W3C的无障碍文件[WCAG20]和联合国《残疾人权利公约》[UN2006]以获取指导。适当的创作工具是非常可取的，但重点是创建Internet草稿，这是RFC编辑器范围之外的主题。
6. The official language of the RFC Series is English. ASCII is required for all text that must be read to understand or implement the technology described in the RFC. Use of non-ASCII characters, expressed in a standard Unicode Encoding Form (such as UTF-8), must receive explicit approval from the document stream manager and will be allowed after the rules for the common use cases are defined in the Style Guide.
6. RFC系列的官方语言为英语。为了理解或实施RFC中描述的技术，所有必须阅读的文本都需要ASCII码。使用以标准Unicode编码形式（如UTF-8）表示的非ASCII字符必须得到文档流管理器的明确批准，并且在样式指南中定义了常见用例的规则后才允许使用。
7. The Submission and Publication formats need to permit extending the set of metadata tags, for the addition of labeled metadata. A predefined set of metadata tags must be created to make use of metadata tags consistent for the life of the Series.
7. 提交和发布格式需要允许扩展元数据标记集，以便添加标记的元数据。必须创建一组预定义的元数据标记，以便在系列的整个生命周期内使用一致的元数据标记。
8. Graphics may include ASCII art and a more complex form to be defined, such as SVG line art [SVG]. Color and grayscale will not be accepted. RFCs must correctly display in monochromatic black-and-white to allow for monochrome displays, black-and-white printing, and support for visual disabilities.
8. 图形可能包括ASCII艺术和要定义的更复杂的形式，如SVG线条艺术[SVG]。不接受颜色和灰度。RFC必须以黑白单色正确显示，以允许单色显示、黑白打印和支持视觉残疾。
9. The Canonical format must be renderable into self-contained Publication formats in order to be easily downloaded and read offline.
9. 规范格式必须可呈现为自包含的发布格式，以便轻松下载和脱机阅读。
10. Fixed-width fonts and non-reflowable text are required for ASCII-art sections, source code examples, and other places where strict alignment is required.
10. ASCII艺术部分、源代码示例和其他需要严格对齐的地方需要固定宽度字体和不可回流文本。
11. At least one Publication format must support readable print to standard paper sizes.
11. 至少有一种出版物格式必须支持标准纸张大小的可读打印。
12. The Canonical format should be structured to enable easy program identification and parsing of code or specifications, such as MIB modules and ABNF.
12. 规范格式的结构应便于程序识别和代码或规范解析，如MIB模块和ABNF。
The requirements of the RFC Editor regarding RFC format and the publication process include:
RFC编辑器关于RFC格式和发布过程的要求包括：
13. The final conversion of all submitted documents to nroff should be replaced by using an accepted Revisable format throughout the process.
13. 在整个过程中，所有提交的文件最终转换为nroff时，应使用可接受的可修改格式。
14. In order to maintain an efficient publication process, the RFC Editor must work with the minimal number of files required for each submission (not a tar ball of several discrete components).
14. 为了保持高效的发布过程，RFC编辑器必须使用每次提交所需的最少数量的文件（而不是几个离散组件的tar球）。
15. In order to maintain the focus of the RFC Editor on editing for clarity and consistency rather than document layout details, the number of Publication formats produced by the RFC editor must be limited.
15. 为了使RFC编辑器的重点保持在编辑的清晰性和一致性，而不是文档布局细节，必须限制RFC编辑器生成的出版物格式的数量。
16. Tools must support error checking against document layout issues as well as other format details (diagrams, line breaks, variable- and fixed-width fonts).
16. 工具必须支持针对文档布局问题以及其他格式细节（图表、换行符、可变和固定宽度字体）的错误检查。
Some of the original requirements will be removed from consideration, but detailed rules regarding how these changes will be implemented will be documented in a future RFC.
一些原始要求将从考虑中删除，但关于如何实施这些变更的详细规则将在未来的RFC中记录。
* Pagination ("Each page must be limited to 58 lines followed by a form feed on a line by itself.")
* 分页（“每个页面必须限制为58行，然后在一行上单独添加一个表单提要。”）
* Maximum line length ("Each line must be limited to 72 characters followed by carriage return and line feed.")
* 最大行长（“每行必须限制为72个字符，后跟回车符和换行符。”）
* Limitation to 100% ASCII text ("The character codes are ASCII.")
* 限制为100%ASCII文本（“字符代码为ASCII”）
This document sets out requirements for RFCs in their various formats; it does not concern interactions between Internet hosts. Therefore, it does not have any specific security considerations.
本文件规定了各种格式的RFC要求；它不涉及Internet主机之间的交互。因此，它没有任何具体的安全考虑。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[RFC5741]Daigle，L.，Ed.，Kolkman，O.，Ed.，和IAB，“RFC流，标题和样板”，RFC 57412009年12月。
[ASCII] American National Standard for Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII), ANSI X3.4-1986, American National Standards Institute, Inc., March 26, 1986.
[ASCII]美国信息系统国家标准-编码字符集-7位美国信息交换国家标准代码（7位ASCII），ANSI X3.4-1986，美国国家标准协会，1986年3月26日。
[2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[2223bis]Reynolds，J.和R.Braden，“征求意见书（RFC）作者须知”，正在进行的工作，2004年8月。
[Style] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in Progress, October 2012.
[风格]Flanagan，H.和S.Ginoza，“RFC风格指南”，正在进行的工作，2012年10月。
[SVG] Dahlstrom, E., Dengler, P., Grasso, A., Lilley, C., McCormack, C., Schepers, D., and J. Watt, "Scalable Vector Graphics (SVG) 1.1 (Second Edition)", W3C Recommendation, 16 August 2011, <http://www.w3.org/TR/SVG11/>.
[SVG]Dahlstrom，E.，Dengler，P.，Grasso，A.，Lilley，C.，McCormack，C.，Schepers，D.，和J.Watt，“可缩放矢量图形（SVG）1.1（第二版）”，W3C建议，2011年8月16日<http://www.w3.org/TR/SVG11/>.
[WCAG20] Caldwell, B., Cooper, M., Reid, L., and G. Vanderheiden, "Web Content Accessibility Guidelines (WCAG) 2.0", 11 December 2008, <http://www.w3.org/TR/WCAG20/>.
[WCAG20]考德威尔，B.，库珀，M.，里德，L.，和G.范德海登，“网络内容可访问性指南（WCAG）2.0”，2008年12月11日<http://www.w3.org/TR/WCAG20/>.
[UN2006] United Nations, "Convention on the Rights of Persons with Disabilities", December 2006.
[UN2006]联合国，《残疾人权利公约》，2006年12月。
The authors received a great deal of helpful input from the community in pulling together these requirements and wish to particularly acknowledge the help of Joe Hildebrand, Paul Hoffman, and John Klensin, who each published an Internet-Draft on the topic of potential format options before the IETF 84 BOF.
作者从社区中获得了大量有用的信息，以汇集这些需求，并希望特别感谢Joe Hildebrand、Paul Hoffman和John Klensin的帮助，他们在IETF 84 BOF之前各自发布了一份关于潜在格式选项主题的互联网草案。
Authors' Addresses
作者地址
Heather Flanagan RFC Series Editor
希瑟·弗拉纳根RFC系列编辑器
EMail: rse@rfc-editor.org
EMail: rse@rfc-editor.org
Nevil Brownlee Independent Submissions Editor
内维尔·布朗利独立投稿编辑
EMail rfc-ise@rfc-editor.org
电子邮件rfc-ise@rfc-编辑网