Supersedes 如何分开修订与抹除

摘要

一份技术公告被发现有误，作者发布修订稿。两个新闻服务站都收到了新文章，也都让读者能够检索它。第一个站点验证撤回凭据后，把旧文章从本地服务中撤下；第二个站点没有通过验证，或者本地政策选择不执行，于是新旧两篇并存。

如果只问“修订稿是否发布”，两个站点的答案完全相同。如果问“旧稿是否还在”，答案却不同。Supersedes 的设计价值恰恰藏在这道分叉里：它没有让更正的传播依赖一次不可能保证的全网清理。

这也意味着“已被替代”不能自动解释为“已经不存在”。它可能只说明新旧身份之间建立了关系，也可能说明某个具体站点改变了展示或检索结果。范围必须说清楚。

RFC 1036 里的 cancel 控制文章通过 Message-ID 指定目标。收到请求的系统若具备撤销能力，就处理自己的那份副本。这里没有一个能直接写入所有服务器的中央账本；撤下从一开始就是分散执行的动作。

难点很快落到授权上。早期规则比较请求与目标文章的 Sender 或 From，也允许站点管理员处理。这个办法试图区分作者更正与恶意破坏，却难以在开放网络里提供强证明。伪造相似的地址，比证明自己真正控制原稿容易得多。

因此，cancel 的历史不应被讲成互联网早期的“删除键”。它更像一项由每个保管者分别判断的请求，而传播已经提前制造了许多保管者。

RFC 5536 把 Netnews Supersedes 的取值收得很窄：恰好一个被替代文章的 Message-ID。规范把它的效果描述为两步连续动作——先像 cancel 一样请求撤下目标，再把去掉 Supersedes 字段的新文章按普通文章处理。

这段表述划清了身份边界。修订稿不是钻进旧文章的存储位置修改正文，也不是沿用旧 Message-ID。它是另一篇文章，有自己的头部、传播路径和存储记录。字段只是把两篇不同身份的文章联系起来。

更关键的是，第二步并不以第一步成功为条件。即使旧稿仍被保留，修订稿也应照常处理。更正因此能够前进，而不是被一项无法跨越所有站点验证的撤回动作拖住。

RFC 5537 进一步说明，Supersedes 本身不是控制消息，但它要求撤下前稿的那一部分，要像 cancel 一样接受认证与授权。站点若决定执行，就采取与有效 cancel 相同的本地动作。

无论站点是否执行，新文章都要正常处理。这条规则防止两个结果被揉成一个布尔值：接受修订稿，不等于确认旧稿已经删除；保留旧稿，也不等于拒绝修订稿。

规范还保留了一段并不体面的现实：由于认证困难、滥用 cancel 的收益又很高，许多站点曾经干脆忽略 cancel 和 supersede 请求。发稿软件应阻止用户替代他人的文章，但请求离开客户端后，后续站点仍要独立判断证据。

RFC 8315 引入 Cancel-Lock 与 Cancel-Key。原文章可以携带锁值，后来发出的 cancel 或 superseding article 提供对应的键；站点通过推导与比较，判断请求者是否掌握与原稿相关的秘密。

相较于比较 From，这是一大进步。它把“看起来像同一个人”改造成可验证的知识证明，也降低了第三方随意撤掉文章的空间。

但密钥只回答认证问题，并不替各站点作政策决定。匹配成功不能让离线归档自动清除副本，不能追回网关导出的内容，也不能抹掉引用。实现该机制的站点获得了更好的判断依据，而不是获得了支配整个网络的权限。

Supersedes 这个名字还出现在邮件世界。RFC 2156 为 Internet Mail 与 X.400 的映射定义了一个可容纳一个或多个消息标识符的字段。RFC 5536 特意指出，Netnews 的单目标字段与它没有关联。

IANA 消息头字段注册表也把 mail 与 netnews 的 Supersedes 分列登记。名称相同，不代表邮件客户端、新闻服务器与归档系统共享同一种“召回”语义。

注册能够稳定字段名和规范出处，却不能证明今天有哪些服务实现了它，更不能证明某次请求已经从所有存储位置抹除内容。

Supersedes 没有许诺一个整洁的历史。读者可能同时看到两个版本，归档可能保留服务站点不再展示的旧稿，不同节点的检索结果也会分叉。运营者必须明确区分“建立替代关系”“不再默认展示”“从某个本地库撤下”和“在某个证据集合中确实不存在”。

这种不整洁却忠实于分布式网络。更正是一项新的公开事实，应该获得自己的身份和传播机会；撤回是一项涉及他人保管副本的请求，必须受限于证据与本地权限。修订稿能够继续向前，正因为协议没有假装它能把过去从所有地方叫回来。