4. 互联网标准跟踪 (The Internet Standards Track)

旨在成为互联网标准的规范通过一组称为"标准跟踪"的成熟度级别演进.这些成熟度级别——"提议标准" (Proposed Standard),"草案标准" (Draft Standard) 和"标准" (Standard)——在第4.1节中定义和讨论.规范沿标准跟踪移动的方式在第6节中描述.

即使在规范被采纳为互联网标准之后,基于经验和新需求的认识,进一步的演进也经常发生.互联网标准化的术语和程序规定了用新的互联网标准替换旧的互联网标准,并分配描述性标签以指示"退役"互联网标准的状态.第4.2节定义了一组成熟度级别,以涵盖这些以及其他不被认为在标准跟踪上的规范.

4.1 标准跟踪成熟度级别 (Standards Track Maturity Levels)

互联网规范经历开发,测试和接受阶段.在互联网标准化流程中,这些阶段被正式标记为"成熟度级别".

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

4.1.1 提议标准 (Proposed Standard)

标准跟踪的入门级成熟度是"提议标准".IESG需要采取特定行动才能将规范移至"提议标准"级别的标准跟踪.

提议标准规范通常是稳定的,已解决已知的设计选择,被认为是被充分理解的,已获得重要的社区审查,并且似乎享有足够的社区兴趣以被认为是有价值的.然而,在其推进之前,进一步的经验可能会导致规范的更改甚至撤回.

通常,将规范指定为提议标准既不需要实现也不需要运营经验.然而,这种经验是非常可取的,并且通常会代表支持提议标准指定的强有力论据.

对于实质上影响核心互联网协议或指定可能对互联网产生重大运营影响的行为的规范,IESG可能要求在授予提议标准状态之前提供实现和/或运营经验.

提议标准对于放置在其上的要求应该没有已知的技术遗漏.然而,当规范被认为是有用和必要 (且及时) 的时候,即使存在已知的技术遗漏,IESG也可以放弃此要求以允许规范推进到提议标准状态.

实现者应将提议标准视为不成熟的规范.实现它们以获得经验并验证,测试和澄清规范是可取的.然而,由于如果发现问题或确定更好的解决方案,提议标准的内容可能会更改,因此不建议在中断敏感环境中部署此类标准的实现.

4.1.2 草案标准 (Draft Standard)

如果至少已从不同代码库开发出两个独立且可互操作的实现,并且已获得足够成功的运营经验,则可以将规范提升到"草案标准"级别.就本节而言,"可互操作"是指在其使用的系统或过程中功能等效或可互换的组件.如果实现需要专利或其他受控技术,则单独的实现还必须源于许可流程的单独执行.提升到草案标准是状态的重大进步,表明坚信规范是成熟的并且将是有用的.

对至少两个独立且可互操作实现的要求适用于规范的所有选项和功能.如果一个或多个选项或功能未在至少两个可互操作实现中得到证明,则规范只有在删除这些选项或功能的情况下才能推进到草案标准级别.

工作组主席负责记录符合规范草案或互联网标准状态资格的具体实现,以及有关这些实现互操作测试的文档.该文档必须包含有关每个单独选项和功能的支持的信息.该文档应与协议行动请求一起提交给区域主任.(参见第6节)

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

草案标准通常被认为是最终规范,并且更改可能仅针对解决遇到的特定问题而进行.在大多数情况下,供应商将草案标准的实现部署到中断敏感环境是合理的.

4.1.3 互联网标准 (Internet Standard)

已获得重大实现和成功运营经验的规范可以提升到互联网标准级别.互联网标准 (可以简称为标准) 的特征是高度的技术成熟度以及普遍认为指定的协议或服务为互联网社区提供重大利益.

达到标准状态的规范在保留其RFC编号的同时被分配STD系列中的编号.

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

并非每个规范都在标准跟踪上.规范可能不打算成为互联网标准,或者可能旨在最终标准化但尚未准备好进入标准跟踪.规范可能已被更新的互联网标准取代,或者由于其他原因而不再使用或失宠.

不在标准跟踪上的规范被标记为三个"非跟踪"成熟度级别之一: "实验性" (Experimental),"信息性" (Informational) 或"历史性" (Historic).带有这些标签的文档在任何意义上都不是互联网标准.

4.2.1 实验性 (Experimental)

"实验性"指定通常表示属于某些研究或开发工作的一部分的规范.此类规范发布是为了向互联网技术社区提供一般信息,并作为工作的档案记录,仅受编辑考虑和验证与标准流程有足够协调的约束 (见下文).实验性规范可能是有组织的互联网研究工作 (例如,IRTF的研究组),IETF工作组的输出,或者可能是个人贡献.

4.2.2 信息性 (Informational)

"信息性"规范发布是为了向互联网社区提供一般信息,并不代表互联网社区的共识或建议.信息性指定旨在提供来自许多来源的非常广泛范围的负责任信息文档的及时发布,仅受编辑考虑和验证与标准流程有足够协调的约束 (参见第4.2.3节).

在互联网社区之外准备的规范,如果未通过第10节的任何规定纳入互联网标准化流程,则可以在所有者许可和RFC编辑同意的情况下作为信息性RFC发布.

4.2.3 实验性和信息性RFC的程序 (Procedures for Experimental and Informational RFCs)

除非它们是IETF工作组行动的结果,否则打算以实验性或信息性状态发布的文档应直接提交给RFC编辑.RFC编辑将发布任何尚未作为互联网草案发布的此类文档作为互联网草案.为了区分这些互联网草案,它们将在I-D目录中被标记或分组,以便于识别.RFC编辑将在此发布后等待两周以征求意见,然后再继续.RFC编辑应就文档以实验性或信息性状态发布的编辑适用性行使其判断,并可能拒绝发布在RFC编辑的专家意见中与互联网活动无关或低于RFC技术和/或编辑标准的文档.

为确保非标准跟踪的实验性和信息性指定不被滥用来规避互联网标准化流程,IESG和RFC编辑已同意,RFC编辑将向IESG提交任何提交以供实验性或信息性发布的文档,这些文档在RFC编辑看来可能与IETF社区正在进行或预期进行的工作相关.IESG应在合理的时间内审查此类转介文档,并建议将其按原提交发布或作为对互联网标准化流程的贡献转介给IETF.

如果 (a) IESG建议将文档纳入IETF并在IETF环境中推进,但作者拒绝这样做,或 (b) IESG认为文档提出的内容与已建立的IETF工作冲突或实际上有害,该文档仍可作为实验性或信息性RFC发布.然而,在这些情况下,IESG可以在RFC的"本备忘录的状态"部分中或紧随其后插入适当的"免责声明"文本,以使其发布情况对读者清楚.

IETF工作组提出的实验性和信息性RFC文档经过IESG审查.使用第6.1.1节中描述的流程启动审查.

4.2.4 历史性 (Historic)

已被更新的规范取代或由于任何其他原因被认为已过时的规范被分配到"历史性"级别.(纯粹主义者建议该词应该是"Historical"; 然而,此时使用"Historic"已成为历史.)

注意: 标准跟踪规范通常不得依赖于处于较低成熟度级别的其他标准跟踪规范或非标准跟踪规范,除了来自其他标准机构的引用规范.(参见第7节.)

---