摘要

  • draft-wolf-dialogue-txt-00 是一份个人提交、拟定为 Informational 的 Internet-Draft，不是 RFC、已完成的 IANA 登记或部署证明。它建议发布者在 /.well-known/dialogue.txt 放置规范文件，允许陌生读者发一条初始消息；沉默后最多再提醒一次。
  • 这项许可只覆盖“谈话”。行动、访问系统、代表发布者、广告、监控以及要求对方回复都被明确排除。消息送达不建立通道，只有发布者的回复才建立草案所称的 bridge。
  • 企业不能把整条链压缩成一个“已同意”字段。发现、文件原文、解释规则、消息送达、发布者回复、后续轮次、独立行动授权与实际结果都需要各自的证据。

机器可读的许可有一种危险的视觉效果。字段整齐，布尔值明确，解析器返回成功，于是控制台上很容易出现一个绿色的“Consent”。从那一刻起，原本只覆盖一个动作的许可，会被下游系统当成对所有后续行为的总授权。

draft-wolf-dialogue-txt-00 的重要之处，在于它试图从格式内部阻止这种扩权。个人或机构在自己控制的域名上放置一个纯文本文件。任何读者都可以发现其中的联络渠道和主题，甚至读者可以是此前没有任何关系的软件系统。但文件说得很窄：你可以问，不能因此行动。

这不是代理任务接口，不是审批端点，也不是身份注册表。发布者只代表自己。读取文件没有副作用。额外能力不会产生额外权利。如果读者分不清“谈话”与“行动”，草案给出的默认选择不是猜测，而是不发送。

第一条消息只是在提议搭桥

读者可以通过列出的渠道发一条消息，主题或首行要带公开参考码，问题必须具体，并提供在自身进程结束后仍然有效的回复地址。它不能持续轮询，也不能让任务一直阻塞等待。达到发布者声明的等待期后，最多提醒一次，此后停止。

邮件服务器接受了消息，只能证明某个传输环节接收了数据。它不能证明收件人看见、理解或同意继续。沉默也不是异步审批。草案把状态变化留给了发布者：只有他的回复，才建立对话桥。

桥建立以后，范围仍然很小。每条消息一个问题，收到答案后再继续；任何一方都可以拒绝或结束。一封友好回复没有让发件人取得采购权、发布权、系统访问权、代表权或执行权。谈话通道与行动通道必须分离。

公开参考码不是凭证

文件要求发布者选择一个简短参考码。带有参考码的消息可以进入专门队列；没有参考码的消息可以被忽略。当参考码被采集并滥用时，发布者可以更换它。

但它是公开值，“知道”它不能证明任何身份。它不是共享密钥、承载令牌、数字签名或能力凭证。抓取程序、缓存和存档都能复制它。企业最多用它改善分流，绝不能据此跳过发件人识别、内容隔离、限速与授权检查。

域名本身也有同样的边界。HTTPS 能帮助读者确认响应来自预期网络源，却不能证明文件中的自然人是谁，也不能证明某位公司高管批准了内容。草案明确承认，除了域控制之外没有进一步认证。域名账户被攻破、注册过期或产权变更，都会改变邀请的实际控制者。

规范源可以撤回，公开披露却难以收回

只有发布者域名上 canonical_url 指向的文件有效。其他地方的副本只是副本，不能授予当前许可。发布者可将 live 改为 false，或删除文件，撤回新的联系邀请。

然而，爬虫和互联网存档仍可能长期保留姓名、渠道和旧参考码。也就是说，许可可以撤回，披露却可能永久存在。证据系统必须同时处理两条时间线：历史副本可以说明某次旧消息为何在当时合理，却不能给今天的新消息续期。

每次首次联系都应记录规范 URL、抓取时间、重定向链、域与传输检查结果、文件哈希和解释器版本。缓存必须有明确的新鲜度上限。否则，读者实际上把发布者的临时许可变成了自己决定期限的长期授权。

“众所周知的位置”只解决在哪里找

RFC 8615 规范 /.well-known/ 路径，使应用能在可预测的位置寻找站点元数据。它解决发现成本，并不保证内容真实。RFC 9116 的 security.txt 提供了更成熟的对照：规范要求注意被篡改的文件、恶意重定向和陈旧联系方式，也明确指出该文件本身不授予安全测试许可。

能找到报告渠道，与被允许实施测试，是两件事。dialogue.txt 把这条经验写进固定值：talk 为 true，act、access_systems 与 represent_author 为 false。未知字段忽略；重复或冲突时选择更窄解释；扩展可以缩小邀请，不能扩大邀请。

草案还请求 IANA 登记 dialogue.txt 和 JSON 镜像。研究时，这仍然只是 revision 00 内的请求。Datatracker 状态、文档历史、草案正文、IANA 注册表快照和实际部署，必须逐项验证，不能相互代替。

单个读者受限，不代表总负载受限

一个合规读者最多发送一条消息和一次提醒。一万个合规读者仍可带来两万封邮件。参考码能过滤没有读过文件的部分噪音，却挡不住读完规则后选择无视规则的程序。

因此，发布者需要专用邮箱、附件隔离、聚合限速、人工速度的处理队列和快速撤回能力。主题只是一块“擅长回答什么”的门牌，不是访问控制。若团队只能处理极窄范围，就不能把执行性约束寄托在标签上。

隐私风险也不只在发布者一侧。来信可能暴露发件人的姓名、机构、研究意图和长期回复地址。RFC 6973 所要求的数据最小化与用户参与，在这里意味着只收集回答一次问询所需的数据、禁止公开联络日志，并在开门前确定保存期限与访问者。

不要建立“总同意”，要建立证据链

至少需要八类收据：从哪个规范地址发现；当时的文件字节与状态；解析器如何采取更窄解释；发出的消息与渠道回执；发布者哪一条回复建立了桥；桥上的问题、答案与拒绝；哪一个独立主体在何种范围和期限内授权行动；最后实际系统发生了什么。

这些收据由不同主体控制。网站管理员控制公开文件，通信系统控制送达，发布者控制回复，应用所有者控制操作授权，运行中的系统才产生结果。把它们合成一个绿色字段，会让责任和时间全部消失。

Lu Heng 关于最小初始规范、本地化未来决策与自愿采用的原则提供了准确约束：协调文件只应说明最低限度的共同规则；未来现实来自参与者真正的回复、采用、授权与运行，而不是文件发布这一动作本身。

若按这个窄边界实施，dialogue.txt 的价值不是给机器更多权力，而是使机器在发现邀请时仍能知道自己的权力到哪里结束。