IETF-W3C

W3C 新版工作草案补上了传感数据的关系对照表。它能帮助团队说清哪些链接应当保留，却不能替任何部署证明一次转换没有改变数据含义。

一张候选人名单能说明谁获得提名，却不能说明当选者将为谁执行指令。W3C 新一届董事会的七个会员选举席位，带来的是对法人整体的受托责任；技术标准的制定和流程修订，仍有各自明确的权力归属。

网页代码能发起请求，却不能仅凭这个动作证明浏览器放行了什么。W3C 安全兴趣组在一份威胁模型草案中重新绘制了最上层的流程，恰好把“提出要求”和“作出调解”分到了两边。

一份看似简短的关联数据文件，进入程序后可能膨胀为庞大的内部结构。W3C 最新草案把这一风险说得更清楚，但怎样限制解析行为，仍是接收方自己的决定。

浏览器发出拒绝出售或分享数据的信号，网站公布支持 GPC 的声明，数据随后怎样流转：这是三件不同的事。W3C 最新工作草案把前两件事写得清楚，却没有把声明变成第三件事的证明。

W3C 9 月修订的关键不在新增操作，而在两个容易被客户端省略的约定：不写 `Accept` 时可能收到什么 RDF 格式，以及间接图名的字节如何还原。写入权限仍是另一道决定。

W3C 新版工作草案补上了电子书批注的安全说明。跨阅读器导入一条笔记时，定位到哪本书、署名是否可信、内容能否安全处理，是三件不同的事。

知识图谱需要容纳争议、传闻和被否定的假设。W3C 最新发布的 RDF 1.2 语义候选推荐草案提醒数据使用者：可以引用一个命题，却不能让引用在流转中悄悄变成发布者自己的断言。

一项服务是否达到标准，与监管者决定它必须做到什么，是两份不同的答卷。W3C九月版WCAG 3草案把这条界线写得更清楚，也让要求由谁选择、谁承担后果成为下一道治理题。

W3C 新发布的可验证凭证威胁模型草案，把风险从格式本身延伸到签发、钱包软件和核验方的实际决定。它列出问题，但并不替任何部署者完成控制。

网站可以要求用户为取得服务接受特定限制。W3C 技术架构组新修订的草案追问：代用户履行约定的软件，能否借此把其他数据和退出选择一并锁住？

W3C 新发布的研讨会报告提出把符合性测试延伸到政策处理软件。共同的机器可读文本仍不足以保证不同系统作出可比的判断。

W3C 新工作草案为可验证凭证设计了更精简的状态引用。节省凭证空间的同时，它把状态用途的选择明确留给验证方。

审阅者的赞成票、W3C 的授权公告、标准正文里的身份说明，本来是先后衔接的三件事。9 月 22 日更新的两份法语 WCAG 文档，把最后一步留在了前一步的措辞上。

一个知识库里的陈述，可能来自原始资料，也可能是规则运行后的产物。W3C 新发布的 SHACL 1.2 推理规则工作草案把这两类数据分开，却将“是哪条规则产生了结果”的记录留为可选项。真正要据此作决定的机构，不能让这个差别在系统交接时消失。

WebAuthn Level 4首份公开工作草案为远程桌面登录设计了一次精确的责任交接：本地浏览器在逐来源授权后，可以让本地认证器签署远程机器提供的客户端数据。但“本地允许调用”与“远端来源判断正确”是两件事，前者不能替后者留下证据。

2026年9月11日，W3C 宣布 Web Authentication Working Group 新章程获批并生效。真正需要被管理的，并不是一次简单的技术路线更新，而是一场参与资格、工作范围与知识产权承诺之间的制度交接。新章程开启了新的工作周期，也要求既有参与方重新确认其在扩展范围下的参与和 Patent Policy 承诺。未来两年的治理质量，将取决于能否清楚区分章程生效、宽限期参与、正式重新加入以及专利承诺更新这四种不同状态，并建立一套隐私安全的重新加入与承诺收据机制。

9 月 17 日，W3C 围绕出版维护工作组的拟议继任章程建立了五条横向审查线索。这是程序真正向前走了一步，却不是批准动作。现行章程仍有效至 2027 年 2 月 5 日；新范围、新期限以及新的参与和专利承诺，仍停留在章程完善阶段。

W3C 咨询委员会在最新说明中写下了一条有分量的原则：不论是否使用大语言模型，分享内容的人都要对成果负责。但同一份文件的状态说明也划出边界：这是咨询委员会认可的 Group Note，既没有得到 W3C 整体背书，也没有得到 W3C 成员背书。个人责任与组织问责之间，还缺一份能说明谁有权制定规则、谁完成核验、错误如何纠正的证据记录。

iPhone 用户已经可以把部分 Safari 数据导出，再交给另一款浏览器导入。这是一条真实但边界清楚的产品路径。9 月 15 日启动的 W3C 浏览器数据可携带社区组则处在另一层：它可以组织讨论、凝聚原则，并可能发布社区组报告；它尚未因此拥有标准、法律、厂商承诺或互操作测试的权威。把这几层分开，正是判断这个新小组价值的起点。

HTTP/2 Rapid Reset 暴露的并不只是一个实现漏洞，而是一条跨越标准、厂商与运营者的责任链：协议允许的行为如何转化为资源耗尽风险，谁发现并推动了问题升级，修复如何进入规范与产品发布，以及什么证据才能证明暴露面真正收敛。

IETF-W3C 这个目录标签指向的是一段可被文件证明的协调历史，而不是一个已经被公开证据证明的统一组织。要判断谁拥有权力、谁承担责任以及应向哪里提出异议，必须把备忘录、RFC 和当前联络记录拆开阅读。

TLS 重协商的历史说明了一个经常被忽略的安全边界：标准可以修复协议中的密码学缺陷，却不能单凭标准文本证明所有终端、库、设备和内部链路已经完成迁移。RFC 5746 重新绑定了重协商握手，TLS 1.3 则取消了重协商；真正的风险收尾仍取决于对遗留部署面的逐一验证。

把 IETF 与 W3C 并列书写，容易让人误以为二者只是承担相似职能的两个标准组织。但它们的权力来源、决策程序、法律安排和争议救济并不相同。对网络运营商、参与者和机构决策者而言，真正重要的问题不是谁发布了 RFC 或 Recommendation，而是哪一份制度文件赋予了具体权力，以及不服决定的人能够向谁提出挑战。

IETF标准并不直接运营网络，但它们规定了网络必须共同实现的状态机：连接如何迁移，路由如何发布和撤回，名称如何验证，故障后哪些状态能够恢复。标准一旦进入实现、运营和测量系统，连续性就不再由一个机构单独控制，而分散在协议实现者、网络运营商、验证器和观察基础设施之间。

匿名问卷的价值，恰恰在于回答可以尖锐，而不必变成指向回答者的线索。W3C新开放的会员问卷和广泛社区问卷都承诺回答匿名，却又在同一份表单中邀请有意参加访谈的人留下邮箱。现有公开材料不能证明邮箱已经与回答关联，也没有展示二者必然分离的机制。应当补上的不是猜测，而是一份简短、可核验的分离说明。

W3C 新发布的 WebAuthn Level 3 推荐标准链接了一份固定测试报告，表格里有四款浏览器。最终过渡记录又特意说明，Chrome 与 Edge 的实现“有一部分不同”。这句提醒很重要，却没有回答最关键的问题：到底是哪项功能、哪一层实现、哪份证据构成了独立性判断？

W3C 于 8 月 11 日更新《ARIA in HTML》推荐标准，并在首页链接一份公开实施报告。报告称最后更新于 2026 年 3 月 22 日；Git 历史却显示，文件在 5 月 20 日经历大幅改写，5 月 27 日又有变动。两组日期可以同时真实，但它们分别回答“证据截至何时”和“文档何时修改”，不应挤在同一个“最后更新”标签里。