摘要

  • terms.txt 第 00 版提出：网站可在交付前核验机器人签名、访问目的、用户授权和支付凭证，并为成功交付签发收据。
  • 签名证明的是“谁作出了这项声明、声明未被篡改”，收据证明的是“一份内容在一组条款下被交付”；两者都不能证明声明真实，也不能控制后续用途。
  • Daniel Kade 建议建立访问义务登记表，把交付前执行、交付后审计和合同义务分栏记录。这是编辑部建议，不是 IETF 要求。

先看这张只能用一次的收据

按照 terms.txt 第 00 版，一次合规请求得到内容时，源站会返回经过签名的 Access-Receipt。它可以包含请求签名的摘要、适用条款、响应状态和内容摘要，因此能回答一个很窄、但很有价值的问题：哪个代理标识在什么条款下，从哪个源站拿到了哪份表示形式。

这张收据只能对应一项签名请求。若共享缓存把同一响应交给第二个请求者，附带的仍是第一项请求的收据，源站也没有记录第二次交付。草案因此要求带收据的响应使用 Cache-Control: no-store，沿用 HTTP 缓存已有的控制语义；没有收据的普通响应不受这一规则影响。

这个取舍揭示了机制的尺度。逐请求归因与共享缓存效率并不天然兼容。以后若要支持可缓存交付，就需要另设收据取得路径或新的绑定办法，而不能把一张旧收据当成所有后续接收者的共同证明。

源站能够执行什么

RFC 9309 明确指出，robots.txt 的规则不是访问授权。它可以请爬虫避开某些路径，却不能验证运营者、区分实时问答与训练，也不能在交付前收取费用。新草案希望把条件放到由源站实际执行的边界上。

源站将按照知名 URI机制发布 /.well-known/terms.txt。每个路径区块可按用途决定允许、收费或拒绝，限定可复现内容的程度，并要求特定范围的用户授权。客户端则借助另一份 Web Bot Auth 工作组草案和 HTTP 消息签名，把 Access-Intent 连同完整目标 URI 纳入签名；必要时还要覆盖授权令牌和一次性支付凭证。

在内容离开之前，源站可核验签名密钥、时间窗口、重放随机数、声明完整性、授权对象与范围、条款版本，以及支付凭证是否有效且尚未使用。它有权据此交付或拒绝。这一层属于可执行事实。

拒绝也被刻意限制在现有 HTTP 语义内。草案选择状态码 403，再用 Problem Details区分签名失败、重放、用途不允许、授权不足或需要付款；它没有擅自定义 HTTP 语义仍保留的 402，也不在没有 WWW-Authenticate 的情况下使用 401。

交付以后，证据换了一种性质

草案把能力分为三层。第一层是交付前可执行的检查。第二层是事后可审计：机器人若声明用于搜索，后来公开产品却大量复现内容而不返回原站，签名声明和收据可以给争议提供起点。第三层属于合同或法律判断：HTTP 看不到内容随后进入了索引、摘要、训练集还是另一份副本。

因此，“签名有效”不能简写为“用途真实”。签名只说明某个已解析代理标识下的密钥持有人发出了声明。它也不能自动证明现实世界中是哪家公司控制该密钥；需要更高身份保证的源站仍要建立额外信任关系。

用户授权和支付也有相同的制度空白。草案规定令牌如何绑定受众、代理和范围，却不规定源站为何信任某个身份提供方；它规定凭证如何被消费，却把结算服务与各方的关系留在范围之外。消息格式互通，不等于中介天然获得裁判权。

还有一项容易被忽略的运行风险：terms.txt 只要解析失败，整个文件都视为不存在。条款发布者必须保留版本、先行验证、原子替换并从外部复核。否则一个格式错误就会让对外可见的治理状态从“有条件”跳成“无条款”。

这还不是 IETF 的决定

Datatracker 页面把该文档列为个人互联网草案，没有标准流程归属，也没有 IETF 正式地位。历史记录显示第 00 版于 2026 年 9 月 11 日人工发布。它尚未被工作组采纳，没有负责的区域主管、IESG 批准或 RFC 编号。

文档页眉写着目标为 Standards Track，而 Datatracker 的预期 RFC 状态仍为空。这只能说明作者希望前往哪里，不能说明流程已经到达那里。与之相邻的 AI 用途偏好词汇和将偏好附着于 HTTP 内容的草案属于各自工作组；它们的流程地位不能借给 terms.txt。

运行代码同样需要准确表述。草案列出一个 JavaScript 参考实现、24 项检查和若干耗时数据，同时明确承认 v0.1 早于当前文本，在目标绑定、HTTP 状态码、令牌格式、代理标识、收据字段、支付表示、缓存和链接关系上都有差异。这证明附近的设计曾经运行，不证明当前第 00 版已经实现或跨实现互通。

建一张访问义务登记表

Daniel Kade 建议由各源站本地维护一张访问义务登记表。每行记录源站和路径范围、条款编号与摘要、声明用途和复现级别、代理标识及身份保证上限、授权签发方与范围、支付凭证权威、交付前决定、响应与内容摘要、收据编号、事后观察、合同义务、争议负责人、到期、撤销和后继条款。

这张表不追求全知，而是防止有限证明被包装成全面合规。Heng Lu 的《政策之镜》要求把证据与决定的分界照出来；“最小初始规范”强调共享层应足够小，让未来决定留在本地；关于 BTW Media 的文章则给出报道纪律：提案本身是新闻，提案做不到什么也是新闻。

来源

  1. terms.txt Datatracker 页面
  2. terms.txt 历史记录
  3. terms.txt 第 00 版
  4. Web Bot Auth HTTP 消息签名草案
  5. AI 用途偏好词汇草案
  6. AI 偏好 HTTP 附着草案
  7. RFC 9309：机器人排除协议
  8. RFC 9421：HTTP 消息签名
  9. RFC 9457：HTTP API 问题详情
  10. RFC 9110：HTTP 语义
  11. RFC 9111：HTTP 缓存
  12. RFC 8615：知名 URI
  13. RFC 8126：IANA 注册指南
  14. The Policy Mirror
  15. Minimum Initial Specification
  16. Why BTW Media Exists