最近读 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-1721
RFC 样式指南
摘要
此文档描述了: 目前在 RFC 系列文档中所使用的, 基本的、独有的样式约定和
编辑方针。此文档包含了 RFC Editor 的基本要求, 且提供了关于 RFC 的样式
及结构的指南。其它的一些指南可以在一网站上获取, 这些指南是实验性质的,
并准备将其纳入到未来的 'RFC 样式指南' 中。此文档废除了 RFC2223,
"Instructions to RFC Authors"。
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.
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.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Flanagan & Ginoza Informational [Page 1]
RFC 7322 RFC Style Guide September 2014
目录
1. 导言 ............................................................3
2. RFC Editor 的理念 ...............................................4
3. RFC 样式约定 ....................................................5
3.1. 语言 .......................................................5
3.2. 标点符号 ...................................................5
3.3. DNS 名称和 URI .............................................6
3.4. 大写形式 ...................................................6
3.5. 引用 .......................................................6
3.6. 缩写规则 ...................................................7
4. RFC 的结构 ......................................................8
4.1. 首页页头 ...................................................9
4.1.1. 作者/编辑者 .........................................9
4.1.2. 组织 ................................................9
4.1.3. "ISSN: 2070-1721" ..................................10
4.1.4. 更新和废除 .........................................10
4.2. 全文标题 ..................................................10
4.3. "摘要" 章节 ...............................................11
4.4. RFC Editor or Stream Notes Section ........................11
4.5. "此备忘录的状态" 章节 .....................................11
4.6. 版权, 许可证, 及知识产权样板章节 ..........................11
4.7. "目录" 章节 ...............................................11
4.8. 备忘录正文 ...............................................12
4.8.1. "导言" 章节 ........................................12
4.8.2. "文档要求的用语" 章节 ..............................12
4.8.3. "IANA 注意事项" 章节 ...............................13
4.8.4. "国际化注意事项" 章节 ..............................13
4.8.5. "安全注意事项" 章节 ................................13
4.8.6. "参考文献" 章节 ....................................14
4.8.6.1. RFC 中的 URI ..............................15
4.8.6.2. 引用 RFC ..................................15
4.8.6.3. 引用 STD 和 BCP ...........................16
4.8.6.4. 引用互联网草案 ............................17
4.8.6.5. 引用勘误 ..................................18
4.8.6.6. 引用其它标准开发组织 ......................18
4.9. "附录" 章节 ...............................................19
4.10. "致谢" 章节 ..............................................19
4.11. "贡献者" 章节 ............................................19
4.12. "作者地址" 章节 ..........................................20
5. 安全注意事项 ...................................................20
6. 参考文献 .......................................................20
6.1. 前提类参考文献 ............................................20
6.2. 信息类参考文献 ............................................20
Flanagan & Ginoza Informational [Page 2]
RFC 7322 RFC Style Guide September 2014
附录 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
致谢 ..............................................................24
贡献者 ............................................................24
作者地址 ..........................................................24
1. 导言
RFC 发布流程的最终目标是: 产生可读的、清晰的、一致的、且合理统一的文
档。20 世纪 70 年代, 最早的 RFC 编辑者, Jon Postel, 建立了基本的 RFC
格式约定。此文档描述了: 目前在 RFC 系列文档 [RFC4844] 中所使用的, 基
本的、独有的样式约定和编辑方针。其目的是作为一个稳定的、不常更新的指
南, 以供作者、编辑者、和评审员参考。
RFC Editor 还维护了样式指南 (Style Guide) 的网页部分 (见附录第 A.3
节), 其中描述了出现的问题, 并指出了 RFC Editor 打算如何处理这些问题。
当出现新的样式相关的问题时, RFC Editor 首先会在样式指南的网页部分中
[STYLE-WEB] 处理这些问题。当这些主题得到修订后, 可能会成为 RFC 样式指
南的一部分。
技术出版界对语法、标点符号、大写字母、及句子的长度、复杂度、并行度等
都有公认的规则。RFC Editor 大体上遵循了在 "芝加哥样式手册" (Chicago
Manual of Style, CMOS) [CMOS] 中所定义的这些公认的规则, 除了一些重要
的例外情况: 为了避免复杂的技术文章中的歧义性、为了处理普通文本与计算
机语言的混用、或为了保留历史遗留的格式规则。此文档展示了那些被 RFC
Editor 所应用或推荐的例外情况。
所有的 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 2014
2. RFC Editor 的理念
理解 RFC Editor 在发布流程中的目标, 可能会对作者有所帮助, 即:
- 根据 RFC 的样式和格式准备文档。
- 使文档尽可能清晰、一致、且可读。
- 更正较严重的文本内容/表述清晰相关的问题; 标记任何不清楚的段落以
供作者审阅。
- 解决不一致问题 (例如, 同一术语采用了多种不同的表述形式、同一文本
出现多次、或大小写不一致)。
我们力求在以下范围内保持一致性:
a. 文档自身的范围内,
b. 一 "簇" 文档的范围内 [CLUSTER],
c. 与同一主题相关的一系列 RFC 文档的范围内。
RFC Editor 的编辑流程并不是对文档进行额外的技术性审阅。当 RFC Editor
为了清晰性与可读性而建议更改措辞时, 这一修改是否会对技术含义产生影响,
是由作者、工作组、或发布流审批机构来决定。如果原始的措辞可以更加准确
地描述文档中的技术内容, 则其优先于文档的编辑约定。
对文档的编辑活动有时会造成作者和编辑者之间的紧张关系。RFC Editor 试图
将文档发布过程中的这一冲突最小化, 同时力求产生大量优秀的系列文档。RFC
Editor 将这种基本的紧张关系称为 "编辑平衡" ("editorial balance"), 而
保持这种平衡是 RFC Editor 所持续关注的问题。这里有一个凌驾于语法约定
的基本要求, 即: 不要改变文本的本来含义。
如果 RFC Editor 不冒着改变文本含义的高风险, 就无法编辑文档, 则该文档
应当退还给发布流审批机构进行再审。更多信息见附录第 A.2 节。
Flanagan & Ginoza Informational [Page 4]
RFC 7322 RFC Style Guide September 2014
3. 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 to
anyone via the Internet."
当文本采用块引述的形式时, 不需要使用引号。
Flanagan & Ginoza Informational [Page 5]
RFC 7322 RFC Style Guide September 2014
3.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 2014
3.6. 缩写规则
当缩写出现在标题中、或在文档中第一次使用时, 缩写应当被展开。文本的缩
写形式应该用括号包裹, 并跟在其完整展开形式的后面。存在例外, 即一缩写
非常常见, 以至于 RFC 读者可以立即认出该缩写; 例如 (但不限于) TCP, IP
SNMP, 和 HTTP。在线的缩写列表 [ABBR] 提供了相关指南。存在一些少见的样
例, RFC Editor 会在权衡了模糊性和复杂性后, 作出最终的判断。
注意: 在线的缩写列表并非是事无巨细的、完全明确的。它仅仅是出现在
RFC 中的缩写的列表, 有时反映了与作者、工作组主席 (Working Group
Chairs)、和/或区域主管 (AD, Area Director) 的讨论结果。注意, 有一
些缩写具有多个展开形式。此外, 该列表还包含一些看起来像缩写的术语,
但实际上它们是事物的固定名称, 因此不能够也不应当被展开。这些术语被
记作 "No Expansion"。
Flanagan & Ginoza Informational [Page 7]
RFC 7322 RFC Style Guide September 2014
4. 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 Considerations
9. 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 2014
4.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 2014
4.1.3. "ISSN: 2070-1721"
RFC 系列文档已经被赋予了一个国际标准期刊编号 (International Standard
Serial 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 the
Common Routing Encapsulation Extension Protocol (CREEP)
RFC Editor 建议: 一个用于描述某个特定的公司私有协议的文档, 应当采用形
如 "Foo's ... Protocol" (其中 Foo 是公司名称) 的标题, 以使其明确区别
于其它更加普遍适用的协议。
Flanagan & Ginoza Informational [Page 10]
RFC 7322 RFC Style Guide September 2014
4.3. "摘要" (Abstract) 章节
每个 RFC 必须具有一个摘要, 来对整个文档的目的和内容进行简明和全面的概
述, 以便技术相关的读者能够对该文档的功能有个大致的概览。
撰写一篇有用的摘要一般需要深思熟虑。通常, 摘要应当以类似 "This memo
..." 或 "This document ..." 这样的短语作为开头。一篇令人满意摘要经常
是根据导言 (Introduction) 章节的部分材料来构建的, 但是一篇有效的摘要
应当比导言更加简短、粗略、且可能范围更广。允许简单地复制粘贴导言的前
几个段落, 但是这可能使摘要变得既不完整又多余。注意: 摘要不能代替导言;
RFC 应当是字包含的, 就像没有摘要一样。
同样, 摘要本身应当是完整的。摘要将会单独出现在 RFC 的发布公告及在线索
引中。因此, 摘要中禁止包含引用。
4.4. RFC Editor or Stream Notes Section
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.
4.5. "此备忘录的状态" 章节
RFC Editor 将会提供合适的 "此备忘录的状态" ("Status of This Memo") 信
息, 其定义在 RFC 5741 [RFC5741] 与 "IAB 发布流中的 RFC 格式" ("Format
for 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 2014
4.8. 备忘录正文
跟随在目录后的是备忘录的正文。
每个 RFC 必须包含一个导言 (Introduction) 章节, 以解释该 RFC 的动机,
以及 (如果合适) 描述文档的适用性, 例如: 它是否能说明了某个协议、提供
了关于某些问题的讨论、仅是对互联网社区的兴趣、又或者提供了某些活动的
状态报告。备忘录的正文和摘要 (Abstract) 都必须是独立的、可分离的。这
可能会导致在摘要和导言间出现一些重复文本; 这是可以接受的。
4.8.1. "导言" (Introduction) 章节
导言章节应当总是目录后的第一个章节 (MIB 模块文档除外)。虽然建议使用
"导言" ("Introduction") 一词, 但是作者可能选择其它标题, 例如 "概述"
("Overview") 或 "背景" ("Background")。这些替代方式是可接受的。
对于 MIB 模块文档, 通常的做法见 "The Internet-Standard Management
Framework" [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 2014
4.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 的注意事项, 则 RFC
Editor 将会删除该章节 (尽管, 在 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] 和 "yang
module security considerations" [YANG-SEC]。
Flanagan & Ginoza Informational [Page 13]
RFC 7322 RFC Style Guide September 2014
4.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 xxx
s.2. Informative References s.2. 信息类参考文献
xxx xxx
... ...
xxx xxx
Flanagan & Ginoza Informational [Page 14]
RFC 7322 RFC Style Guide September 2014
参考文献通常按照引用标签的字母数字的顺序显示。当只有前提类或信息类其
中一种参考文献时, 不需要划分子章节; 其顶级章节标题为 "前提类参考文献"
("Normative References") 或 "信息类参考文献" ("Informative
References")。
如果前提类参考文献引用了互联网草案, 则将会造成该 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 Exchange
Protocol 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 RTT
Estimate Option for the Datagram Congestion
Control 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 Persist
Condition", RFC 6429, December 2011,
<http://www.rfc-editor.org/info/rfc6429>.
4.8.6.3. 引用 STD 和 BCP
互联网标准 (Internet Standards, STDs) 和当前最佳实践 (Best Current
Practices, 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 of
publication, <http://www.rfc-editor.org/info/std#>.
示例:
[STD72] Gellens, R. and J. Klensin, "Message Submission
for 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 of
publication.
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.
<http://www.rfc-editor.org/info/std#>
示例:
[STD13] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
<http://www.rfc-editor.org/info/std13>
4.8.6.4. 引用互联网草案 (Internet-Drafts)
对互联网草案 (Internet-Draft) 的引用只能作为信息类参考文献出现。鉴于
可能会在短时间内对一个 I-D 进行多次修订, 对其的引用必须包括: 发布日期
(月和年)、完整的互联网草案文件名 (包括版本号)、及短语 "Work in
Progress"。作者可以引用一个 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. (if
applicable), "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 of
publication, <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 Recommendation
REC-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", Document
reference number, Date of publication,
<URI if available>.
示例:
[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>.
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 contributed
Section 3")、及可以包含所列出的贡献者的所属机构。根据作者的判断, "贡
献者" 章节中也可以包含贡献者的通讯地址; 因为在将来获取 RFC 相关的信息
时, 他们的学识可能会很有用。任何通讯信息的格式应当与 "作者地址" 章节
的信息格式类似。
Flanagan & Ginoza Informational [Page 19]
RFC 7322 RFC Style Guide September 2014
4.12. "作者地址" ("Author's Address" 或 "Authors' Addresses") 章节
此必须章节给出了在首页页头中列出的作者的通讯信息。
通讯信息中包括一个必须的长期有效的电子邮件地址, 及可选的邮政地址和/或
电话号码。如果包括了一个邮政地址, 地址中应当包含国家名称, 该名称采用
由 ISO 3166 Maintenance Agency [ISO_OBP] 所列出的英文缩写。此章节的目
的是: (1) 明确定义作者身份 (例如, the John Smith who works for FooBar
Systems); (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 Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<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>.
Flanagan & Ginoza Informational [Page 20]
RFC 7322 RFC Style Guide September 2014
[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>.
[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>.
[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>.
[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 of
Chicago Press, 2010.
[FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to
the 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 and
documentation, Subcommittee SC 9, Identification and
description, "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 Informative
References", <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 Current
Practices", 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 to
Request for Comments (RFC) Authors", Work in Progress,
draft-rfc-editor-rfc2223bis-08, August 2004.
[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>.
[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 Editor
Model (Version 2)", RFC 6635, June 2012,
<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>.
[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 Procedures
The following procedures are related to the application and updating
of the RFC Style Guide.
A.1. Dispute Resolution
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.
A.2. Returning an I-D to the Document Stream
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.
A.3. Revising This Document and Associated Web Pages
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].
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.
Flanagan & Ginoza Informational [Page 23]
RFC 7322 RFC Style Guide September 2014
IAB Members at the Time of Approval
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
致谢
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.
Robert T. Braden
USC Information Sciences Institute
Joyce Reynolds
Jon Postel
贡献者
Alice Russo
RFC Production Center
作者地址
Heather Flanagan
RFC Series Editor
EMail: rse@rfc-editor.org
Sandy Ginoza
RFC Production Center
EMail: rfc-editor@rfc-editor.org
Flanagan & Ginoza Informational [Page 24]
1698
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
