摘要

  • W3C 页面称 w3.org/2026/08/xmldsig-more# 已分配给 XML Security，却只链接到 Datatracker 的“最新草案”，没有绑定具体版本和哈希。
  • 5 月 26 日的 -08 仍使用 w3.org/tbd#；8 月 21 日的 -09 首次换成新命名空间，同时加入其他内容。页面的 8 月 19 日修订时间位于两者之间。
  • W3C 自己的指导要求说明名称如何被定义或移除、由谁决定。新页面没有这项政策；沉默既不能证明可变，也不能证明不可变。
  • 一份命名空间变更宪章应绑定分配决定与确切版本，列明冻结前的变更类型、兼容性处理与决定者，指定冻结事件，并分开显示 W3C、IETF 与 IANA 状态。
  • 本文不指控分配无效、算法获得背书、IETF 已采纳草案、IANA 延误或跨机构协作失败；问题只是权限与版本链尚未在公开层接合。

两天的间隔，把版本问题变成了可核验事实

W3C 命名空间页面很短：它说该命名空间已经分配给 XML Security，称其对应一份规范，链接 RFC 9231bis 的 Datatracker 页面，并写明 Simone Onofri 最后修订于 2026 年 8 月 19 日。

短并不等于错。讨论尚未结束时就获得持久 URI，有利于编辑者摆脱临时占位符，避免各自创造相撞的名称，也让不同规范和实现可以围绕同一标识进行审阅。W3C 提供一个稳定地址，本来就不必同时承担技术背书。

真正缺少的是许可边界。页面没有给出分配决定、授权者、具体草案编号、文件哈希或冻结规则。它链接的是“最新版本”。读者可以方便地找到今天的文字，却无法从页面判断 W3C 当初审阅的是哪一份文字，也无法知道后续编辑是否仍在原许可范围内。

协作场所和草案内容都在继续移动

W3C Strategy issue 484在 2024 年 11 月 17 日创建，最初准备举办一次围绕 XML Signature 与 XML Encryption 后量子密码的研讨会。这是一条真实而开放的协调记录，但不是 Recommendation、工作组章程或正式过渡决定。

2024 年 11 月 21 日，RFC 9231bis 的个人草案作者表示愿意加入算法。2025 年 6 月 14 日，公开评论列出 HSS/LMS、ML-DSA、SLH-DSA、ML-KEM，并提出也许 GitHub issue 本身就可以替代研讨会。作者的提议和开放列表能够推动工作，却不会自动形成 W3C 共识或 IETF 采纳。

到 2026 年 8 月，变化更密集。8 月 17 日的更新称 -08 已覆盖上述四类，-09 还在准备其他内容。命名空间页面标记为 19 日。21 日，作者宣布 -09 已发布。26 日，该 issue 的作用又被重新描述：不再筹办研讨会，而是跟踪 XML Signature 与 XML Encryption 的更新需求。

这不是协作失败。相反，它说明公开工作能够改变路径、吸收意见。但只要工作载体、参与者和文档内容都可以变化，命名空间许可就更需要一条独立于“latest”链接的版本收据。

现有证据不能证明 W3C 审阅了哪一组确切字节，也不能证明内部没有更完整的记录。能证明的只有：公开页面没有暴露这条连接。

草案页与草案抬头各自回答不同问题

截至证据截点，Datatracker将 -09 显示为一份活跃的个人 Internet-Draft，IESG 状态为 I-D Exists，没有已定义的 RFC stream，也没有负责的 Area Director。任何人都可以提交 Internet-Draft；进入文档库不等于 IETF 采纳或背书。

草案抬头同时写着 Independent、Obsoletes: 9231 (if approved)、预期状态 Standards Track，并注明 2027 年 2 月 22 日失效。抬头表达作者希望到达的目的地和有条件的未来效果；Datatracker 表达机构当前可归责的程序状态。二者不是互相否定，也不应把其中一个称为错误。

5 月 26 日存档的 -08还把新标识写在 w3.org/tbd# 下，SHA-256 为 cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f。

8 月 21 日存档的 -09把占位符统一替换为 w3.org/2026/08/xmldsig-more#，加入该命名空间的 schema 附录，也包含其他新增内容。它的 SHA-256 为 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b。

公开版本历史确认了 5 月 26 日与 8 月 21 日的上传时间，并未显示工作组采纳、stream 分配或 Area Director 接手。

因此，公开事实只能支持一个谨慎结论：19 日的 W3C 页面早于第一份使用新 URI 的存档版本两天。它不能告诉我们分配决定实际发生在哪天，更不能告诉我们 W3C 许可是否自动覆盖 -09 的所有其他编辑。

一个 URI 穿过三个不同权力面

当前获批的基准仍是 RFC 9231。它记录上一代 XML Security URI，并明确把标识符与 W3C/IETF 对算法的官方地位分开。新草案也延续了这一防线。

IANA XML Security URIs 登记表仍以 RFC 9231 为参考，采用 Specification Required，并列出指定专家。继任草案尚未获批时，这正是合理状态；不能据此称 IANA 落后，更不能要求它提前复制 -09。

三个机构的动作不能压缩成一个“已批准”：

  1. W3C 在自己的 Web 命名空间中分配并维持 URI；
  2. IETF 文档程序可以发展、采纳、审议并可能批准一份使用该 URI 的规范；
  3. IANA 根据登记政策执行有效的注册动作。

个人作者能编辑草案，却不因此取得 W3C 命名空间政策的控制权。W3C 能分配地址，却不因此批准 IETF RFC。IANA 维护登记表，也不意味着某个算法必须部署。公开材料分别守住了这些边界；缺少的是各边界之间何时交接的共同地图。

W3C 的通用政策已经写出应回答的问题

W3C 命名空间分配指南承认 /YYYY/MM/... 一类日期式 URI，并说明 @w3c/transitions 通过 w3c/ns pull request 分配和授权这些形式。它同时解释，讨论期间保持标识稳定很有价值，而且分配不代表 W3C 背书相关规范。

同一份指南还要求小组明确说明其控制的命名空间以后会怎样变化或不会变化，并把预期写在命名空间文档中或从那里清楚链接。

W3C TAG 关于命名空间名称处置的 Finding更为具体：定义命名空间的规范应明确变更政策；若命名空间并非不可变，就应说明名称如何被赋予定义或被移除，以及由谁执行。没有明确声明时，不能推断命名空间不可变。

这句话同时挡住两种过度推断。新页面的沉默不能证明 -09 已冻结，也不能证明未来编辑者拥有开放式改名权。公开状态就是无法推知。

W3C URI 持久性政策把日期式资源纳入持久承诺，也允许资源修改并保存历史。地址连续性与局部名称集合不可变，是两项不同属性。

本文不据此宣布分配违规。可能存在未链接的合法授权材料。批评只到这里：用户在 W3C 自己建议的查找位置，仍看不到这项政策。

以前的每一代都把“冻结”当作事件

-09 将 2000 年前缀标为 “Frozen by W3C”，把 2001、2007、2021 三代分别与 RFC 4051、RFC 6931、RFC 9231 的冻结联系起来。冻结不是模糊印象，而是带有出处的状态转移。

2026 年这一代尚未公开说明：RFC 前能否增加名称，谁能移除，已经被实现或引用的名称是否必须保留，RFC 获批是否自动冻结，还是 W3C 另需动作，冻结后新增内容是否要另开日期式前缀。

外部评论者不需要替机构选择答案。治理要求只是让答案先于路径依赖出现。

标识符语法不是算法判决

XML Signature 1.1与 XML Encryption 1.1说明稳定标识对 XML 结构互操作为何重要，却不因此批准未来所有被命名的算法。

草案延续 Specification Required。 RFC 8126把这项政策建立在永久、公开的规范与专家审查上。它是登记准入方式，不是通用安全认证，也不是部署命令。

因此，本文不比较任何密码算法，不判断安全、不安全、成熟、最终、已实现或广泛部署。即使这些局部名称代表的不是算法，只要持久词汇依赖于仍在移动的文档，治理问题依然成立。

一页变更宪章就可以补上缺口

第一组字段应记录命名空间 URI、日期式类别、分配决定、授权主体、日期和公开的 pull request 或 transition 记录；然后分别记录分配时目标草案的编号与哈希，以及当前所链接的版本。

第二组字段应分类处理增加、文字纠正、重命名、移除和弃用。每一类都要说明谁能提议、谁能决定、对已存在的引用和实现如何兼容。

第三组字段应指定冻结事件、决定者和时间。冻结后，要说明扩展是继续使用同一前缀、走 IANA 专家审查、通过勘误或继任 RFC，还是开启新的日期式命名空间。

最后，页面要分别呈现 W3C 页面保管人；IETF 文档类别、工作组、stream、采纳状态与 Area Director（如有）；IANA 登记状态、政策与专家范围。标识符语法的权威来源，要与算法语义的来源分开。更正、勘误、继承、失效和下次复核触发条件都应留痕。

命名空间分配、草案发布、IETF 采纳或 stream 分配、RFC 批准、IANA 更新、协议或运营者部署，是六个不同动作。任何一个都不能替代下一个。

这份宪章无需公开私下讨论、敏感实现报告或个人通信。它只需要保存版本、权限、变化类别和状态转移。

这是一项可读性修复，不是行为指控

公开记录展现了许多健康特征：讨论开放，版本可追溯，W3C 地址持久，IANA 仍正确引用现行 RFC，草案也明确反对把 URI 当成机构背书。没有证据显示恶意、俘获、无权登记或协作破裂。

正因为零件已经存在，补接成本并不高。“latest”链接继续服务当前发现；版本化收据负责解释历史许可和未来边界。不要让一个动态链接同时承担这两种任务。