跳到主要内容

4. Internet 标准轨道 (THE INTERNET STANDARDS TRACK)

  1. Internet 标准轨道 (THE INTERNET STANDARDS TRACK)

旨在成为 Internet Standards 的规范, 会经历一组称为 "standards track" (标准轨道) 的成熟度级别. 这些成熟度级别, 即 "Proposed Standard", "Draft Standard" 和 "Standard", 在第 4.1 节中定义和讨论. 规范如何沿 标准轨道推进, 见第 6 节.

即使某个规范已被采纳为 Internet Standard, 它也经常会基于经验以及对新 需求的认识继续演进. Internet 标准化的命名和过程允许用新的 Internet Standards 替换旧标准, 并分配描述性标签以表明 "retired" Internet Standards 的状态. 第 4.2 节定义了一组成熟度级别, 用于覆盖这些规范 以及其他不被认为处于标准轨道上的规范.

4.1 标准轨道成熟度级别 (Standards Track Maturity Levels)

Internet 规范会经历开发, 测试和接受等阶段. 在 Internet Standards Process 中, 这些阶段被正式标记为 "maturity levels" (成熟度级别).

本节描述这些成熟度级别以及每个级别上规范的预期特征.

4.1.1 提议标准 (Proposed Standard)

标准轨道的入门成熟度级别是 "Proposed Standard". 将某个规范以 "Proposed Standard" 级别移入标准轨道, 需要 IESG 采取明确行动.

Proposed Standard 规范通常是稳定的, 已解决已知设计选择, 被认为已被 充分理解, 接受过大量社区审查, 并且似乎拥有足够社区关注而可被认为有 价值. 但是, 在其推进之前, 进一步经验可能导致规范变更, 甚至撤回.

通常, 将某个规范指定为 Proposed Standard 不要求实现经验或运行经验. 但是, 这类经验非常可取, 并且通常会成为支持 Proposed Standard 指定的 有力论据.

对于实质影响核心 Internet 协议的规范, 或规定的行为可能对 Internet 运行产生重大影响的规范, IESG 可以在授予 Proposed Standard 状态之前 要求实现和/或运行经验.

就其所承担的要求而言, Proposed Standard 不应存在已知技术遗漏. 但是, 当某个规范即使存在已知技术遗漏仍被认为有用, 必要且及时, IESG 可以 豁免此要求, 以允许该规范推进到 Proposed Standard 状态.

实现者应将 Proposed Standards 视为未成熟规范. 为获得经验并验证, 测试 和澄清规范, 实现它们是可取的. 但是, 如果发现问题或识别出更好的解决 方案, Proposed Standards 的内容可能发生变化, 因此不建议将这类标准的 实现部署到对中断敏感的环境中.

4.1.2 草案标准 (Draft Standard)

如果某规范已经从不同代码库开发出至少两个独立且可互操作的实现, 并且 已获得充分的成功运行经验, 则可以提升到 "Draft Standard" 级别. 就本 节而言, "interoperable" (可互操作) 意味着它们在所使用的系统或流程中 是功能等价或可互换的组件. 如果实现需要专利技术或其他受控技术, 则这些 独立实现还必须来自许可流程的分别行使. 提升到 Draft Standard 是状态上 的重大推进, 表明人们强烈相信该规范已经成熟且将会有用.

至少两个独立且可互操作实现的要求适用于规范的所有选项和特性. 如果一个 或多个选项或特性尚未在至少两个可互操作实现中得到证明, 则只有移除这些 选项或特性后, 该规范才可以推进到 Draft Standard 级别.

Working Group 主席负责记录使该规范符合 Draft 或 Internet Standard 状态 资格的具体实现, 以及这些实现互操作测试的文档. 文档必须包含每个单独 选项和特性的支持信息. 该文档应随协议行动请求一起提交给 Area Director. (见第 6 节)

Draft Standard 必须被充分理解, 并且无论在语义上还是作为开发实现的基础, 都已知相当稳定. Draft Standard 可能仍需要额外或更广泛的现场经验, 因为 基于 Draft Standard 规范的实现, 在生产环境中大规模使用时可能表现出 未预见的行为.

Draft Standard 通常被认为是最终规范, 更改很可能只用于解决遇到的具体 问题. 在大多数情况下, 供应商将 Draft Standards 的实现部署到对中断 敏感的环境中是合理的.

4.1.3 Internet 标准 (Internet Standard)

已获得大量实现经验和成功运行经验的规范, 可以提升到 Internet Standard 级别. Internet Standard (也可简称为 Standard) 的特征是具有高度技术 成熟度, 并且普遍认为所规定的协议或服务能为 Internet 社区提供显著 益处.

达到 Standard 状态的规范会在 STD 系列中分配一个编号, 同时保留其 RFC 编号.

4.2 非标准轨道成熟度级别 (Non-Standards Track Maturity Levels)

并非每个规范都处于标准轨道上. 某个规范可能并不打算成为 Internet Standard, 或者虽然最终打算标准化但尚未准备好进入标准轨道. 某个规范 可能已被更新的 Internet Standard 取代, 或者因其他原因不再使用或不再 受认可.

不在标准轨道上的规范会被标记为三种 "off-track" (轨道外) 成熟度级别 之一: "Experimental", "Informational" 或 "Historic". 带有这些标签的 文档在任何意义上都不是 Internet Standards.

4.2.1 实验性 (Experimental)

"Experimental" 标记通常表示某个规范是某项研究或开发工作的一部分. 这类规范的发布是为了向 Internet 技术社区提供一般信息, 并作为该工作的 归档记录; 它只受编辑方面考虑以及确认已与标准流程进行充分协调的约束 (见下文). Experimental 规范可以是有组织的 Internet 研究工作的产出 (例如 IRTF 的 Research Group), 可以来自 IETF Working Group, 也可以是 个人贡献.

4.2.2 信息性 (Informational)

"Informational" 规范是为 Internet 社区提供一般信息而发布的, 并不代表 Internet 社区的共识或建议. Informational 标记旨在为来自多种来源的, 范围非常广泛且负责任的信息性文档提供及时发布机制; 它只受编辑方面考虑 以及确认已与标准流程进行充分协调的约束 (见第 4.2.3 节).

在 Internet 社区之外编写, 且未通过第 10 节任何条款纳入 Internet Standards Process 的规范, 可以在所有者许可且 RFC Editor 同意的情况下 作为 Informational RFC 发布.

4.2.3 Experimental 和 Informational RFC 的过程 (Procedures for Experimental and Informational RFCs)

除非它们是 IETF Working Group 行动的结果, 打算以 Experimental 或 Informational 状态发布的文档应直接提交给 RFC Editor. RFC Editor 会将 任何尚未作为 Internet-Drafts 发布的这类文档发布为 Internet-Drafts. 为了区分这些 Internet-Drafts, 它们会在 I-D 目录中被标记或分组, 以便 易于识别. 发布后, RFC Editor 会等待两周接收评论, 然后再继续处理. RFC Editor 应对文档是否适合以 Experimental 或 Informational 状态发布 作出编辑判断, 并且可以拒绝发布在 RFC Editor 专家意见中与 Internet 活动无关, 或低于 RFC 技术和/或编辑标准的文档.

为确保非标准轨道的 Experimental 和 Informational 标记不被滥用来规避 Internet Standards Process, IESG 和 RFC Editor 已达成一致: 对于提交 为 Experimental 或 Informational 发布的任何文档, 如果 RFC Editor 认为 它可能与 IETF 社区正在进行或预期进行的工作有关, RFC Editor 会将其 提交给 IESG. IESG 应在合理时间内审查这类转交文档, 并建议按原提交 形式发布, 或将其提交给 IETF 作为 Internet Standards Process 的贡献.

如果 (a) IESG 建议将该文档纳入 IETF 并在 IETF 上下文内推进, 但作者 拒绝这样做, 或 (b) IESG 认为该文档提出的内容与既有 IETF 工作冲突, 或实际有害于该工作, 该文档仍可作为 Experimental 或 Informational RFC 发布. 但是在这些情况下, IESG 可以在 RFC 的 "Status of this Memo" 节中或紧随其后插入适当的 "disclaimer" (免责声明) 文本, 以向读者说明 其发布情况.

由 IETF Working Groups 提议作为 Experimental 和 Informational RFC 的 文档需要经过 IESG 审查. 审查使用第 6.1.1 节描述的过程发起.

4.2.4 历史性 (Historic)

已被更新规范取代, 或因任何其他原因被认为已经过时的规范, 会被分配到 "Historic" 级别. (纯粹主义者曾建议该词应为 "Historical"; 但是到目前 为止, 使用 "Historic" 已经成为历史.)

注: 标准轨道规范通常不得依赖成熟度级别更低的其他标准轨道规范, 也不得 依赖非标准轨道规范, 但引用其他标准机构的规范除外. (见第 7 节.)

最后于 更新