摘要

  • IESG 已就 RFC 7405 从 Proposed Standard 晋级为 Internet Standard、并加入 STD 68 征求全 IETF 意见，截止日为 9 月 28 日；目前尚无决定。
  • RFC 7405 于 2014 年为 ABNF 加入区分大小写的 %s 字符串和明确不区分大小写的 %i 字符串，未加前缀的旧语法保持不区分大小写。
  • 晋级申请称，截至 2026 年第二季度已有 20 份 RFC 规范性引用它，并列举 HTTP/1.1、YANG 和工具广泛支持；没有已知互操作问题或分歧解释。
  • 规范引用证明文本依赖，工具支持证明能力；二者都不能自动替代两套独立实现、互操作、广泛部署与成功运行经验的可追索记录。
  • 解决办法不是恢复 RFC 6410 已取消的正式互操作报告，而是附上一份轻量、可核验的成熟度证据回执。

这次改变的是身份，不是语法

ABNF 是许多互联网规范用来描述消息、字段和关键词结构的形式语言。现有 STD 68 由 RFC 5234 承载。它的默认引号字符串不区分大小写；如果作者需要精确的小写或大写，只能逐个写出十进制或十六进制字符值。

RFC 7405 把这个笨重写法变成两个前缀：%s"false" 只匹配指定大小写，%i"aBc" 明确表示不区分大小写；不带前缀时继续兼容旧规则。这是一项窄小、容易理解的更新。

本次申请不准备发布新 RFC。RFC 6410 允许 IESG 在至少四周的全 IETF Last Call 后，直接重新分类现有文档。8 月 31 日的公告说明，申请来自一名个人参与者，IESG 计划在未来数周决定，实质意见须在 9 月 28 日前提交。证据冻结时，Datatracker 状态仍是 AD Review。

因此，申请、征求意见和最终晋级是三个权限状态。参与者可以补充事实、提出异议；IESG 才能改变标签。不能把正在接受审查的理由写成已经成立的结论。

汇总证据并不薄弱

申请书记录了一个清晰的采用趋势。截至 2026 年第二季度，20 份 RFC 对 RFC 7405 作规范性引用。当前 Datatracker 依赖页还列出 HTTP、YANG、邮件、媒体、CDDL 和 DNS 等不同领域的 RFC 与活跃草案，同时提醒读者其引用提取依靠启发式方法。

RFC 7950 给出了肉眼可见的使用。YANG 1.1 的语法用 %s 固定 module、container、leaf、rpc 等大量关键词的大小写。申请还把 HTTP/1.1 作为重要例子，并称 ABNF 工具已广泛实现 RFC 7405。

另一个例子揭示加入 STD 68 的编辑价值。2024 年的 RFC 9535 仍用十六进制字节写小写的 true、false 和 null。这不能证明作者的工具不支持 %s，更不是故障；它只能说明，新扩展的权威地位仍未被每一位新规范作者自然接受。

其余成熟度条件也有直接回答：提出用单引号替代现有形式的勘误已经被拒绝；没有已知会导致新实现无法互操作的勘误；这项功能没有显著增加未使用复杂度，也不依赖受控技术。

这些理由足以支持认真考虑晋级。问题在于，其中第一项仍把不同性质的证明压缩成了一段话。

“被引用”与“在生产中运行”之间有一道桥

RFC 6410 的第一项标准包含五个命题：至少两套实现、实现彼此独立、两者可互操作、已有广泛部署、并有成功运行经验。规范引用数量并不直接回答代码库是否独立；工具“广泛支持”也没有告诉读者哪些版本、输入和运行场景受过观察。

公开申请没有列出两套实现，没有说明共同语法样本或对端，没有定义怎样算广泛，也没有给出运行时段与结果。这是一项对公开材料的有限观察，不是“实现不存在”或“标准未满足”的结论。证据完全可能散落在开源仓库、维护者经验、运营网络和邮件列表中。

不过，成熟度标签一旦生效，后来读者看到的将是统一结论，而不是当年的分散记忆。若“没有已知问题”来自多套解析器多年处理实际语法，它很有分量；若没有写清观察面，几年后就难以区分真正的长期运行经验与单纯没有收到报告。

不必重建旧式测试仪式

最有力的反驳来自 RFC 6410 自身。它明确取消了正式互操作报告的强制要求，因为部署与使用可以证明互操作。为了一个已流通十二年的小特性重新组织实验室测试，很可能增加文书，却不增加判断质量。

所以需要的是回执，不是新闸门。至少两个例子各自记录实现名称与版本、代码库独立性的依据、实际使用的 %s 或 %i 语法、共同语料或对端、部署类型与有限尺度、观察时段、成功结果、已知排除项和稳定来源。涉及商业或安全敏感系统时，可以使用不泄露内部配置的边界描述。

IESG 随后仍需作出判断：为什么这些例子合在一起足以称为广泛部署和成功运行；Last Call 中的重大异议如何处置；何时正式改变 RFC 与 STD 记录。回执提供证据，不把决定自动化，也不让实现者取得制度主权。

“运行代码”也必须能被归因

Heng Lu 强调的 running-code 原则，在这里应被理解为证据纪律。代码能逼迫技术主张接受现实检验；但如果没有名称、版本、输入、独立对照和结果，“代码正在运行”也会沦为一句无法核验的权威口号。

各角色的边界并不冲突。实现者提供运行事实，RFC 作者与引用关系显示规范采用，Last Call 参与者提供经验与反对意见，IESG 依规则决定。RFC 7405 很可能值得晋级；一份小型公开桥梁只会让这个判断更耐久，而不会削弱它。

来源

  1. IETF — RFC 7405 晋级 Last Call
  2. IETF Datatracker — RFC 7405 状态变更申请
  3. RFC 6410 — 两级标准成熟度
  4. RFC 7405 — ABNF 区分大小写字符串
  5. IETF Datatracker — 对 RFC 7405 的引用
  6. RFC 5234 — ABNF 规范
  7. RFC 7950 — YANG 1.1 数据建模语言
  8. RFC 9535 — JSONPath 查询表达式
  9. RFC Editor — RFC 7405 勘误记录
  10. Heng Lu — 运行代码优先原则