摘要

  • W3C WebTransport 工作组的新章程于 2026 年 9 月 1 日生效，期限至 2028 年 8 月 31 日；章程历史把本次新增事项称为潜在的点对点交互工作。
  • 点对点出现在“范围”部分，原文是工作组正在考虑孵化相关机制；“规范性交付物”部分却只列出 WebTransport，并明确初始版本限于客户端—服务器连接。
  • 公开 Issue 590 把本地网络、NAT 后服务器、mDNS、ICE、NAT-PMP、UPnP 与点对点 QUIC 等不同问题放在一起提问，没有选择任何方案。
  • 章程审查中的一条非阻塞安全意见要求进行至少高层次的评审；公开回复承诺新能力会尽早评审，并预计在 TPAC 安排专题讨论。这不是技术采纳决定。
  • W3C 流程把“范围”和“交付物”分开规定。以后若出现新的推荐标准轨交付物，是否落在现有交付物范围内，将影响它属于重大修改还是其他处理路径。
  • 后续公开记录应明确：点对点是进入下一版 WebTransport、另立交付物、转入其他工作组、停留在非规范性孵化，还是被搁置或关闭。

新章程给的是探索权，不是成品牌照

9 月 1 日生效的章程有一句写得很克制：WebTransport 工作组“也在考虑孵化点对点能力的机制”。两个动词都不应省略。“考虑”表示结论尚未形成，“孵化”表示问题、用例和设计仍可被拆解、试验和淘汰。

同一份章程没有把点对点列成规范性交付物。它列出的规范只有 WebTransport，描述的仍是浏览器与服务器之间的数据传输 API，并特别注明该交付物的初始版本限于客户端—服务器连接。章程历史采用的也是“潜在的新工作”，而不是“新增规范”。

这不是文字矛盾，而是一套有顺序的状态。范围决定工作组可以研究什么；交付物决定哪一份成果已有明确的标准轨归属；工作草案、候选推荐标准与推荐标准继续标记文档成熟度；实现、互操作和实际采用则提供另一层技术证据。

若把这些状态压成一句“W3C 已经支持点对点 WebTransport”，机构授权、技术选择和部署现实就会同时被提前。

“点对点”目前不是一个已经定义好的功能

公开的 WebTransport Issue 590 说明了为什么要保留孵化状态。提问者遇到的需求并不相同：有些人希望客户端和服务器在同一本地网络中相互发现；有些人面对的是 NAT 后的服务器；另一些讨论涉及不依赖 ICE 的点对点 QUIC。问题中列出的 mDNS、ICE、NAT-PMP 和 UPnP 只是可能的思路。

这些路径会暴露不同的信息，也会改变连接的发起者、信任边界与企业网络控制。找到局域网中的一台服务，与让任意两个浏览器穿越家用路由器，并不是同一种风险。把“服务器在 NAT 后”简称为“浏览器对浏览器”，也可能掩盖真正要解决的拓扑问题。

Issue 590 因而只问“应该采取什么方法”。截至证据截止时，它仍为开放状态，没有记录工作组决议、选定协议或规范文本。把罗列过的技术名词改写成产品路线图，会使一份问题清单看起来像已经形成的计划。

章程审查还引用过另一份 Local Peer-to-Peer API 的 TAG 评审。那是 WICG 孵化的不同提案，最初连标准化归属都没有确定。TAG 的安全意见要求具体威胁模型，并提到功能滥用、发现、设备指纹、用户画像及类似 UPnP 的问题。WebTransport 章程的安全评审者明确说明两者不是同一提案。

因此，这些问题只能作为比较坐标，不能冒充 WebTransport 自己已经完成的评审。相近能力需要相近的警觉，不等于一份提案的结论可以自动移植给另一份设计。

“会尽早评审”仍然是未来时

7 月 29 日，Strategy Issue 537 收到一条迟到但明确标注为非阻塞的安全意见。意见把新范围与 Issue 590 联系起来，并询问点对点孵化是否至少会经过高层次评审。8 月 24 日的公开回复说，任何新能力都会得到早期评审，并预计在 TPAC 举行专题讨论。

这项承诺的价值在于把安全和隐私问题放到设计早期，而不是等文档成熟后才补票。它没有证明专题讨论已经发生，也没有证明威胁模型已获接受、某种穿透技术已形成共识，或工作组已把点对点写进规范。

9 月 1 日，Issue 537 以 completed 状态关闭。最后一条公开评论说章程已经宣布，并链接到会员可见的存档。现在可由公众直接核验的是最终章程与工作组页面：新任期从 2026 年 9 月 1 日开始，到 2028 年 8 月 31 日结束。

关闭前短暂出现的计票标签和时间间隔，不能用来推算票数、异议或保密理由。本文不重构会员材料。公开证据已经足够支持一个更窄的结论：点对点探索获得了工作范围，但设计身份仍未决定。

2027 年 2 月不是预先填好的答案

章程时间线写有“2027 年 2 月：下一版 WebTransport 的首份公开工作草案”。这个节点很容易被当成点对点的默认归宿，然而章程没有建立这种对应关系。

下一版可能容纳点对点，也可能不容纳；它可能只加入其他功能。点对点也可能成为单列的推荐标准轨交付物、形成非规范性的用例或说明文档、与另一个 W3C 或 IETF 工作流协同，或者在试验后终止。日期只能说明预期发布节点，不能代替内容差异和采纳决定。

W3C 流程文件把边界写得更清楚。章程必须分别写明工作范围与交付物性质。范围变化属于重大修改；若新增推荐标准轨交付物且不在现有交付物范围内，也属于重大修改。另一方面，对已在范围内的交付物进行更名或重组，可以有不同处理。

所以，现在就断言“一定要重新修章程”并不准确；说“既然点对点在范围内，任何未来规范都已自动获批”同样不准确。程序路径取决于以后究竟提出了什么，以及它与现有 WebTransport 交付物的关系。

需要公开的是身份变化那一刻

最小的治理补丁不是再增加一层审批，而是给孵化事项附上一份公开状态回执。它应记录问题陈述与仓库、下一步分类的责任主体、安全与隐私及架构评审、与 IETF 的依赖协调、改变状态的工作组决议或 W3C 动作、承接工作的规范或机构，以及关闭或替代原孵化记录的事件。

公众至少应能区分五种结局：

  1. 点对点进入现有 WebTransport 交付物的下一版本；
  2. 它成为另一个单列的推荐标准轨交付物；
  3. 它被转交或拆分到其他 W3C、IETF 工作流；
  4. 它只形成试验、用例或其他非规范性材料；
  5. 它被延期或关闭。

现在不应替工作组选择任何一项。回执的意义恰恰在于答案尚未出现：以后不能让一次编辑提交、一场会议讨论或一项实现试验悄悄充当获得标准身份的那个动作。

这也是《Running-Code Primacy》在此处最适合的用法。章程可以为技术工作划定边界，运行实现可以检验设计价值；但程序、文档和代码各自只证明自己的那一层。问题发现、孵化、公开决定、规范状态、可测试实现和实际采用应按顺序保留，不能互相冒名。

新章程已经完成了第一步：点对点不再位于 WebTransport 工作组可探索范围之外。它还没有完成下一步：把某个具体机制变成单列的规范性成果。真正的治理考题，是那个变化发生时公众能否看见是谁、依据什么证据、通过哪一项正式动作作出的决定。

来源

  1. W3C — 2026 年 WebTransport 工作组章程
  2. W3C — WebTransport 工作组页面
  3. W3C — WebTransport 章程历史
  4. W3C Strategy Issue 537 — WebTransport 工作组章程
  5. 要求高层次点对点评审的迟到、非阻塞安全意见
  6. 承诺尽早评审并预计举行 TPAC 专题讨论的公开回复
  7. WebTransport Issue 590 — NAT 后或本地网络中的服务器
  8. W3C TAG Design Review 932 — Local Peer-to-Peer API
  9. TAG 对另一项 Local Peer-to-Peer API 的安全意见
  10. W3C 流程文件，2025 年 8 月 18 日版
  11. W3C — 2026 年 7 月 17 日公开的 AC 评审通知
  12. W3C — 2026 年 7 月 30 日 WebTransport 候选推荐标准快照
  13. 引入点对点范围的章程草案提交
  14. Lu Heng — Running-Code Primacy