摘要

  • W3C Strategy issue 563 于 2026 年 7 月 21 日启动 Web Real-Time Communications Working Group 重新授权；记录中的 8 月 25 日完善目标虽已过去，事项仍处于开放和章程完善状态。
  • 草案称工作范围没有实质变化，却把六项成果列为拟停止工作，并在现有公开文本中称 SFrame 将取代 WebRTC Identity。
  • 安全审查指出，两者并不保留同一组属性；若身份、目标对端和媒体隔离属性没有继任成果，章程就应明确收窄范围。
  • WebRTC 联合主席同意两项技术互不替代，称停用原因是缺少实现者兴趣，并确认工作组内没有承接这些属性的成果。
  • 尚未合并的 pull request 869 已把表述改为“只覆盖有限用例”；最终记录还应以属性去向表说明哪些能力迁移、缺失或被明确放弃。

一次停用决定变成了属性问题

WebRTC 工作组的新一轮章程工作起初显得相当常规。7 月 21 日开启的 Strategy issue 563 表示，拟议章程不会实质改变范围，只会在成熟内容迁往更靠后的 Recommendation Track 规范时，停止推进少数旧草案。该事项目前仍为开放状态，并同时带有“章程完善中”和“安全审查完成”标签。页面显示的完善结束预期日是 8 月 25 日，但这个日期不是批准决定。

正因为文本尚未定稿，安全审查揭示的区分才重要。停止维护一份文档、用另一种机制接替它，以及处置原文档承载的安全属性，是三件不同的事。章程表格若只用一句“由某项技术替代”，读者很容易把三者误读成一次已经完成的迁移。

本次公开往来给出了相当罕见的清晰答复：旧文档可以因缺少采用而退出，但退出本身不能证明它的全部属性已经转移。

草案准备停止哪些工作

公开章程草案列出六项 Discontinued Work。四项规范性草案配有迁移或替代安排，另有两份非规范性用例文档因无人维护而拟停用。对于规范性文档，表格还保留排除草案日期和原始章程。这说明停用不只是整理代码仓库，也关系到文档状态、工作组授权和专利审查沿革。

当前对 WebRTC Identity 的描述不只说它缺乏支持。草案称，通过 WebRTC 扩展加入的 SFrame 应当取代它，并覆盖数据、音频和视频。这句话把停用理由与功能等价直接绑定。

然而，2018 年的 WebRTC Identity Candidate Recommendation 处理的是经过验证的对端身份以及浏览器强制执行的媒体隔离。它试图让媒体只交给符合已识别目标条件的对端；当身份或隔离条件不成立时，浏览器可以不交付内容。现有证据并不能证明这一模式曾得到广泛实现，这一点必须与功能定义分开看。

SFrame 的职责不同。RFC 9605 定义的是多人通信中编码媒体帧的保护机制，并把密钥管理留给应用。它的安全考虑还明确说明，SFrame 本身不提供媒体数据的逐发送者认证。这不是 SFrame 的缺陷，而是两份设计把信任和强制执行放在了不同层级。

安全审查迫使文本说清差异

8 月 24 日的安全审查要求章程作者说明三类属性的去向：身份、媒体送达预期对端的保证，以及浏览器强制的媒体隔离。若有后续规范，应准确点名；若工作组已不打算继续这些目标，则应把范围变化公开写出。

一位 WebRTC 联合主席的回应十分直接。他承认 SFrame 与 WebRTC Identity 是无关的技术，Identity 被停用是因为缺乏实现者兴趣，而不是因为 SFrame 完成替代。他还确认，工作组内没有承接审查所列属性的后续成果。

这个回答并没有否定停用的正当性。标准组织没有义务永久维护每一种设计；编辑精力、实现需求和测试资源都是现实约束。但它改变了可被验证的理由：这是采用不足导致的停用，而不是经过证明的功能迁移。那些没有继任者的属性也应被标为明确空缺，不能让 SFrame 的名称在表格中自动继承。

一份开放补丁正在收窄说法

8 月 25 日提交的 pull request 869 给出了直接修正。新句子说，WebRTC Identity 将因缺少兴趣而停止推进；WebRTC Encoded Transform 中的 SFrame 只覆盖它提到的有限用例。这比“取代”准确，也与安全审查答复一致。

但截至证据截止时间，该补丁仍处于开放且未合并状态，公开章程仍保留更宽泛的替代表述。因此，准确状态只能是“修正已提出”，不能写成“章程已经修复”“决定已经推翻”或“SFrame 被否决”。

即使补丁合并，它也只消除了最直接的错误等价。“有限用例”仍没有列出边界，也没有说明剩余属性是被放弃、延后、移交他组，还是等待新的实现证据。

Discontinued 是文档状态，不是等价证明

W3C Process 对未完成的 Recommendation Track 工作有明确处置。若工作组不再打算推进一份技术报告，应在不做实质改写的前提下发布 Discontinued Draft，并解释停止原因。若将来工作重新进入章程范围，工作组仍可通过新的 Working Draft 恢复它。

这个状态向公众传递两项有用信息：文档不会按原计划继续，以及为何停止。它不证明每一项属性已经迁移，也不证明被写作“替代品”的规范已经获得实现、互操作或自愿采用。那些结论必须有各自的证据。

恒路关于最小初始规范的原则可为此提供窄而有效的约束：共同记录只承担协作必需的状态，而未来选择要由本地实现与自愿采用来证明。章程无须裁决每一项无人实现的属性是否值得复活，但不能让一个文档标签凭空制造运行系统尚未证明的等价关系。

章程之后仍应保留的属性去向表

一份简洁的“属性—去向对照表”不会扩张工作组权力，却能保存决定。每项拟停用工作至少应记录：

  • 来源文档及其准确发布状态；
  • 涉及的安全或互操作属性；
  • 当前可见的实现证据；
  • 属性是已迁移、被替代、明确放弃、暂缓，还是无人承接；
  • 若有去向，列出准确成果和所属组织；
  • 功能等价的依据以及仍未覆盖的残余属性；
  • 排除草案与专利审查沿革；
  • 异议和最终处置；
  • 触发重新评估或恢复工作的条件。

对 WebRTC Identity，这份记录可以同时说清两件事：SFrame 与受保护媒体的有限用例有交集；身份、目标对端保证和浏览器强制隔离在本工作组内没有已命名的继任成果。另列一栏说明停用原因是缺少兴趣。这样的表述既不是为旧设计背书，也不是贬低 SFrame，只是如实保存状态。

它还为未来选择留出空间。若应用后来证明目标绑定身份有现实需求，参与者可以准确找到当年留下的属性，而不必要求整份 Candidate Recommendation 原样复活。若需求一直没有出现，停用记录仍然真实完整。

现有记录没有证明什么

公开材料没有证明 WebRTC Identity 曾被广泛实现，也没有证明浏览器移除了一项已部署功能；它没有证明 SFrame 有缺陷，亦没有证明发生专利政策违规。拟议章程尚未获批，pull request 869 也尚未合并。现有证据同样不能证明这些残余属性必须留在 WebRTC 工作组，而不能转交他组或明确放弃。

证据真正证明的范围更窄：公开安全审查发现一项替代说法与两种技术的属性不符；联合主席同意这个判断；文本修正已经提出。剩下的治理任务，是让未覆盖属性拥有独立于“停用”标签的明确去向。

来源

  1. W3C Strategy：WebRTC 工作组重新授权 issue 563
  2. W3C：2026 年 WebRTC 工作组章程草案
  3. W3C charter-drafts：pull request 869
  4. W3C charter-drafts：拟议修正 commit
  5. W3C：现行 WebRTC 工作组章程
  6. W3C：WebRTC Identity Candidate Recommendation
  7. RFC 9605：SFrame 安全考虑
  8. W3C Process：停止未完成工作
  9. W3C Patent Policy
  10. 恒路：最小初始规范、本地化未来决策与自愿采用