Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7322 S. Ginoza
Obsoletes: 2223 RFC Editor
Category: Informational September 2014
ISSN: 2070-1721
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7322 S. Ginoza
Obsoletes: 2223 RFC Editor
Category: Informational September 2014
ISSN: 2070-1721
RFC Style Guide
RFC风格指南
Abstract
摘要
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".
本文档描述了RFC系列当前使用的基本和独特的样式约定以及编辑策略。它捕获了RFC编辑器的基本需求，并提供了有关RFC样式和结构的指导。其他指南可在网站上获取，该网站反映了该指南的实验性质，并为将来纳入RFC风格指南做好准备。本文件废除了RFC 2223“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 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/rfc7322.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7322.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................3
2. RFC Editor's Philosophy .........................................4
3. RFC Style Conventions ...........................................5
3.1. Language ...................................................5
3.2. Punctuation ................................................5
3.3. DNS Names and URIs .........................................6
3.4. Capitalization .............................................6
3.5. Citations ..................................................6
3.6. Abbreviation Rules .........................................7
4. Structure of an RFC .............................................8
4.1. First-Page Header ..........................................9
4.1.1. Author/Editor .......................................9
4.1.2. Organization ........................................9
4.1.3. "ISSN: 2070-1721" ..................................10
4.1.4. Updates and Obsoletes ..............................10
4.2. Full Title ................................................10
4.3. Abstract Section ..........................................11
4.4. RFC Editor or Stream Notes Section ........................11
4.5. Status of This Memo Section ...............................11
4.6. Copyright, Licenses, and IPR Boilerplate Section ..........11
4.7. Table of Contents Section .................................11
4.8. Body of the Memo .........................................12
4.8.1. Introduction Section ...............................12
4.8.2. Requirement Language Section .......................12
4.8.3. IANA Considerations Section ........................13
4.8.4. Internationalization Considerations Section ........13
4.8.5. Security Considerations Section ....................13
4.8.6. References Section .................................14
4.8.6.1. URIs in RFCs ..............................15
4.8.6.2. Referencing RFCs ..........................15
4.8.6.3. Referencing STDs and BCPs .................16
4.8.6.4. Referencing Internet-Drafts ...............17
4.8.6.5. Referencing Errata ........................18
4.8.6.6. Referencing Other Standards Development
Organizations (SDOs) ......................18
4.9. Appendices Section ........................................19
4.10. Acknowledgements Section .................................19
4.11. Contributors Section .....................................19
4.12. "Author's Address" or "Authors' Addresses" Section .......20
5. Security Considerations ........................................20
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................20
1. Introduction ....................................................3
2. RFC Editor's Philosophy .........................................4
3. RFC Style Conventions ...........................................5
3.1. Language ...................................................5
3.2. Punctuation ................................................5
3.3. DNS Names and URIs .........................................6
3.4. Capitalization .............................................6
3.5. Citations ..................................................6
3.6. Abbreviation Rules .........................................7
4. Structure of an RFC .............................................8
4.1. First-Page Header ..........................................9
4.1.1. Author/Editor .......................................9
4.1.2. Organization ........................................9
4.1.3. "ISSN: 2070-1721" ..................................10
4.1.4. Updates and Obsoletes ..............................10
4.2. Full Title ................................................10
4.3. Abstract Section ..........................................11
4.4. RFC Editor or Stream Notes Section ........................11
4.5. Status of This Memo Section ...............................11
4.6. Copyright, Licenses, and IPR Boilerplate Section ..........11
4.7. Table of Contents Section .................................11
4.8. Body of the Memo .........................................12
4.8.1. Introduction Section ...............................12
4.8.2. Requirement Language Section .......................12
4.8.3. IANA Considerations Section ........................13
4.8.4. Internationalization Considerations Section ........13
4.8.5. Security Considerations Section ....................13
4.8.6. References Section .................................14
4.8.6.1. URIs in RFCs ..............................15
4.8.6.2. Referencing RFCs ..........................15
4.8.6.3. Referencing STDs and BCPs .................16
4.8.6.4. Referencing Internet-Drafts ...............17
4.8.6.5. Referencing Errata ........................18
4.8.6.6. Referencing Other Standards Development
Organizations (SDOs) ......................18
4.9. Appendices Section ........................................19
4.10. Acknowledgements Section .................................19
4.11. Contributors Section .....................................19
4.12. "Author's Address" or "Authors' Addresses" Section .......20
5. Security Considerations ........................................20
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................20
Appendix A. Related Procedures ....................................23
A.1. Dispute Resolution .........................................23
A.2. Returning an I-D to the Document Stream ....................23
A.3. Revising This Document and Associated Web Pages ............23
IAB Members at the Time of Approval ...............................24
Acknowledgements ..................................................24
Contributors ......................................................24
Authors' Addresses ................................................24
Appendix A. Related Procedures ....................................23
A.1. Dispute Resolution .........................................23
A.2. Returning an I-D to the Document Stream ....................23
A.3. Revising This Document and Associated Web Pages ............23
IAB Members at the Time of Approval ...............................24
Acknowledgements ..................................................24
Contributors ......................................................24
Authors' Addresses ................................................24
The ultimate goal of the RFC publication process is to produce documents that are readable, clear, consistent, and reasonably uniform. The basic formatting conventions for RFCs were established in the 1970s by the original RFC Editor, Jon Postel. This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series [RFC4844]. It is intended as a stable, infrequently updated reference for authors, editors, and reviewers.
RFC发布过程的最终目标是生成可读、清晰、一致且合理统一的文档。RFC的基本格式约定是由最初的RFC编辑器Jon Postel在20世纪70年代建立的。本文档描述了RFC系列[RFC4844]当前使用的基本和独特的样式约定和编辑策略。它是作为一个稳定的，很少更新的参考作者，编辑和评论员。
The RFC Editor also maintains a web portion of the Style Guide (see Appendix A.3) that describes issues as they are raised and indicates how the RFC Editor intends to address them. As new style issues arise, the RFC Editor will first address them on the web portion of the Style Guide [STYLE-WEB]. These topics may become part of the RFC Style Guide when it is revised.
RFC编辑器还维护样式指南的web部分（见附录a.3），其中描述了提出的问题，并指出RFC编辑器打算如何解决这些问题。当出现新的样式问题时，RFC编辑器将首先在样式指南[style-web]的web部分解决这些问题。修订后，这些主题可能成为RFC样式指南的一部分。
The world of technical publishing has generally accepted rules for grammar, punctuation, capitalization, sentence length and complexity, parallelism, etc. The RFC Editor generally follows these accepted rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a few important exceptions to avoid ambiguity in complex technical prose and to handle mixtures of text and computer languages, or to preserve historical formatting rules. This document presents these exceptions as applied or recommended by the RFC Editor.
技术出版界对语法、标点符号、大写字母、句子长度和复杂性、并行性等有普遍接受的规则。RFC编辑器通常遵循芝加哥风格手册（CMOS）[CMOS]定义的这些公认规则，除了一些重要的例外，以避免复杂的技术散文中的歧义，处理文本和计算机语言的混合，或保留历史格式规则。本文档介绍了RFC编辑器应用或建议的这些例外情况。
All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a well-written and properly constructed Internet-Draft [ID-GUIDE] provides a strong basis for a good RFC. The RFC Editor accepts Internet-Drafts from specified streams for publication [RFC4844] and applies the rules and guidelines for the RFC Series during the editorial process.
所有RFC都以互联网草稿（也称为I-D）开始，一份编写良好且结构合理的互联网草稿[ID-GUIDE]为良好的RFC提供了坚实的基础。RFC编辑器接受来自指定流的Internet草稿以供发布[RFC4844]，并在编辑过程中应用RFC系列的规则和指南。
Authors may find it helpful to understand the RFC Editor's goals during the publication process, namely to:
作者可能会发现，了解RFC编辑在出版过程中的目标很有帮助，即：
- Prepare the document according to RFC style and format.
- 根据RFC样式和格式准备文件。
- Make the document as clear, consistent, and readable as possible.
- 使文档尽可能清晰、一致和可读。
- Correct larger content/clarity issues; flag any unclear passages for author review.
- 纠正较大的内容/清晰度问题；标记任何不清楚的段落以供作者审阅。
- Fix inconsistencies (e.g., terms that appear in various forms, text that appears multiple times, or inconsistent capitalization).
- 修复不一致（例如，以各种形式出现的术语、多次出现的文本或不一致的大写）。
We strive for consistency within:
我们力求在以下方面保持一致：
a. the document,
a. 文件,，
b. a cluster of documents [CLUSTER], and
b. 文档群集[群集]，以及
c. the series of RFCs on the subject matter.
c. 关于主题的一系列RFC。
The editorial process of the RFC Editor is not an additional technical review of the document. Where the RFC Editor may suggest changes in wording for clarity and readability, it is up to the author, working group, or stream-approving body to determine whether the changes have an impact on the technical meaning of the document [RFC4844]. If the original wording is a more accurate representation of the technical content being described in the document, it takes precedence over editorial conventions.
RFC编辑器的编辑过程不是对文件的附加技术审查。如果RFC编辑为了清晰易读而建议修改措辞，则应由作者、工作组或流审批机构确定这些修改是否会影响文件的技术含义[RFC4844]。如果原始措辞更准确地表达了文件中描述的技术内容，则其优先于编辑惯例。
The activity of editing sometimes creates a tension between author and editor. The RFC Editor attempts to minimize this conflict for RFC publication while continually striving to produce a uniformly excellent document series. The RFC Editor refers to this fundamental tension as "editorial balance," and maintaining this balance is a continuing concern for the RFC Editor. There is a prime directive that must rule over grammatical conventions: do not change the intended meaning of the text.
编辑活动有时会造成作者和编辑之间的紧张关系。RFC编辑器试图最小化RFC发布的这种冲突，同时不断努力生成一致优秀的文档系列。RFC编辑将这种基本的紧张关系称为“编辑平衡”，保持这种平衡是RFC编辑持续关注的问题。有一条基本指令必须凌驾于语法惯例之上：不要改变文本的预期含义。
If the RFC Editor cannot edit a document without serious risk of altering the meaning, it may be returned to the stream-approving body for review. See Appendix A.2 for more information.
如果RFC编辑器无法编辑文档而不存在改变其含义的严重风险，则可以将其返回流审批机构进行审查。更多信息请参见附录A.2。
This Style Guide does not use terminology as defined in RFC 2119 [BCP14]. In this document, lowercase use of "must" and "should" indicates changes the RFC Editor will make automatically to conform with this Style Guide versus those that may be questioned if not applied. The lowercase "must" indicates those changes that will be applied automatically and are not at the discretion of the authors. The lowercase "should" indicates the RFC Editor's recommended use, but conformance with the recommendations is not required; the RFC Editor may question whether the guidance may be applied.
本样式指南不使用RFC 2119[BCP14]中定义的术语。在本文档中，小写使用“必须”和“应该”表示RFC编辑器将自动进行更改，以符合本样式指南，而不是那些如果不应用可能会受到质疑的更改。小写的“必须”表示将自动应用且不由作者自行决定的更改。小写的“应该”表示RFC编辑器的建议用途，但不要求符合建议；RFC编辑可能会质疑该指南是否适用。
The RFC publication language is English. Spelling may be either American or British, as long as an individual document is internally consistent. Where both American and British English spelling are used within a document or cluster of documents, the text will be modified to be consistent with American English spelling.
RFC的出版语言为英语。拼写可以是美国或英国，只要单个文档内部一致。如果在文档或文档组中同时使用美式和英式英语拼写，则将修改文本以与美式英语拼写一致。
* No overstriking (or underlining) is allowed.
* 不允许过度拉伸（或划线）。
* When a sentence ended by a period is immediately followed by another sentence, there must be two blank spaces after the period.
* 当以句号结尾的句子紧接着另一个句子时，句号后必须有两个空格。
* A comma is used before the last item of a series, e.g.,
* 在序列的最后一项之前使用逗号，例如。，
"TCP service is reliable, ordered, and full duplex"
TCP服务可靠、有序且全双工
* When quoting literal text, punctuation is placed outside quotation marks, e.g.,
* 引用文字时，标点符号放在引号外，例如。，
Search for the string "Error Found".
搜索字符串“Error Found”。
When quoting general text, such as general text from another RFC, punctuation may be included within the quotation marks, e.g.,
引用一般文本时，例如来自另一RFC的一般文本，标点符号可能包含在引号内，例如。，
RFC 4844 indicates that "RFCs are available free of charge to anyone via the Internet."
RFC 4844表示“任何人都可以通过互联网免费获得RFC。”
Quotation marks are not necessary when text is formatted as a block quotation.
当文本格式为块引号时，不需要引号。
DNS names, whether or not in URIs, that are used as generic examples in RFCs should use the particular examples defined in "Reserved Top Level DNS Names" [BCP32], to avoid accidental conflicts.
在RFC中用作一般示例的DNS名称（无论是否在URI中）应使用“保留顶级DNS名称”[BCP32]中定义的特定示例，以避免意外冲突。
Angle brackets are strongly recommended around URIs [STD66], e.g.,
强烈建议在URI[STD66]周围使用尖括号，例如：。，
<http://example.com/>
<http://example.com/>
* Capitalization must be consistent within the document and ideally should be consistent with related RFCs. Refer to the online table of decisions on consistent usage of terms in RFCs [TERMS].
* 文件中的大写字母必须一致，最好与相关RFC一致。参考RFCs中术语一致使用的在线决策表[术语]。
* Per CMOS guidelines, the major words in RFC titles and section titles should be capitalized (this is sometimes called "title case"). Typically, all words in a title will be capitalized, except for internal articles, prepositions, and conjunctions.
* 根据CMOS指南，RFC标题和章节标题中的主要词语应大写（有时称为“标题格”）。通常，标题中的所有单词都将大写，内部冠词、介词和连词除外。
* Section titles that are in sentence form will follow typical sentence capitalization.
* 句子形式的章节标题将遵循典型的句子大小写。
* Titles of figures may be in sentence form or use title case.
* 图的标题可以是句子形式或用例形式。
* References and citations must match. That is, there must be a reference for each citation used, and vice versa.
* 参考文献和引文必须匹配。也就是说，每个引用都必须有一个引用，反之亦然。
* Citations must be enclosed in square brackets (e.g., "[CITE1]").
* 引文必须用方括号括起来（如“[CITE1]”）。
* A citation/reference tag must not contain spaces.
* 引用/引用标记不得包含空格。
Example: "[RFC2119]" rather than "[RFC 2119]"
示例：“[RFC2119]”而不是“[RFC2119]”
However, the proper textual naming of an RFC contains a space.
但是，RFC的正确文本命名包含空格。
Example: "See RFC 2119 [BCP14] for more information."
示例：“有关更多信息，请参阅RFC 2119[BCP14]
* Cross-references within the body of the memo and to other RFCs must use section numbers rather than page numbers, as pagination may change per format and device.
* 备忘录正文和其他RFC的交叉引用必须使用章节号，而不是页码，因为页码可能因格式和设备而异。
Abbreviations should be expanded in document titles and upon first use in the document. The full expansion of the text should be followed by the abbreviation itself in parentheses. The exception is an abbreviation that is so common that the readership of RFCs can be expected to recognize it immediately; examples include (but are not limited to) TCP, IP, SNMP, and HTTP. The online list of abbreviations [ABBR] provides guidance. Some cases are marginal, and the RFC Editor will make the final judgment, weighing obscurity against complexity.
缩略语应在文件标题和首次在文件中使用时扩展。全文展开后应在括号内加上缩写词。例外情况是一个非常常见的缩写，可以期望RFC的读者立即识别它；示例包括（但不限于）TCP、IP、SNMP和HTTP。缩略语在线列表[ABBR]提供了指导。有些案例是边缘案例，RFC编辑将做出最终判断，权衡模糊性和复杂性。
Note: The online list of abbreviations is not exhaustive or definitive. It is a list of abbreviations appearing in RFCs and sometimes reflects discussions with authors, Working Group Chairs, and/or Area Directors (ADs). Note that some abbreviations have multiple expansions. Additionally, this list includes some terms that look like abbreviations but that are actually fixed names for things and hence cannot and should not be expanded. These are noted as "No Expansion".
注：在线缩略语列表并不详尽或明确。这是RFC中出现的缩写列表，有时反映与作者、工作组主席和/或区域主管（ADs）的讨论。请注意，有些缩写有多个扩展名。此外，该列表包含一些看起来像缩写的术语，但实际上是事物的固定名称，因此不能也不应该扩展。这些被称为“无扩展”。
A published RFC will largely contain the elements in the following list. Some of these sections are required, as noted. Those sections marked with "*" will be supplied by the RFC Editor during the editorial process when necessary. Sections are allowed to contain nothing but subsections. The rules for each of these elements are described in more detail below.
已发布的RFC将主要包含以下列表中的元素。如前所述，其中一些章节是必需的。必要时，RFC编辑器将在编辑过程中提供标有“*”的章节。章节只允许包含小节。下面将更详细地描述每个元素的规则。
First-page header * [Required]
Title [Required]
Abstract [Required]
RFC Editor or Stream Note * [Upon request]
Status of This Memo * [Required]
Copyright Notice * [Required]
Table of Contents * [Required]
Body of the Memo [Required]
1. Introduction [Required]
2. Requirements Language (RFC 2119)
3. ...
MAIN BODY OF THE TEXT
6. ...
7. IANA Considerations [Required in I-D]
8. Internationalization Considerations
9. Security Considerations [Required]
10. References
10.1. Normative References
10.2. Informative References
Appendix A.
Appendix B.
Acknowledgements
Contributors
Author's Address [Required]
First-page header * [Required]
Title [Required]
Abstract [Required]
RFC Editor or Stream Note * [Upon request]
Status of This Memo * [Required]
Copyright Notice * [Required]
Table of Contents * [Required]
Body of the Memo [Required]
1. Introduction [Required]
2. Requirements Language (RFC 2119)
3. ...
MAIN BODY OF THE TEXT
6. ...
7. IANA Considerations [Required in I-D]
8. Internationalization Considerations
9. Security Considerations [Required]
10. References
10.1. Normative References
10.2. Informative References
Appendix A.
Appendix B.
Acknowledgements
Contributors
Author's Address [Required]
Within the body of the memo, the order shown above is strongly recommended. Exceptions may be questioned. Outside the body of the memo, the order above is required. The section numbers above are for illustrative purposes; they are not intended to correspond to required numbering in an RFC.
在备忘录正文中，强烈建议按上述顺序执行。例外情况可能会受到质疑。在备忘录正文之外，需要上面的顺序。以上章节编号仅用于说明目的；它们不符合RFC中要求的编号。
The elements preceding the body of the memo should not be numbered. Typically, the body of the memo will have numbered sections and the appendices will be labeled with letters. Any sections that appear after the appendices should not be numbered or labeled (e.g., see "Contributors" above).
备忘录正文前的元素不应编号。通常，备忘录的正文将有编号部分，附录将用字母标记。附录后面出现的任何章节都不应编号或贴标签（例如，见上文“贡献者”）。
Headers will follow the format described in "RFC Streams, Headers, and Boilerplates" [RFC5741] and its successors. In addition, the following conventions will apply.
标题将遵循“RFC流、标题和样板文件”[RFC5741]及其后续文件中描述的格式。此外，以下公约将适用。
The determination of who should be listed as an author or editor on an RFC is made by the stream.
流决定谁应该被列为RFC上的作者或编辑。
The author's name (initial followed by family name) appears on the first line of the heading. Some variation, such as additional initials or capitalization of family name, is acceptable. Once the author has selected how their name should appear, they should use that display consistently in all of their documents.
标题的第一行显示作者的姓名（首字母后接姓氏）。可以接受一些变化，如附加首字母或姓氏大写。一旦作者选择了他们的名字应该如何显示，他们应该在所有文档中一致地使用该显示。
The total number of authors or editors on the first page is generally limited to five individuals and their affiliations. If there is a request for more than five authors, the stream-approving body needs to consider if one or two editors should have primary responsibility for this document, with the other individuals listed in the Contributors or Acknowledgements section. There must be a direct correlation of authors and editors in the document header and the Authors' Addresses section. These are the individuals that must sign off on the document during the AUTH48 process and respond to inquiries, such as errata.
第一页上的作者或编辑总数通常限于五个人及其所属机构。如果有超过五名作者的请求，流审批机构需要考虑一个或两个编辑是否应该对这份文件有主要责任，而其他人则在贡献者或确认部分中列出。文档标题和作者地址部分中必须有作者和编辑的直接关联。在AUTH48过程中，这些人必须在文档上签字，并回答诸如勘误表之类的询问。
The author's organization is indicated on the line following the author's name.
作者的组织机构显示在作者姓名后的一行。
For multiple authors, each author name appears on its own line, followed by that author's organization. When more than one author is affiliated with the same organization, the organization can be "factored out," appearing only once following the corresponding Author lines. However, such factoring is inappropriate when it would force an unacceptable reordering of author names.
对于多个作者，每个作者的姓名都显示在自己的行中，后跟该作者的组织。当一个以上的作者隶属于同一个组织时，该组织可以被“分解”，只在相应的作者行之后出现一次。然而，当这种因素将迫使作者姓名重新排序时，它是不合适的。
If an author cannot or will not provide an affiliation for any reason, "Independent", "Individual Contributor", "Retired", or some other term that appropriately describes the author's affiliation may be used. Alternatively, a blank line may be included in the document header when no affiliation is provided.
如果作者因任何原因不能或不愿提供从属关系，则可以使用“独立”、“个人贡献者”、“退休”或其他适当描述作者从属关系的术语。或者，当没有提供附属关系时，可以在文档标题中包括一个空行。
The RFC Series has been assigned an International Standard Serial Number of 2070-1721 [ISO3297]. It will be included by the RFC Editor.
RFC系列被分配了一个国际标准序列号2070-1721[ISO3297]。它将由RFC编辑器包含。
When an RFC obsoletes or updates a previously published RFC or RFCs, this information is included in the document header. For example:
当RFC淘汰或更新以前发布的RFC或RFC时，此信息将包含在文档标题中。例如：
"Updates: nnnn" or "Updates: nnnn, ..., nnnn"
“更新：nnnn”或“更新：nnnn，…，nnnn”
"Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"
“淘汰：nnnn”或“淘汰：nnnn，…，nnnn”
If the document updates or obsoletes more than one document, numbers will be listed in ascending order.
如果文档更新或废弃了多个文档，则编号将按升序列出。
The title must be centered below the rest of the heading, preceded by two blank lines and followed by one blank line.
标题必须在标题的其余部分下方居中，前面有两行空行，后面有一行空行。
Choosing a good title for an RFC can be a challenge. A good title should fairly represent the scope and purpose of the document without being either too general or too specific and lengthy.
为RFC选择一个好的标题可能是一个挑战。一个好的标题应该公平地代表文件的范围和目的，而不是过于笼统或过于具体和冗长。
Abbreviations in a title must generally be expanded when first encountered (see Section 3.6 for additional guidance on abbreviations).
标题中的缩略语通常在第一次遇到时必须进行扩展（有关缩略语的附加指南，请参见第3.6节）。
It is often helpful to follow the expansion with the parenthesized abbreviation, as in the following example:
在展开后加上括号中的缩写通常很有帮助，如下例所示：
Encoding Rules for the Common Routing Encapsulation Extension Protocol (CREEP)
通用路由封装扩展协议（CREW）的编码规则
The RFC Editor recommends that documents describing a particular company's private protocol should bear a title of the form "Foo's ... Protocol" (where Foo is a company name), to clearly differentiate it from a protocol of more general applicability.
RFC编辑器建议，描述特定公司专用协议的文件应标有“Foo的…协议”的标题（其中，Foo是公司名称），以明确区分其与更具普遍适用性的协议。
Every RFC must have an Abstract that provides a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document.
每一份RFC都必须有一份摘要，对整个文档的目的和内容进行简明而全面的概述，以使技术知识渊博的读者对文档的功能有一个大致的了解。
Composing a useful Abstract generally requires thought and care. Usually, an Abstract should begin with a phrase like "This memo ..." or "This document ..." A satisfactory Abstract can often be constructed in part from material within the Introduction section, but an effective Abstract may be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is allowed, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract.
撰写一份有用的摘要通常需要深思熟虑。通常，摘要应该以“本备忘录…”或“本文件…”等短语开头。一份令人满意的摘要通常可以部分地从导言部分的材料中构造出来，但一份有效的摘要可能比导言更短，更不详细，范围更广。简单地复制和粘贴引言的前几段是允许的，但这可能会导致摘要既不完整又多余。还要注意，摘要不能代替引言；RFC应该是独立的，就像没有摘要一样。
Similarly, the Abstract should be complete in itself. It will appear in isolation in publication announcements and in the online index of RFCs. Therefore, the Abstract must not contain citations.
同样，摘要本身也应该是完整的。它将单独出现在出版物公告和RFC在线索引中。因此，摘要不得包含引文。
A stream-approving body may approve the inclusion of an editorial note to explain anything unusual about the process that led to the document's publication or to note a correction. In this case, a stream note section will contain such a note.
流审批机构可批准包含编辑注释，以解释导致文件发布的过程中的任何异常情况，或说明更正。在这种情况下，流注释部分将包含这样的注释。
Additionally, an RFC Editor Note section may contain a note inserted by the RFC Editor to highlight special circumstances surrounding an RFC.
此外，RFC编辑器注释部分可能包含RFC编辑器插入的注释，以突出显示RFC周围的特殊情况。
The RFC Editor will supply an appropriate "Status of This Memo" as defined in RFC 5741 [RFC5741] and "Format for RFCs in the IAB Stream" [IAB-FORM].
RFC编辑器将提供RFC 5741[RFC5741]和“IAB流中RFC的格式”[IAB-FORM]中定义的适当“本备忘录的状态”。
The full copyright and license notices are available on the IETF Trust Legal Provisions documents website [IETF-TRUST].
完整的版权和许可声明可在IETF信托法律条款文件网站[IETF-Trust]上获得。
A Table of Contents (TOC) is required in all RFCs. It must be positioned after the Copyright Notice and before the Introduction.
所有RFC中都需要目录（TOC）。它必须放在版权声明之后和介绍之前。
Following the TOC is the body of the memo.
TOC之后是备忘录的主体。
Each RFC must include an Introduction section that (among other things) explains the motivation for the RFC and (if appropriate) describes the applicability of the document, e.g., whether it specifies a protocol, provides a discussion of some problem, is simply of interest to the Internet community, or provides a status report on some activity. The body of the memo and the Abstract must be self-contained and separable. This may result in some duplication of text between the Abstract and the Introduction; this is acceptable.
每个RFC必须包括一个介绍部分，该部分（除其他外）解释了RFC的动机，并（如适用）描述了文件的适用性，例如，它是否指定了协议，是否提供了一些问题的讨论，是否只是互联网社区感兴趣，或是否提供了一些活动的状态报告。备忘录和摘要的正文必须是独立的和可分离的。这可能会导致摘要和导言之间出现一些文本重复；这是可以接受的。
The Introduction section should always be the first section following the TOC (except in the case of MIB module documents). While "Introduction" is recommended, authors may choose alternate titles such as "Overview" or "Background". These alternates are acceptable.
简介部分应始终是TOC之后的第一部分（MIB模块文档除外）。虽然建议使用“简介”，但作者可以选择其他标题，如“概述”或“背景”。这些替代品是可以接受的。
For MIB module documents, common practice has been for "The Internet-Standard Management Framework" [MIB-BOILER] text to appear as Section 1.
对于MIB模块文档，通常的做法是将“Internet标准管理框架”[MIB-BOOLBOY]文本显示为第1节。
Some documents use certain capitalized words ("MUST", "SHOULD", etc.) to specify precise requirement levels for technical features. RFC 2119 [BCP14] defines a default interpretation of these capitalized words in IETF documents. If this interpretation is used, RFC 2119 must be cited (as specified in RFC 2119) and included as a normative reference. Otherwise, the correct interpretation must be specified in the document.
一些文件使用某些大写单词（“必须”、“应该”等）来指定技术特性的精确要求级别。RFC 2119[BCP14]定义了IETF文档中这些大写单词的默认解释。如果使用此解释，则必须引用RFC 2119（如RFC 2119中所规定），并将其作为规范性参考。否则，必须在文件中规定正确的解释。
This section must appear as part of the body of the memo (as defined by this document). It must appear as part of, or subsequent to, the Introduction section.
本节必须作为备忘录正文的一部分出现（如本文件所定义）。它必须作为引言部分的一部分或之后出现。
These words are considered part of the technical content of the document and are intended to provide guidance to implementers about specific technical features, generally governed by considerations of interoperability. RFC 2119 says:
这些词语被视为本文件技术内容的一部分，旨在为实施者提供有关特定技术特性的指导，通常受互操作性考虑的制约。RFC2119说：
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting
本备忘录中定义的命令类型必须谨慎使用。特别是，它们必须仅在互操作或限制可能造成伤害的行为（例如限制）实际需要时使用
retransmisssions) For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability.
例如，当互操作性不需要某个方法时，不能使用重传来试图将该方法强加给实现者。
For guidance on how to register IANA-related values or create new registries to be managed by IANA, see "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
有关如何注册IANA相关值或创建IANA管理的新注册表的指导，请参阅“RFCs中编写IANA注意事项部分的指南”[BCP26]。
The RFC Editor will update text accordingly after the IANA assignments have been made. It is helpful for authors to clearly identify where text should be updated to reflect the newly assigned values. For example, the use of "TBD1", "TBD2", etc., is recommended in the IANA Considerations section and in the body of the memo.
完成IANA分配后，RFC编辑器将相应地更新文本。对于作者来说，清楚地确定文本应该在哪里更新以反映新指定的值是很有帮助的。例如，IANA注意事项部分和备忘录正文中建议使用“TBD1”、“TBD2”等。
If the authors have provided values to be assigned by IANA, the RFC Editor will verify that the values inserted by the authors match those that have actually been registered on the IANA site. When writing a given value, consistent use of decimal or hexadecimal is recommended.
如果作者提供了IANA分配的值，RFC编辑器将验证作者插入的值是否与IANA站点上实际注册的值匹配。写入给定值时，建议一致使用十进制或十六进制。
If any of the IANA-related information is not clear, the RFC Editor will work with IANA to send queries to the authors to ensure that assignments and values are properly inserted.
如果任何与IANA相关的信息不清楚，RFC编辑器将与IANA一起向作者发送查询，以确保正确插入赋值和值。
The RFC Editor will remove an IANA Considerations section that says there are no IANA considerations (although such a section is required in the Internet-Draft preceding the RFC).
RFC编辑器将删除一个IANA注意事项部分，该部分表示没有IANA注意事项（尽管RFC之前的互联网草案中需要这样一个部分）。
All RFCs that deal with internationalization issues should have a section describing those issues; see "IETF Policy on Character Sets and Languages" [BCP18], Section 6, for more information.
所有涉及国际化问题的RFC都应该有一个章节来描述这些问题；有关更多信息，请参阅“IETF字符集和语言政策”[BCP18]，第6节。
All RFCs must contain a section that discusses the security considerations relevant to the specification; see "Guidelines for Writing RFC Text on Security Considerations" [BCP72] for more information.
所有RFC必须包含一节，讨论与规范相关的安全注意事项；有关更多信息，请参阅“关于安全注意事项的RFC文本编写指南”[BCP72]。
Note that additional boilerplate material for RFCs containing MIB and YANG modules also exists. See "Security Guidelines for IETF MIB Modules" [MIB-SEC] and "yang module security considerations" [YANG-SEC] for details.
请注意，还存在包含MIB和YANG模块的RFC的其他样板材料。有关详细信息，请参阅“IETF MIB模块安全指南”[MIB-SEC]和“yang模块安全注意事项”[yang-SEC]。
The reference list is solely for recording reference entries. Introductory text is not allowed.
参考列表仅用于记录参考条目。不允许使用介绍性文字。
The RFC style allows the use of any of a variety of reference styles, as long as they are used consistently within a document. However, where necessary, some reference styles have been described for use within the Series. See the examples in this document.
RFC样式允许使用各种引用样式中的任何一种，只要它们在文档中一致使用。但是，在必要的情况下，已经描述了一些参考样式，以便在本系列中使用。请参阅本文档中的示例。
The RFC Editor ensures that references to other RFCs refer to the most current RFC available on that topic (unless provided with a reason not to do so). When referring to an obsoleted document, it is common practice to also refer to the most recent version.
RFC编辑器确保对其他RFC的引用引用该主题上可用的最新RFC（除非提供了不这样做的理由）。当提及过时的文档时，通常也会提及最新版本。
A reference to an RFC that has been assigned an STD [RFC1311], BCP [RFC1818], or FYI [FYI90] sub-series number must include the sub-series number of the document. Note that the FYI series was ended by RFC 6360. RFCs that were published with an FYI sub-series number and still maintain the FYI number must include the sub-series number in the reference.
已分配STD[RFC1311]、BCP[RFC1818]或FYI[FYI90]子序列号的RFC参考必须包括文档的子序列号。请注意，FYI系列以RFC 6360结束。使用FYI子系列号发布且仍保留FYI号的RFC必须在参考中包含子系列号。
Reference lists must indicate whether each reference is normative or informative, where normative references are essential to implementing or understanding the content of the RFC and informative references provide additional information. More information about normative and informative references may be found in the IESG's statement "Normative and Informative References" [REFS]. When both normative and informative references exist, the references section should be split into two subsections:
参考文献列表必须说明每个参考文献是规范性的还是信息性的，其中规范性参考文献对于实施或理解RFC的内容至关重要，而信息性参考文献提供了额外的信息。有关规范性和信息性参考文献的更多信息，请参见IESG的声明“规范性和信息性参考文献”[参考文献]。当同时存在规范性和信息性参考文件时，参考文件部分应分为两个小节：
s. References
s. 工具书类
s.1. Normative References
s、 一,。规范性引用文件
xxx ... xxx
xxx。。。xxx
s.2. Informative References
s、 二,。资料性引用
xxx ... xxx
xxx。。。xxx
References will generally appear in alphanumeric order by citation tag. Where there are only normative or informative references, no subsection is required; the top-level section should say "Normative References" or "Informative References".
参考文献通常按引文标签以字母数字顺序出现。如果只有规范性或信息性参考，则无需小节；顶层部分应注明“规范性参考文件”或“信息性参考文件”。
Normative references to Internet-Drafts will cause publication of the RFC to be suspended until the referenced draft is also ready for publication; the RFC Editor will then update the entry to refer to the RFC and publish both documents simultaneously.
对互联网草案的规范性引用将导致RFC暂停发布，直到所引用的草案也准备好发布；然后，RFC编辑器将更新条目以引用RFC并同时发布这两个文档。
The use of URIs in references is acceptable, as long as the URI is the most stable (i.e., unlikely to change and expected to be continuously available) and direct reference possible. The URI will be verified as valid during the RFC editorial process.
在引用中使用URI是可以接受的，只要URI是最稳定的（即，不太可能更改，并且预期会持续可用）和可能的直接引用。在RFC编辑过程中将验证URI是否有效。
If a dated URI (one that includes a timestamp for the page) is available for a referenced web page, its use is required.
如果一个带日期的URI（包含页面时间戳的URI）可用于引用的网页，则需要使用它。
Note that URIs may not be the sole information provided for a reference entry.
请注意，URI可能不是为引用条目提供的唯一信息。
The following format is required for referencing RFCs. Note the ordering for multiple authors: the format of the name of the last author listed is different than that of all previous authors in the list.
参考RFC需要以下格式。请注意多个作者的顺序：最后列出的作者的姓名格式不同于列表中以前所有作者的姓名格式。
For one author or editor:
对于一位作者或编辑：
[RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, Date of publication, <http://www.rfc-editor.org/info/rfc#>.
[RFCXXXX]姓氏，首字母，编辑（如适用），“RFC标题”，子系列号（如适用），RFC编号，出版日期<http://www.rfc-editor.org/info/rfc#>.
Example:
例子：
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001, <http://www.rfc-editor.org/info/rfc3080>.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月<http://www.rfc-editor.org/info/rfc3080>.
For two authors or editors:
对于两位作者或编辑：
[RFCXXXX] Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, Date of publication, <http://www.rfc-editor.org/info/rfc#>.
[RFCXXXX]姓氏、首字母、Ed（如适用）和首字母。姓氏，编辑（如适用），“RFC标题”，子系列编号（如适用），RFC编号，出版日期<http://www.rfc-editor.org/info/rfc#>.
Example:
例子：
[RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)", RFC 6323, July 2011, <http://www.rfc-editor.org/info/rfc6323>.
[RFC6323]Renker，G.和G.Fairhurst，“数据报拥塞控制协议（DCCP）的发送方RTT估计选项”，RFC 63232011年7月<http://www.rfc-editor.org/info/rfc6323>.
For three or more authors or editors:
对于三位或三位以上作者或编辑：
[RFCXXXX] Last name, First initial., Ed. (if applicable), Last name, First initial., Ed. (if applicable), and First initial. Last name, Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, Date of publication, <http://www.rfc-editor.org/info/rfc#>.
[RFCXXXX]姓、首字母、Ed（如适用）、姓、首字母、Ed（如适用）和首字母。姓氏，编辑（如适用），“RFC标题”，子系列编号（如适用），RFC编号，出版日期<http://www.rfc-editor.org/info/rfc#>.
Example:
例子：
[RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender Clarification for Persist Condition", RFC 6429, December 2011, <http://www.rfc-editor.org/info/rfc6429>.
[RFC6429]Bashyam，M.，Jethanandani，M.，和A.Ramaiah，“TCP发送方对持续状态的澄清”，RFC 64292011年12月<http://www.rfc-editor.org/info/rfc6429>.
Internet Standards (STDs) and Best Current Practices (BCPs) may consist of a single RFC or multiple RFCs. When an STD or BCP that contains multiple RFCs is referenced, the reference entry should include ALL of the RFCs comprising that sub-series. The authors should refer to specific RFC numbers as part of the text (not as citations) and cite the sub-series number. Inclusion of the URI to the STD or BCP info page (see Section 3.2.3 of [RFC5741]) is recommended. The text should appear as follows:
互联网标准（STD）和最佳现行做法（BCP）可能由一个RFC或多个RFC组成。当引用包含多个RFC的STD或BCP时，引用条目应包括构成该子系列的所有RFC。作者应参考特定的RFC编号作为文本的一部分（而不是引用），并引用子系列编号。建议在STD或BCP信息页面中包含URI（见[RFC5741]第3.2.3节）。案文应如下：
See RFC 1034 [STD13].
见RFC 1034[STD13]。
For an STD or BCP that contains one RFC:
对于包含一个RFC的STD或BCP：
[STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number, RFC number, Date of publication, <http://www.rfc-editor.org/info/std#>.
[STDXXX]姓氏，首字母，编辑（如适用），“RFC标题”，子系列号，RFC编号，出版日期<http://www.rfc-editor.org/info/std#>.
Example:
例子：
[STD72] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011, <http://www.rfc-editor.org/info/std72>.
[STD72]Gellens，R.和J.Klensin，“邮件信息提交”，STD 72，RFC 6409，2011年11月<http://www.rfc-editor.org/info/std72>.
For an STD or BCP that contains two or more RFCs:
对于包含两个或多个RFC的STD或BCP：
[STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number, RFC number, Date of publication.
[STDXXX]姓氏，首字母，编辑（如适用），“RFC标题”，子系列号，RFC编号，出版日期。
Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "RFC Title", Sub-series number, RFC number, Date of publication.
姓氏、首字母、Ed.（如适用）和首字母。姓氏，编辑（如适用），“RFC标题”，子系列号，RFC编号，出版日期。
<http://www.rfc-editor.org/info/std#>
<http://www.rfc-editor.org/info/std#>
Example:
例子：
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
<http://www.rfc-editor.org/info/std13>
<http://www.rfc-editor.org/info/std13>
References to Internet-Drafts may only appear as informative references. Given that several revisions of an I-D may be produced in a short time frame, references must include the posting date (month and year), the full Internet-Draft file name (including the version number), and the phrase "Work in Progress". Authors may reference multiple versions of an I-D. If the referenced I-D was also later published as an RFC, then that RFC must also be listed.
对互联网草案的引用只能作为信息性引用出现。鉴于可能会在短时间内对I-D进行多次修订，参考文件必须包括发布日期（月份和年份）、完整的互联网草案文件名（包括版本号）和短语“正在进行的工作”。作者可以引用ID的多个版本。如果引用的ID后来也作为RFC发布，则该RFC也必须列出。
[SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "I-D Title", Work in Progress, draft-string-NN, Month Year.
[SYMBOL-TAG]姓氏、首字母、Ed（如适用）和首字母。姓氏，Ed.（如适用），“I-D标题”，正在进行的工作，草案字符串NN，月-年。
Example:
例子：
[RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in Progress, draft-flanagan-style-01, June 2013.
[RFC-STYLE]Flanagan，H.和S.Ginoza，“RFC风格指南”，正在进行的工作，草稿-Flanagan-STYLE-012013年6月。
The following format is required when a reference to an erratum report is necessary:
当需要参考勘误表报告时，需要以下格式：
[ErrNumber] RFC Errata, Erratum ID number, RFC number.
[ErrNumber]RFC勘误表、勘误表ID号、RFC号。
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978.
[Err1912]RFC勘误表，勘误表ID 1912，RFC 2978。
The following format is suggested when referencing a document or standard from another SDO in which authors are listed:
当参考其他SDO中列出作者的文件或标准时，建议采用以下格式：
[SYMBOLIC-TAG] Last name, First initial. and First initial. Last name, "Document Title", Document reference number, Date of publication, <URI if available>.
[SYMBOL-TAG]姓氏，首字母缩写。和第一个首字母。姓氏，“文件标题”，文件参考号，出版日期，<URI（如有）。
[W3C.REC-xml11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-xml11]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，Yergeau，F.，和J.Cowan，“可扩展标记语言（XML）1.1（第二版）”，W3C建议REC-xml11-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml11-20060816>.
Note that the order of authors in the list is the same as the order shown on the actual document and that the common, abbreviated form of the SDO is used.
请注意，列表中作者的顺序与实际文档中显示的顺序相同，并且使用了SDO的通用缩写形式。
Alternatively, when no list of authors is available, the following format is recommended:
或者，如果没有可用的作者列表，建议使用以下格式：
[SYMBOLIC-TAG] Organization, "Document Title", Document reference number, Date of publication, <URI if available>.
[SYMBOL-TAG]组织，“文件标题”，文件参考号，出版日期，<URI（如果可用）。
Example:
例子：
[IEEE802.1Q] IEEE, "Local and Metropolitan Area Networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011, <http://standards.ieee.org/findstds/standard/ 802.1Q-2011.html>.
[IEEE802.1Q]IEEE，“局域网和城域网——媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q-2011，2011年8月<http://standards.ieee.org/findstds/standard/ 802.1Q-2011.html>。
The RFC Editor recommends placing references before the Appendices. Appendices should be labeled as "Appendix A. Title", "A.1. Title", "Appendix B. Title", etc.
RFC编辑器建议将引用放在附录之前。附录应标记为“附录A.标题”、“A.1.标题”、“附录B.标题”等。
This optional section may be used instead of, or in addition to, a Contributors section. It is often used by authors to publicly thank those who have provided feedback regarding a document and to note any documents from which text was borrowed.
此可选部分可用于替代或补充贡献者部分。作者经常使用它来公开感谢那些就某个文档提供反馈的人，并注意到从中借用文本的任何文档。
This optional section acknowledges those who have made significant contributions to the document.
本可选部分感谢对本文件做出重大贡献的人员。
In a similar fashion to the Author's Address section, the RFC Editor does not make the determination as to who should be listed as a contributor to an RFC. The determination of who should be listed as a contributor is made by the stream.
以与作者地址部分类似的方式，RFC编辑不会决定谁应该被列为RFC的贡献者。由流决定谁应该被列为贡献者。
The Contributors section may include brief statements about the nature of particular contributions ("Sam contributed Section 3"), and it may also include affiliations of listed contributors. At the discretion of the author(s), contact addresses may also be included in the Contributors section, for those contributors whose knowledge makes them useful future contacts for information about the RFC. The format of any contact information should be similar to the format of information in the Author's Address section.
贡献者部分可能包括关于特定贡献性质的简短陈述（“Sam贡献部分3”），也可能包括列出的贡献者的从属关系。根据作者的判断，联系人地址也可以包含在“投稿人”部分中，供那些了解RFC信息的投稿人使用。任何联系信息的格式应与作者地址部分中的信息格式相似。
This required section gives contact information for the author(s) listed in the first-page header.
此必填部分提供了第一页页眉中列出的作者的联系信息。
Contact information must include a long-lived email address and optionally may include a postal address and/or telephone number. If the postal address is included, it should include the country name, using the English short name listed by the ISO 3166 Maintenance Agency [ISO_OBP]. The purpose of this section is to (1) unambiguously define author identity (e.g., the John Smith who works for FooBar Systems) and (2) provide contact information for future readers who have questions or comments.
联系信息必须包括长期有效的电子邮件地址，也可以包括邮政地址和/或电话号码。如果包含邮政地址，则应使用ISO 3166维护机构[ISO_OBP]列出的英文短名称包含国家名称。本节的目的是（1）明确定义作者身份（例如，为FooBar系统工作的John Smith）和（2）为有疑问或评论的未来读者提供联系信息。
The practice of munged email addresses (i.e., altering an email address to make it less readable to bots and web crawlers to avoid spam) is not appropriate in an archival document series. Author contact information is provided so that readers can easily contact the author with questions and/or comments. Address munging is not allowed in RFCs.
屏蔽电子邮件地址的做法（即更改电子邮件地址，使其不易被机器人和网络爬虫读取，以避免垃圾邮件）不适用于存档文档系列。提供作者联系信息，以便读者可以轻松地通过问题和/或评论联系作者。在RFCs中不允许使用地址模糊不清。
This document has no security considerations.
此文档没有安全考虑。
[STYLE-WEB] RFC Editor, "Web Portion of the Style Guide", <http://www.rfc-editor.org/rfc-style-guide/part2.html>.
[STYLE-WEB]RFC编辑器，“样式指南的WEB部分”<http://www.rfc-editor.org/rfc-style-guide/part2.html>.
[ABBR] RFC Editor Abbreviations List, <http://www.rfc-editor.org/rfc-style-guide/ abbrev.expansion.txt>.
[ABBR]RFC编辑器缩写列表<http://www.rfc-editor.org/rfc-style-guide/ abbrev.expansion.txt>。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/bcp14>.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/bcp14>.
[BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998, <http://www.rfc-editor.org/info/bcp18>.
[BCP18]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月<http://www.rfc-editor.org/info/bcp18>.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/bcp26>.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/bcp26>.
[BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999, <http://www.rfc-editor.org/info/bcp32>.
[BCP32]Eastlake 3rd，D.和A.Panitz，“保留顶级域名”，BCP 32，RFC 26061999年6月<http://www.rfc-editor.org/info/bcp32>.
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/bcp72>.
[BCP72]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月<http://www.rfc-editor.org/info/bcp72>.
[CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue", <http://www.rfc-editor.org/cluster_def.html>.
[CLUSTER]RFC编辑器，“RFC编辑器队列中的群集”<http://www.rfc-editor.org/cluster_def.html>.
[CMOS] Chicago Manual of Style, 16th ed. Chicago: University of Chicago Press, 2010.
《芝加哥风格手册》，第十六版，芝加哥：芝加哥大学出版社，2010。
[FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to the FYI Notes", FYI Notes, RFC 1150, March 1990.
[FYI90]Malkin，G.和J.Reynolds，“FYI上的FYI：FYI注释介绍”，FYI注释，RFC 1150，1990年3月。
Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, August 2011.
Housley，R.，“FYI RFC子系列的结论”，RFC 63602011年8月。
[IAB-FORM] IAB, "Format for RFCs in the IAB Stream", <http://www.rfc-editor.org/rfc-style-guide/ iab-format.txt>.
[IAB-FORM]IAB，“IAB流中RFC的格式”<http://www.rfc-editor.org/rfc-style-guide/ iab format.txt>。
[ID-GUIDE] IETF, "Guidelines to Authors of Internet Drafts", <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[ID-GUIDE]IETF，“互联网草稿作者指南”<http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[IETF-TRUST] IETF Trust, "Trust Legal Provisions (TLP)", <http://trustee.ietf.org/license-info/>.
[IETF-TRUST]IETF信托，“信托法律条款（TLP）”<http://trustee.ietf.org/license-info/>.
[ISO_OBP] ISO, "Online Browsing Platform (OBP)", <https://www.iso.org/obp/ui/>.
[ISO_OBP]ISO，“在线浏览平台（OBP）”<https://www.iso.org/obp/ui/>.
[ISO3297] Technical Committee ISO/TC 46, Information and documentation, Subcommittee SC 9, Identification and description, "Information and documentation - International standard serial number (ISSN)", September 2007.
[ISO3297]技术委员会ISO/TC 46，信息和文件，小组委员会SC 9，标识和说明，“信息和文件-国际标准序列号（ISSN）”，2007年9月。
[MIB-BOILER] IETF OPS Area, "Boilerplate for IETF MIB Documents", <http://www.ops.ietf.org/mib-boilerplate.html>.
[MIB-BOILTER]IETF OPS区域，“IETF MIB文件样板文件”<http://www.ops.ietf.org/mib-boilerplate.html>.
[MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules", <http://trac.tools.ietf.org/area/ops/trac/wiki/ mib-security>.
[MIB-SEC]IETF OPS领域，“IETF MIB模块安全指南”<http://trac.tools.ietf.org/area/ops/trac/wiki/ mib安全>。
[REFS] IESG, "IESG Statement: Normative and Informative References", <http://www.ietf.org/iesg/statement/ normative-informative.html>.
[参考文献]IESG，“IESG声明：规范性和信息性参考文件”<http://www.ietf.org/iesg/statement/ 规范信息.html>。
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992, <http://www.rfc-editor.org/info/rfc1311>.
[RFC1311]Postel，J.，“标准说明介绍”，RFC13111992年3月<http://www.rfc-editor.org/info/rfc1311>.
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", RFC 1818, August 1995, <http://www.rfc-editor.org/info/rfc1818>.
[RFC1818]Postel，J.，Li，T.，和Y.Rekhter，“当前最佳实践”，RFC 18181995年8月<http://www.rfc-editor.org/info/rfc1818>.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997, <http://www.rfc-editor.org/ info/rfc2223>.
[RFC2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月<http://www.rfc-editor.org/ 信息/rfc2223>。
[RFC2223bis] Reynolds, J., Ed. and B. Braden, Ed. "Instructions to Request for Comments (RFC) Authors", Work in Progress, draft-rfc-editor-rfc2223bis-08, August 2004.
[RFC2223bis]Reynolds，J.，Ed.和B.Braden，Ed.“征求意见（RFC）作者的说明”，正在进行的工作，草稿-RFC-editor-RFC2223bis-08，2004年8月。
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC4844]Daigle，L.，Ed.，和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 48442007年7月<http://www.rfc-editor.org/info/rfc4844>.
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009, <http://www.rfc-editor.org/info/rfc5741>.
[RFC5741]Daigle，L.，Ed.，Kolkman，O.，Ed.，和IAB，“RFC流，标题和样板”，RFC 57412009年12月<http://www.rfc-editor.org/info/rfc5741>.
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, June 2012, <http://www.rfc-editor.org/info/rfc6635>.
[RFC6635]Kolkman，O.，Ed.，Halpern，J.，Ed.，和IAB，“RFC编辑器模型（版本2）”，RFC 66352012年6月<http://www.rfc-editor.org/info/rfc6635>.
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/ info/std66>.
[STD66]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/ 信息/std66>。
[TERMS] RFC Editor, "Terms List", <http://www.rfc-editor.org/styleguide.html>.
[TERMS]RFC编辑器，“术语列表”<http://www.rfc-editor.org/styleguide.html>.
[YANG-SEC] IETF OPS Area, "yang module security considerations", <http://trac.tools.ietf.org/area/ops/trac/wiki/ yang-security-guidelines>.
[YANG-SEC]IETF作战区，“YANG模块安全注意事项”<http://trac.tools.ietf.org/area/ops/trac/wiki/ 杨安全指南>。
The following procedures are related to the application and updating of the RFC Style Guide.
以下步骤与RFC样式指南的应用和更新相关。
There are competing rationales for some of the rules described in this Guide, and the RFC Editor has selected the ones that work best for the Series. However, at times, an author may have a disagreement with the RFC Production Center (RPC) over the application of Style Guide conventions. In such cases, the authors should discuss their concerns with the RPC. If no agreement can be reached between the RPC and the authors, the RFC Series Editor will, with input from the appropriate stream-approving body, make a final determination. If further resolution is required, the dispute resolution process as described in the RFC Editor Model [RFC6635] will be followed.
对于本指南中描述的一些规则，存在着相互竞争的理论基础，RFC编辑器选择了最适合本系列的规则。但是，有时，作者可能与RFC生产中心（RPC）在样式指南约定的应用上存在分歧。在这种情况下，作者应与RPC讨论他们的担忧。如果RPC和作者之间无法达成协议，RFC系列编辑器将根据相应流审批机构的输入做出最终决定。如果需要进一步解决，将遵循RFC编辑器模型[RFC6635]中所述的争议解决流程。
For a given document, if the RFC Editor determines that it cannot be edited without serious risk of altering the meaning of the technical content or if the RFC Editor does not have the resources to provide the level of editing it needs, it may be sent back to the stream-approving body with a request to improve the clarity, consistency, and/or readability of the document. This is not to be considered a dispute with the author.
对于给定的文档，如果RFC编辑器确定其无法编辑而不会改变技术内容的含义，或者如果RFC编辑器没有资源来提供其所需的编辑级别，则可以将其发送回流审批机构，并请求提高清晰度、一致性，和/或文件的可读性。这不应被视为与提交人的争议。
The RFC Series is continually evolving as a document series. This document focuses on the fundamental and stable requirements that must be met by an RFC. From time to time, the RFC Editor may offer less formal recommendations that authors may apply at their discretion; these recommendations may be found on the RFC Editor website "Guidelines for RFC Style" [STYLE-WEB].
RFC系列作为文档系列不断发展。本文件侧重于RFC必须满足的基本和稳定要求。RFC编辑可能会不时提供不太正式的建议，作者可自行决定采用这些建议；这些建议可在RFC编辑器网站“RFC风格指南”[Style-WEB]上找到。
When a new recommendation is made regarding the overall structure and formatting of RFCs, it will be published on that page and accepted for a period of time before the RFC Editor determines whether it should become part of the fundamental requirements in the RFC Style Guide or remain as a less formal recommendation. That period of time will vary, in part depending on the frequency with which authors encounter and apply the guidance.
当就RFC的整体结构和格式提出新建议时，将在该页面上发布并接受一段时间，然后RFC编辑确定该建议是应成为RFC样式指南中基本要求的一部分，还是作为不太正式的建议保留。这段时间会有所不同，部分取决于作者遇到和应用指南的频率。
IAB Members at the Time of Approval
批准时的IAB成员
Jari Arkko (IETF Chair) Mary Barnes Marc Blanchet Joel Halpern Ted Hardie Joe Hildebrand Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Brian Trammell
Jari Arkko（IETF主席）Mary Barnes Marc Blanchet Joel Halpern Ted Hardie Joe Hildebrand Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Brian Trammell
Acknowledgements
致谢
This document refers heavily to RFC 2223 [RFC2223] and [RFC2223bis]; as such, we are grateful to the authors of those documents for putting their time and effort into the RFC Series.
本文件主要参考了RFC 2223[RFC2223]和[RFC2223bis]；因此，我们感谢这些文件的作者将他们的时间和精力投入到RFC系列中。
Robert T. Braden USC Information Sciences Institute
罗伯特·T·布拉登南加州大学信息科学研究所
Joyce Reynolds
乔伊斯·雷诺兹
Jon Postel
普斯特尔
Contributors
贡献者
Alice Russo RFC Production Center
Alice Russo RFC生产中心
Authors' Addresses
作者地址
Heather Flanagan RFC Series Editor
希瑟·弗拉纳根RFC系列编辑器
EMail: rse@rfc-editor.org
EMail: rse@rfc-editor.org
Sandy Ginoza RFC Production Center
桑迪·吉诺扎RFC生产中心
EMail: rfc-editor@rfc-editor.org
EMail: rfc-editor@rfc-editor.org