最近读 RFC 文档的过程中，发现在过去十几年里，每年都有尝试翻译 RFC 的小伙伴，但是大家没有统一的规范，译文的组织也非常松散，翻译的水平参差不齐。

为了能够使大家的工作成果得到维护，并提供对译文不断迭代的可能，我最近建了一个 Github 仓库和一个网站；另外，我还翻译了几篇比较基础的 RFC，对于 RFC 文档的准确理解和翻译都很重要。希望通过做一点微小的贡献，达到“前人栽树，后人乘凉”的目的。

网站的视觉效果应该会好些，使用了等宽字体，并且有中英对照；但毕竟是第一次进行网站开发，且使用的是最低配的服务器，响应时间、页面布局会有很多问题。

https://github.com/dianbo-rfc/dianbo-rfc

https://dianbo-rfc.cn/progress

下面是译文：

Internet Architecture Board (IAB)                            H. Flanagan
Request for Comments: 7322                                     S. Ginoza
Obsoletes: 2223                                               RFC Editor
Category: Informational                                   September 2014
ISSN: 2070-1721RFC 样式指南摘要此文档描述了: 目前在 RFC 系列文档中所使用的, 基本的、独有的样式约定和编辑方针。此文档包含了 RFC Editor 的基本要求, 且提供了关于 RFC 的样式及结构的指南。其它的一些指南可以在一网站上获取, 这些指南是实验性质的,并准备将其纳入到未来的 'RFC 样式指南' 中。此文档废除了 RFC2223,"Instructions to RFC Authors"。Status of This MemoThis document is not an Internet Standards Track specification; it ispublished for informational purposes.This document is a product of the Internet Architecture Board (IAB)and represents information that the IAB has deemed valuable toprovide for permanent record.  It represents the consensus of theInternet Architecture Board (IAB).  Documents approved forpublication by the IAB are not a candidate for any level of InternetStandard; see Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7322.Copyright NoticeCopyright (c) 2014 IETF Trust and the persons identified as thedocument authors.  All rights reserved.This document is subject to BCP 78 and the IETF Trust's LegalProvisions Relating to IETF Documents(http://trustee.ietf.org/license-info) in effect on the date ofpublication of this document.  Please review these documentscarefully, as they describe your rights and restrictions with respectto this document.Flanagan & Ginoza             Informational                     [Page 1]RFC 7322                     RFC Style Guide              September 2014目录1. 导言 ............................................................32. RFC Editor 的理念 ...............................................43. RFC 样式约定 ....................................................53.1. 语言 .......................................................53.2. 标点符号 ...................................................53.3. DNS 名称和 URI .............................................63.4. 大写形式 ...................................................63.5. 引用 .......................................................63.6. 缩写规则 ...................................................74. RFC 的结构 ......................................................84.1. 首页页头 ...................................................94.1.1. 作者/编辑者 .........................................94.1.2. 组织 ................................................94.1.3. "ISSN: 2070-1721" ..................................104.1.4. 更新和废除 .........................................104.2. 全文标题 ..................................................104.3. "摘要" 章节 ...............................................114.4. RFC Editor or Stream Notes Section ........................114.5. "此备忘录的状态" 章节 .....................................114.6. 版权, 许可证, 及知识产权样板章节 ..........................114.7. "目录" 章节 ...............................................114.8. 备忘录正文  ...............................................124.8.1. "导言" 章节 ........................................124.8.2. "文档要求的用语" 章节 ..............................124.8.3. "IANA 注意事项" 章节 ...............................134.8.4. "国际化注意事项" 章节 ..............................134.8.5. "安全注意事项" 章节 ................................134.8.6. "参考文献" 章节 ....................................144.8.6.1. RFC 中的 URI ..............................154.8.6.2. 引用 RFC ..................................154.8.6.3. 引用 STD 和 BCP ...........................164.8.6.4. 引用互联网草案 ............................174.8.6.5. 引用勘误 ..................................184.8.6.6. 引用其它标准开发组织 ......................184.9. "附录" 章节 ...............................................194.10. "致谢" 章节 ..............................................194.11. "贡献者" 章节 ............................................194.12. "作者地址" 章节 ..........................................205. 安全注意事项 ...................................................206. 参考文献 .......................................................206.1. 前提类参考文献 ............................................206.2. 信息类参考文献 ............................................20Flanagan & Ginoza             Informational                     [Page 2]RFC 7322                     RFC Style Guide              September 2014附录 A. Related Procedures ........................................23A.1. Dispute Resolution .........................................23A.2. Returning an I-D to the Document Stream ....................23A.3. Revising This Document and Associated Web Pages ............23IAB Members at the Time of Approval ...............................24致谢 ..............................................................24贡献者 ............................................................24作者地址 ..........................................................241.  导言RFC 发布流程的最终目标是: 产生可读的、清晰的、一致的、且合理统一的文档。20 世纪 70 年代, 最早的 RFC 编辑者, Jon Postel, 建立了基本的 RFC格式约定。此文档描述了: 目前在 RFC 系列文档 [RFC4844] 中所使用的, 基本的、独有的样式约定和编辑方针。其目的是作为一个稳定的、不常更新的指南, 以供作者、编辑者、和评审员参考。RFC Editor 还维护了样式指南 (Style Guide) 的网页部分 (见附录第 A.3节), 其中描述了出现的问题, 并指出了 RFC Editor 打算如何处理这些问题。当出现新的样式相关的问题时, RFC Editor 首先会在样式指南的网页部分中[STYLE-WEB] 处理这些问题。当这些主题得到修订后, 可能会成为 RFC 样式指南的一部分。技术出版界对语法、标点符号、大写字母、及句子的长度、复杂度、并行度等都有公认的规则。RFC Editor 大体上遵循了在 "芝加哥样式手册" (ChicagoManual of Style, CMOS) [CMOS] 中所定义的这些公认的规则, 除了一些重要的例外情况: 为了避免复杂的技术文章中的歧义性、为了处理普通文本与计算机语言的混用、或为了保留历史遗留的格式规则。此文档展示了那些被 RFCEditor 所应用或推荐的例外情况。所有的 RFC 都是以互联网草案 (Internet-Drafts, 又称 I-Ds) 开始的, 而一个编写良好、结构合理的互联网草案 [ID-GUIDE] 为一个优秀的 RFC 提供了坚实的基础。RFC Editor 接受来自一些特定的发布流 (stream) 的互联网草案,来进行发布 [RFC4844], 并在编辑流程中应用 RFC 系列文档 (RFC Series) 的规则和指南。Flanagan & Ginoza             Informational                     [Page 3]RFC 7322                     RFC Style Guide              September 20142.  RFC Editor 的理念理解 RFC Editor 在发布流程中的目标, 可能会对作者有所帮助, 即:- 根据 RFC 的样式和格式准备文档。- 使文档尽可能清晰、一致、且可读。- 更正较严重的文本内容/表述清晰相关的问题; 标记任何不清楚的段落以供作者审阅。- 解决不一致问题 (例如, 同一术语采用了多种不同的表述形式、同一文本出现多次、或大小写不一致)。我们力求在以下范围内保持一致性:a. 文档自身的范围内,b. 一 "簇" 文档的范围内 [CLUSTER],c. 与同一主题相关的一系列 RFC 文档的范围内。RFC Editor 的编辑流程并不是对文档进行额外的技术性审阅。当 RFC Editor为了清晰性与可读性而建议更改措辞时, 这一修改是否会对技术含义产生影响,是由作者、工作组、或发布流审批机构来决定。如果原始的措辞可以更加准确地描述文档中的技术内容, 则其优先于文档的编辑约定。对文档的编辑活动有时会造成作者和编辑者之间的紧张关系。RFC Editor 试图将文档发布过程中的这一冲突最小化, 同时力求产生大量优秀的系列文档。RFCEditor 将这种基本的紧张关系称为 "编辑平衡" ("editorial balance"), 而保持这种平衡是 RFC Editor 所持续关注的问题。这里有一个凌驾于语法约定的基本要求, 即: 不要改变文本的本来含义。如果 RFC Editor 不冒着改变文本含义的高风险, 就无法编辑文档, 则该文档应当退还给发布流审批机构进行再审。更多信息见附录第 A.2 节。Flanagan & Ginoza             Informational                     [Page 4]RFC 7322                     RFC Style Guide              September 20143.  RFC 样式约定此样式指南 (Style Guide) 没有使用 RFC 2119 [BCP14] 中定义的术语。此文档中, 对 "must" 和 "should" 的小写形式的使用 (译者, 译文中未加方括号【】进行强调的 "必须" 和 "应该" 等词), 表示 RFC Editor 将会自动地对文档进行修改, 以遵循此样式指南; 与之相对, 如果没有应用此修改, 则将受到质疑。小写形式的 "must" (译者, 译文中未加方括号【】的 "必须"), 表示将会自动地应用这些修改, 而非由作者决定。小写形式的 "should" (译者, 译文中未加方括号【】的 "应该"), 表示是 RFC Editor 所建议的用法, 但遵循该建议并不是必须的; RFC Editor 可能会询问是否要应用该条指南。3.1.  语言RFC 的发布语言为英语。单词拼写可能是美式的、或英式的, 只要其在单个文件内部保持一致即可。如果在一个文件内部、或一 "簇" 文件内部同时使用了英式拼写和美式拼写, 则文本将会被修改为与美式拼写相一致。3.2.  标点符号*  不允许对文本加粗 (或添加下划线)。*  如果一个句子以句点结束, 且其后紧跟另一个句子, 则句点后必须有两个空格。*  在一序列中的最后一项前添加逗号, 例如:"TCP service is reliable, ordered, and full duplex"*  当引述纯单词的文本时, 标点符号放在引号外部, 例如:Search for the string "Error Found".当引述一般的文本时, 例如来自另一个 RFC 的一般文本, 标点符号可以被包含到引号内部, 例如:RFC 4844 indicates that "RFCs are available free of charge toanyone via the Internet."当文本采用块引述的形式时, 不需要使用引号。Flanagan & Ginoza             Informational                     [Page 5]RFC 7322                     RFC Style Guide              September 20143.3.  DNS 名称和 URI在 RFC 中用作一般示例的 DNS 名称 (无论其是否在 URI 中), 都应当使用在"Reserved Top Level DNS Names" [BCP32] 所定义的特定示例, 以避免意外的冲突。强烈建议在 URI 周围使用尖括号 [STD66], 例如:<http://example.com/>3.4.  大写形式*  大写形式必须在文本内保持一致, 且在理想情况下, 应与相关的 RFC 保持一致。请参考在线表格 [TERMS], 了解关于 RFC 中术语的一致性使用的决定。*  根据 CMOS (Chicago Manual of Style) 中的准则, 在 RFC 的主标题和章节标题中的主要单词应当被大写 (这有时被称为 "title case")。通常, 标题中的所有单词都应被大写, 但其中的冠词、介词、和连词除外。(译者,这里的大写是指首字母大写)。*  句子形式的章节标题, 将遵循典型的句首单词首字母大写的形式。*  图片的标题可以采用句子或标题的大写形式。3.5.  引用*  参考文献和引用必须要匹配。因此, 对于每一个引用都必须有相应的参考文献, 反之亦然。*  引用必须被包裹在方括号中 (例如 "[CITE1]")。*  在引用/参考文献的标签中禁止包含空格。示例: "[RFC2119]" rather than "[RFC 2119]"但是, 正确的 RFC 文本命名中包含有一个空格。示例: "See RFC 2119 [BCP14] for more information."*  位于备忘录 (译者, 实际上就是指文档) 正文中的、 指向其它 RFC 的交叉引用 (Cross-references), 应当使用章节号, 而非页号; 因为页号可能会因格式或设备的不同而改变。Flanagan & Ginoza             Informational                     [Page 6]RFC 7322                     RFC Style Guide              September 20143.6.  缩写规则当缩写出现在标题中、或在文档中第一次使用时, 缩写应当被展开。文本的缩写形式应该用括号包裹, 并跟在其完整展开形式的后面。存在例外, 即一缩写非常常见, 以至于 RFC 读者可以立即认出该缩写; 例如 (但不限于) TCP, IPSNMP, 和 HTTP。在线的缩写列表 [ABBR] 提供了相关指南。存在一些少见的样例, RFC Editor 会在权衡了模糊性和复杂性后, 作出最终的判断。注意: 在线的缩写列表并非是事无巨细的、完全明确的。它仅仅是出现在RFC 中的缩写的列表, 有时反映了与作者、工作组主席 (Working GroupChairs)、和/或区域主管 (AD, Area Director) 的讨论结果。注意, 有一些缩写具有多个展开形式。此外, 该列表还包含一些看起来像缩写的术语,但实际上它们是事物的固定名称, 因此不能够也不应当被展开。这些术语被记作 "No Expansion"。Flanagan & Ginoza             Informational                     [Page 7]RFC 7322                     RFC Style Guide              September 20144.  RFC 的结构一个已发布的 RFC 将主要包含以下列表中的元素。如上所述, 其中的一些章节是必需的。在文档的编辑流程中, 如有必要, RFC Editor 将会提供那些用 "*"标出的章节。在各个章节中, 只能包含子章节。关于这些文档元素的规则, 将在下面详细介绍。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        IANA 注意事项   [Required in I-D]8.  Internationalization Considerations9.  Security Considerations    安全注意事项    [Required]10.  References                参考文献10.1.  Normative References    前提类参考文献10.2.  Informative References  信息类参考文献Appendix A.                    附录 A.Appendix B.                    附录 B.Acknowledgements              致谢Contributors                  贡献者Author's Address              作者地址           [Required]强烈建议: 在备忘录的正文 (body of the memo) 中, 使用上面所示的顺序。对于那些未采用该顺序的例外情况, 可能会受到问询。在备忘录的正文外, 上面所示的顺序是必须的。上面所示的章节编号仅用于说明目的; 它们并不与实际的 RFC 中所需的编号相对应。不应对备忘录正文 (body of the memo) 前面的元素进行编号。通常, 在备忘录正文中的, 章节使用数字进行编号, 附录使用字母进行标记。出现在附录后面的章节, 不应当被编号或标记 (例, 上面所示的 "Contributors")。Flanagan & Ginoza             Informational                     [Page 8]RFC 7322                     RFC Style Guide              September 20144.1.  首页页头 (First-Page Header)页头 (Headers) 将遵循在 "RFC Streams, Headers, and Boilerplates"[RFC5741] 及其后续文档中所描述的格式。此外, 将会应用下述的约定。4.1.1.  作者/编辑者由发布流来确定: 在 RFC 中, 哪些人应当被列为作者或编辑者。作者的姓名应出现在页头的第一行。允许在姓名中添加额外的姓氏的缩写或大写。一旦作者选择了姓名的显示方式, 他们应当在其所有的文档中使用一致的显示方式。在首页中, 作者或编辑者的总数通常限制在五个, 包括个人及其所属机构。如果要求列出五名以上的作者, 则发布流审批机构需要考虑: 这些人中是否有一到两人对此文档负有主要责任, 并将其他人列在贡献者 (Contributors) 或致谢 (Acknowledgements) 章节中。出现在文档页头中、及作者地址 (Authors'Addresses) 章节中的作者和编辑者, 必须有着直接关联。这些人要负责: 在AUTH48 流程中, 在文档上签字; 以及回应各类询问, 例如勘误。4.1.2.  组织作者所属的组织应在作者姓名的下一行指出。对于多名作者的情形, 每名作者的姓名出现在单独一行中, 并后跟作者所属的组织。当有多名作者从属于同一组织时, 可以将组织名称 "提取" 出来, 并跟随在这些作者姓名行的后面, 仅显示一次。但是, 当这种 "提取" 会改变作者姓名的顺序, 且这种顺序的改变是不可接受的时候, "提取" 行为是不合适的。如果一名作者因为某些原因, 不能或不愿提供所属机构时, 可以使用 "独立的"("Independent")、"个人贡献者" ("Individual Contributor")、"已退休"("Retired")、或其他合适的术语, 来描述作者从属情况。或者, 当没有提供任何从属信息时, 可以在文档页头中包含一空行。Flanagan & Ginoza             Informational                     [Page 9]RFC 7322                     RFC Style Guide              September 20144.1.3.  "ISSN: 2070-1721"RFC 系列文档已经被赋予了一个国际标准期刊编号 (International StandardSerial Number), 为 2070-1721 [ISO3297]。该编号将会被包含在 RFC Editor中。4.1.4.  更新 (Updates) 和废除 (Obsoletes)当一个 RFC 要废除或更新之前的一个或多个已发布的 RFC 时, 应当在文档的页头中包含如下信息。例如:"Updates: nnnn" or "Updates: nnnn, ..., nnnn""Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"如果当前文档更新或废除了多个文档, 则文档编号将按照升序列出。4.2.  全文标题 (Full Title)标题必须位于页头的下方, 居中对齐, 并前后各添加一空行。为 RFC 选择一个好的标题是一个挑战。一个好的标题应当能够中肯地表明文档涉及的领域及其目的, 且不会过于笼统、或过于具体和冗长。标题中的缩写, 若是第一次遇到, 一般必须要被展开 (关于缩写的额外指南见第 3.6 节)。通常, 很有帮助的做法是: 在缩写的展开形式的后面, 跟随被括号包裹的该缩写。如下面的例子所示:Encoding Rules for theCommon Routing Encapsulation Extension Protocol (CREEP)RFC Editor 建议: 一个用于描述某个特定的公司私有协议的文档, 应当采用形如 "Foo's ... Protocol" (其中 Foo 是公司名称) 的标题, 以使其明确区别于其它更加普遍适用的协议。Flanagan & Ginoza             Informational                    [Page 10]RFC 7322                     RFC Style Guide              September 20144.3. "摘要" (Abstract) 章节每个 RFC 必须具有一个摘要, 来对整个文档的目的和内容进行简明和全面的概述, 以便技术相关的读者能够对该文档的功能有个大致的概览。撰写一篇有用的摘要一般需要深思熟虑。通常, 摘要应当以类似 "This memo..." 或 "This document ..." 这样的短语作为开头。一篇令人满意摘要经常是根据导言 (Introduction) 章节的部分材料来构建的, 但是一篇有效的摘要应当比导言更加简短、粗略、且可能范围更广。允许简单地复制粘贴导言的前几个段落, 但是这可能使摘要变得既不完整又多余。注意: 摘要不能代替导言;RFC 应当是字包含的, 就像没有摘要一样。同样, 摘要本身应当是完整的。摘要将会单独出现在 RFC 的发布公告及在线索引中。因此, 摘要中禁止包含引用。4.4.  RFC Editor or Stream Notes SectionA stream-approving body may approve the inclusion of an editorialnote to explain anything unusual about the process that led to thedocument's publication or to note a correction.  In this case, astream note section will contain such a note.Additionally, an RFC Editor Note section may contain a note insertedby the RFC Editor to highlight special circumstances surroundingan RFC.4.5. "此备忘录的状态" 章节RFC Editor 将会提供合适的 "此备忘录的状态" ("Status of This Memo") 信息, 其定义在 RFC 5741 [RFC5741] 与 "IAB 发布流中的 RFC 格式" ("Formatfor RFCs in the IAB Stream") [IAB-FORM] 中。4.6.  版权, 许可证, 及知识产权样板章节完整的版权和许可证的声明, 可以从 IETF Trust Legal Provisions 文档页面[IETF-TRUST] 获取。4.7. "目录" 章节所有的 RFC 都需要有目录 (TOC, Table of Contents)。目录必须位于版权声明之后、导言之前。Flanagan & Ginoza             Informational                    [Page 11]RFC 7322                     RFC Style Guide              September 20144.8.  备忘录正文跟随在目录后的是备忘录的正文。每个 RFC 必须包含一个导言 (Introduction) 章节, 以解释该 RFC 的动机,以及 (如果合适) 描述文档的适用性, 例如: 它是否能说明了某个协议、提供了关于某些问题的讨论、仅是对互联网社区的兴趣、又或者提供了某些活动的状态报告。备忘录的正文和摘要 (Abstract) 都必须是独立的、可分离的。这可能会导致在摘要和导言间出现一些重复文本; 这是可以接受的。4.8.1. "导言" (Introduction) 章节导言章节应当总是目录后的第一个章节 (MIB 模块文档除外)。虽然建议使用"导言" ("Introduction") 一词, 但是作者可能选择其它标题, 例如 "概述"("Overview") 或 "背景" ("Background")。这些替代方式是可接受的。对于 MIB 模块文档, 通常的做法见 "The Internet-Standard ManagementFramework" [MIB-BOILER], 即文本作为第 1 节出现。4.8.2. "文档要求的用语" 章节一些文档使用了特定的大写单词 ("MUST"、"SHOULD" 等, 译文中为【必须】、【应当】等), 来指出对某一技术特性的明确的要求级别。RFC 2119 [BCP14]定义了: 当这些大写单词出现在 IETF 文档中时的默认解释。如果使用此解释,则必须引用 RFC 2119 (如 RFC 2119 中指定的那样), 并将其作为前提类参考文献。否则, 必须在文档中说明用词的正确释义。这一章节必须作为备忘录正文的一部分出现 (如此文档中定义的那样)。它必须作为导言章节的一部分、或作为导言的后续章节。这些单词被认为是文档的技术内容的一部分, 这些单词的使用通常以技术特性的互操作性作为考量, 旨在为实现者提供关于一些具体的技术特性的指导。在RFC 2119 中, 有说:在此备忘录中定义的这些祈使词, 必须被小心地、保守地使用。特别的, 这些祈使词的使用【必须】是出于互操作性的实际需要、或是为了限制可能导致潜在危害的行为 (例如, 限制重传)。例如, 它们不得被用于: 将特定方法强加给实现者, 而该方法是互操作性所不需要的。Flanagan & Ginoza             Informational                    [Page 12]RFC 7322                     RFC Style Guide              September 20144.8.3. "IANA 注意事项" (IANA Considerations) 章节关于如何注册与 IANA 相关的值, 或如何创建新的由 IANA 管理的注册表, 见"Guidelines for Writing an IANA Considerations Section in RFCs"[BCP26]。在完成 IANA 分配后, RFC Editor 将会相应地对文本进行更新。建议作者清楚地标出应当更新哪些文本, 以反映新分配的值。例如, 推荐在 "IANA 注意事项" 章节、及备忘录正文中, 使用 "TBD1", "TBD2" 等。如果作者已经提供了由 IANA 分配的值, 则 RFC Editor 将会验证: 作者插入到文档中的值是否与在 IANA 站点上实际注册的值匹配。当书写给定的值时,建议使用一致的十进制或十六进制形式。如果有任何与 IANA 相关的信息不明确, 则 RFC Editor 会同 IANA 一起向作者发出问询, 以确保该分配流程及分配的值被正确插入到文档中。如果一个 "IANA 注意事项" 章节表示其没有关于 IANA 的注意事项, 则 RFCEditor 将会删除该章节 (尽管, 在 RFC 发布前的互联网草案 Internet-Draft阶段确实需要这一章节)。4.8.4. "国际化注意事项" (Internationalization Considerations) 章节所有处理国际化问题的 RFC 都应当包含这一章节来描述这些问题; 更多信息见"IETF Policy on Character Sets and Languages" [BCP18] 中的第 6 节。4.8.5. "安全注意事项" (Security Considerations) 章节所有的 RFC 都应当包含这一章节, 来讨论与该规范相关的安全注意事项。更多信息见 "Guidelines for Writing RFC Text on Security Considerations"[BCP72]。注意, 存在其它的样文, 用于那些包含有 MIB 和 YANG 模块的 RFC。详细信息, 见 "Security Guidelines for IETF MIB Modules" [MIB-SEC] 和 "yangmodule security considerations" [YANG-SEC]。Flanagan & Ginoza             Informational                    [Page 13]RFC 7322                     RFC Style Guide              September 20144.8.6.  "参考文献" (References) 章节参考文献列表仅仅用于记录参考项。不允许加入介绍性文本。RFC 样式允许使用任何种类的引用样式, 只要它们的使用在同一文档中保持一致。但是, 在此 RFC 系列文档的范围内, 有一些已被描述过的引用样式的使用是必要的。具体示例参见此文档。RFC Editor 会确保: 引用其它 RFC 的参考文献, 会引用相关主题的最新版的RFC (除非提供了不这样做的理由)。当引用一个被废除的文档时, 通常也会引用其最新版本的文档。如果一 RFC 被分配了一个 STD [RFC1311]、BCP [RFC1818]、或 FYI [FYI90]子系列编号 (sub-series number), 则参考文献在引用它时, 必须包含该文档的子系列编号。注意, FYI 系列的文档已由 RFC 6360 终止。那些含有 FYI 子系列编号发布的、或依旧在维护 FYI 编号的 RFC, 必须在其参考文献中包含该子系列编号。参考文献列表必须要指明: 每一个参考文献是前提类的 (normative) 还是信息类的 (informative), 其中前提类的参考文献对实现或理解 RFC 的内容至关重要, 而信息类的参考文献则提供了附加信息。关于前提类和信息类参考文献的更多信息, 可以在 IESG 的声明 "Normative and Informative References"[REFS] 中找到。当同时存在前提类和信息类的参考文献时, 参考文献章节应当被划分为两个子章节:s.  References                             s. 参考文献s.1.  Normative References                 s.1. 前提类参考文献xxx                                       xxx...                                       ...xxx                                       xxxs.2.  Informative References               s.2. 信息类参考文献xxx                                       xxx...                                       ...xxx                                       xxxFlanagan & Ginoza             Informational                    [Page 14]RFC 7322                     RFC Style Guide              September 2014参考文献通常按照引用标签的字母数字的顺序显示。当只有前提类或信息类其中一种参考文献时, 不需要划分子章节; 其顶级章节标题为 "前提类参考文献"("Normative References") 或 "信息类参考文献" ("InformativeReferences")。如果前提类参考文献引用了互联网草案, 则将会造成该 RFC 的发布被暂停, 直到被引用的草案也准备好发布为止; 然后, RFC Editor 将会更新相应条目, 以引用要发布的 RFC, 并同时发布两个文档。4.8.6.1.  RFC 中的 URI允许在参考文献中使用 URI, 只要该 URI 是非常稳定的 (例, 不太可能更改,且预期持续可用), 且可以直接引用。在 RFC 编辑流程中, 将会验证 URI 的有效性。如果对某网页的引用, 有一可用的、且含有日期的 URI (包含有该页面的时间戳), 则应当使用这种 URI。注意, URI 不应是为引用条目所提供的唯一信息。4.8.6.2.  引用 RFC要引用 RFC, 需要使用下面给出的格式。注意, 当对多名作者排序时: 列表中,列出的最后一名作者的姓名格式, 不同于所有在他前面列出的其他作者。对于一名作者或编辑者:[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#>.示例:[RFC3080] Rose, M., "The Blocks Extensible ExchangeProtocol Core", RFC 3080, March 2001,<http://www.rfc-editor.org/info/rfc3080>.Flanagan & Ginoza             Informational                    [Page 15]RFC 7322                     RFC Style Guide              September 2014对于两名作者或编辑者:[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#>.示例:[RFC6323] Renker, G. and G. Fairhurst, "Sender RTTEstimate Option for the Datagram CongestionControl Protocol (DCCP)", RFC 6323, July 2011,<http://www.rfc-editor.org/info/rfc6323>.对于三名或更多的作者或编辑者:[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#>.示例:[RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah,"TCP Sender Clarification for PersistCondition", RFC 6429, December 2011,<http://www.rfc-editor.org/info/rfc6429>.4.8.6.3.  引用 STD 和 BCP互联网标准 (Internet Standards, STDs) 和当前最佳实践 (Best CurrentPractices, BCPs) 可能由一个或多个 RFC 组成。当引用包含多个 RFC 的 STD或 BCP 时, 该引用条目应当包括: 组成该子系列 (STD 或 BCP) 的所有 RFC。作者应当在文本中指出具体的 RFC 编号 (非引用形式), 并引用相应的子系列编号。推荐在参考文献章节的引用中包含指向相应 STD 或 BCP 信息页的 URI(见 [RFC5741] 中的第 3.2.3 节)。文本中的引用应如下所示。See RFC 1034 [STD13].Flanagan & Ginoza             Informational                    [Page 16]RFC 7322                     RFC Style Guide              September 2014对于包含有一个 RFC 的 STD 或 BCP:[STDXXX]  Last name, First initial., Ed. (if applicable),"RFC Title", Sub-series number, RFC number, Date ofpublication, <http://www.rfc-editor.org/info/std#>.示例:[STD72]   Gellens, R. and J. Klensin, "Message Submissionfor Mail", STD 72, RFC 6409, November 2011,<http://www.rfc-editor.org/info/std72>.对于包含有两个或更多 RFC 的 STD 或 BCP:[STDXXX]  Last name, First initial., Ed. (if applicable),"RFC Title", Sub-series number, RFC number, Date ofpublication.Last name, First initial., Ed. (if applicable)and First initial. Last name, Ed. (if applicable),"RFC Title", Sub-series number, RFC number, Date ofpublication.<http://www.rfc-editor.org/info/std#>示例:[STD13]    Mockapetris, P., "Domain names - concepts andfacilities", STD 13, RFC 1034, November 1987.Mockapetris, P., "Domain names - implementation andspecification", STD 13, RFC 1035, November 1987.<http://www.rfc-editor.org/info/std13>4.8.6.4.  引用互联网草案 (Internet-Drafts)对互联网草案 (Internet-Draft) 的引用只能作为信息类参考文献出现。鉴于可能会在短时间内对一个 I-D 进行多次修订, 对其的引用必须包括: 发布日期(月和年)、完整的互联网草案文件名 (包括版本号)、及短语 "Work inProgress"。作者可以引用一个 I-D 的多个版本。如果被引用的 I-D 后来作为RFC 被发布, 则该 RFC 也必须被列出。Flanagan & Ginoza             Informational                    [Page 17]RFC 7322                     RFC Style Guide              September 2014[SYMBOLIC-TAG]  Last name, First initial., Ed. (if applicable)and First initial. Last name, Ed. (ifapplicable), "I-D Title", Work in Progress,draft-string-NN, Month Year.示例:[RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide",Work in Progress, draft-flanagan-style-01,June 2013.4.8.6.5.  引用勘误 (Errata)当需要引用一个勘误报告时, 要求使用下面的格式:[ErrNumber]  RFC Errata, Erratum ID number, RFC number.[Err1912]  RFC Errata, Erratum ID 1912, RFC 2978.4.8.6.6.  引用其它标准开发组织当引用来自其它标准开发组织 (Standards Development Organization, SDO)的文档或标准时, 在参考文献的作者列表处, 应当使用下面的格式:[SYMBOLIC-TAG]Last name, First initial. and First initial. Last name,"Document Title", Document reference number, Date ofpublication, <URI if available>.[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 RecommendationREC-xml11-20060816, August 2006,<http://www.w3.org/TR/2006/REC-xml11-20060816>.注意, 列表中的作者的顺序, 应与真实文档中显示的顺序相同, 并使用与 SDO相同的缩写形式。Flanagan & Ginoza             Informational                    [Page 18]RFC 7322                     RFC Style Guide              September 2014或者, 当没有作者列表时, 推荐使用下面的格式:[SYMBOLIC-TAG]  Organization, "Document Title", Documentreference number, Date of publication,<URI if available>.示例:[IEEE802.1Q]  IEEE, "Local and Metropolitan AreaNetworks -- Media Access Control (MAC)Bridges and Virtual Bridged Local AreaNetworks", IEEE Std 802.1Q-2011, August 2011,<http://standards.ieee.org/findstds/standard/802.1Q-2011.html>.4.9. "附录" (Appendices) 章节RFC Editor 建议将 "参考文献" 章节放在 "附录" 章节之前。"附录" 章节应当被标记为 "Appendix A.  Title"、"A.1.  Title"、"Appendix B.  Title"等形式。4.10. "致谢" (Acknowledgements) 章节此可选章节可以用来代替、或补充 "贡献者" (Contributors) 章节。作者经常使用它来: 公开感谢那些对文档提供反馈的人员、及注明在文本中所借鉴过的任何文档。4.11. "贡献者" (Contributors) 章节此可选章节用于感谢那些对文档作出重要贡献的人员。与 "作者地址" (Author's Address) 章节类似, RFC Editor 不会决定谁应当被列为 RFC 的贡献者。谁应当被列为贡献者, 是由发布流决定的。"贡献者" 章节可以包含关于特定的贡献内容的简短陈述 ("Sam contributedSection 3")、及可以包含所列出的贡献者的所属机构。根据作者的判断, "贡献者" 章节中也可以包含贡献者的通讯地址; 因为在将来获取 RFC 相关的信息时, 他们的学识可能会很有用。任何通讯信息的格式应当与 "作者地址" 章节的信息格式类似。Flanagan & Ginoza             Informational                    [Page 19]RFC 7322                     RFC Style Guide              September 20144.12. "作者地址" ("Author's Address" 或 "Authors' Addresses") 章节此必须章节给出了在首页页头中列出的作者的通讯信息。通讯信息中包括一个必须的长期有效的电子邮件地址, 及可选的邮政地址和/或电话号码。如果包括了一个邮政地址, 地址中应当包含国家名称, 该名称采用由 ISO 3166 Maintenance Agency [ISO_OBP] 所列出的英文缩写。此章节的目的是: (1) 明确定义作者身份 (例如, the John Smith who works for FooBarSystems); (2) 为将来有疑问或意见的读者提供通讯信息。伪装邮件地址的做法 (即, 更改电子邮件地址以降低机器人和网络爬虫程序的可读性, 从而避免垃圾邮件) 在归档的文档系列中是不合适的。提供作者的通讯信息, 为的是读者能够方便地联系到作者, 并提出疑问和/或意见。在 RFC中不允许伪装邮件地址。5.  安全注意事项此文档没有关于安全的注意事项。6.  参考文献6.1.  前提类参考文献[STYLE-WEB]RFC Editor, "Web Portion of the Style Guide",<http://www.rfc-editor.org/rfc-style-guide/part2.html>.6.2.  信息类参考文献[ABBR]     RFC Editor Abbreviations List,<http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt>.[BCP14]    Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997,<http://www.rfc-editor.org/info/bcp14>.[BCP18]    Alvestrand, H., "IETF Policy on Character Sets andLanguages", BCP 18, RFC 2277, January 1998,<http://www.rfc-editor.org/info/bcp18>.Flanagan & Ginoza             Informational                    [Page 20]RFC 7322                     RFC Style Guide              September 2014[BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 5226,May 2008, <http://www.rfc-editor.org/info/bcp26>.[BCP32]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNSNames", BCP 32, RFC 2606, June 1999,<http://www.rfc-editor.org/info/bcp32>.[BCP72]    Rescorla, E. and B. Korver, "Guidelines for Writing RFCText on Security Considerations", BCP 72, RFC 3552,July 2003, <http://www.rfc-editor.org/info/bcp72>.[CLUSTER]  RFC Editor, "Clusters in the RFC Editor Queue",<http://www.rfc-editor.org/cluster_def.html>.[CMOS]     Chicago Manual of Style, 16th ed. Chicago: University ofChicago Press, 2010.[FYI90]    Malkin, G. and J. Reynolds, "FYI on FYI: Introduction tothe FYI Notes", FYI Notes, RFC 1150, March 1990.Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,August 2011.[IAB-FORM] IAB, "Format for RFCs in the IAB Stream",<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>.[IETF-TRUST]IETF Trust, "Trust Legal Provisions (TLP)",<http://trustee.ietf.org/license-info/>.[ISO_OBP]  ISO, "Online Browsing Platform (OBP)",<https://www.iso.org/obp/ui/>.[ISO3297]  Technical Committee ISO/TC 46, Information anddocumentation, Subcommittee SC 9, Identification anddescription, "Information and documentation -International standard serial number (ISSN)",September 2007.[MIB-BOILER]IETF OPS Area, "Boilerplate for IETF MIB Documents",<http://www.ops.ietf.org/mib-boilerplate.html>.Flanagan & Ginoza             Informational                    [Page 21]RFC 7322                     RFC Style Guide              September 2014[MIB-SEC]  IETF OPS Area, "Security Guidelines for IETF MIB Modules",<http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security>.[REFS]     IESG, "IESG Statement: Normative and InformativeReferences", <http://www.ietf.org/iesg/statement/normative-informative.html>.[RFC1311]  Postel, J., "Introduction to the STD Notes", RFC 1311,March 1992, <http://www.rfc-editor.org/info/rfc1311>.[RFC1818]  Postel, J., Li, T., and Y. Rekhter, "Best CurrentPractices", RFC 1818, August 1995,<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>.[RFC2223bis]Reynolds, J., Ed. and B. Braden, Ed. "Instructions toRequest for Comments (RFC) Authors", Work in Progress,draft-rfc-editor-rfc2223bis-08, August 2004.[RFC4844]  Daigle, L., Ed., and Internet Architecture Board, "The RFCSeries and RFC Editor", RFC 4844, July 2007,<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>.[RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC EditorModel (Version 2)", RFC 6635, June 2012,<http://www.rfc-editor.org/info/rfc6635>.[STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, "UniformResource Identifier (URI): Generic Syntax", STD 66,RFC 3986, January 2005, <http://www.rfc-editor.org/info/std66>.[TERMS]    RFC Editor, "Terms List",<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>.Flanagan & Ginoza             Informational                    [Page 22]RFC 7322                     RFC Style Guide              September 2014附录 A.  Related ProceduresThe following procedures are related to the application and updatingof the RFC Style Guide.A.1.  Dispute ResolutionThere are competing rationales for some of the rules described inthis Guide, and the RFC Editor has selected the ones that work bestfor the Series.  However, at times, an author may have a disagreementwith the RFC Production Center (RPC) over the application of StyleGuide conventions.  In such cases, the authors should discuss theirconcerns with the RPC.  If no agreement can be reached between theRPC and the authors, the RFC Series Editor will, with input from theappropriate stream-approving body, make a final determination.  Iffurther resolution is required, the dispute resolution process asdescribed in the RFC Editor Model [RFC6635] will be followed.A.2.  Returning an I-D to the Document StreamFor a given document, if the RFC Editor determines that it cannot beedited without serious risk of altering the meaning of the technicalcontent or if the RFC Editor does not have the resources to providethe 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 adispute with the author.A.3.  Revising This Document and Associated Web PagesThe RFC Series is continually evolving as a document series.  Thisdocument focuses on the fundamental and stable requirements that mustbe met by an RFC.  From time to time, the RFC Editor may offer lessformal recommendations that authors may apply at their discretion;these recommendations may be found on the RFC Editor website"Guidelines for RFC Style" [STYLE-WEB].When a new recommendation is made regarding the overall structure andformatting of RFCs, it will be published on that page and acceptedfor a period of time before the RFC Editor determines whether itshould become part of the fundamental requirements in the RFC StyleGuide or remain as a less formal recommendation.  That period of timewill vary, in part depending on the frequency with which authorsencounter and apply the guidance.Flanagan & Ginoza             Informational                    [Page 23]RFC 7322                     RFC Style Guide              September 2014IAB Members at the Time of ApprovalJari Arkko (IETF Chair)Mary BarnesMarc BlanchetJoel HalpernTed HardieJoe HildebrandRuss HousleyEliot LearXing LiErik NordmarkAndrew SullivanDave ThalerBrian Trammell致谢This document refers heavily to RFC 2223 [RFC2223] and[RFC2223bis]; as such, we are grateful to the authors of thosedocuments for putting their time and effort into the RFC Series.Robert T. BradenUSC Information Sciences InstituteJoyce ReynoldsJon Postel贡献者Alice RussoRFC Production Center作者地址Heather FlanaganRFC Series EditorEMail: rse@rfc-editor.orgSandy GinozaRFC Production CenterEMail: rfc-editor@rfc-editor.orgFlanagan & Ginoza             Informational                    [Page 24]