摘要

  • checkgroups 正文必须完整列出其范围内的新闻组，并可携带说明与审核状态；因此，范围内没有出现的组名可以构成删除请求，而不只是未知缺口。
  • chkscope 用纳入和排除前缀划定快照边界，chksernr 则随清单变化单调递增，帮助服务器挡住迟到或重放的旧版本。
  • 完整、定界和更新都不等于授权。媒体类型不提供授权信息，任何 Netnews 代理都可以依本地认证和策略拒绝执行或保留明确例外。

一条没有出现的组名

设想某个层级在两台服务器上都保有四个组。新到的控制文章只列出三个，而且声明这就是所覆盖层级的完整清单；它还排除了一条另行维护的子层级，并带有比上次更大的序号。

第一位管理员确认发布者有权管理该层级，把第四个本地组送入复核并最终停用。第二位管理员确认的是同一个发布者，却因本地用户仍依赖该组而把它标成例外继续保留。两边都不触碰被排除的分支。几天后，一份序号较小的旧清单从慢路径抵达，两台服务器都拒绝倒退。

这里的关键不在于谁“同步成功”，而在于同一份证据产生了可解释的不同结果。清单把请求说清楚，却没有取得远端目录的所有权。

早期机制本来就是本地对照

RFC 1036 对 checkgroups 的描述非常直接：正文包含正式的新闻组及其说明清单；主机将它与自己当前承载的组比较，把新增或过时项目报告给本地 Usenet 管理员，并据此更新本地说明。

这个流程天然分成三层：网络带来的参考清单、某台主机当时的实际目录、管理员随后作出的处理。标准没有假设存在一张能瞬间改写所有节点的中央表。

正因为状态可能分叉，对账才有价值。清单中有而本地没有的组，是待评估的新增项；本地有而清单没有的组，是待评估的过时项；名称相同而说明不同，则是元数据漂移。每一种差异都需要本地解释，而不是自动证明全网发生了某件事。

完整性让沉默具有含义

RFC 5537 进一步规定，接收方若接受 checkgroups，应让清单中的组存在，移除所代表层级中未列出的组，并使说明和审核状态与正文一致。要让“未列出即请求移除”成立，正文必须覆盖其所代表层级的全部组，不能只发送局部片段。

这项约束看似严格，实则是在防止误删。增量通知只说明哪些项目发生变化，没有出现的项目通常保持原样；完整快照则同时声明哪些项目不在集合里。把增量误当快照，会把沉默当删除命令；把快照误当松散建议，又无法可靠清理过时项目。

因此，完整性不是篇幅要求，而是一种负面证据契约。只有发送者承诺不遗漏，接收方才能安全解释缺席。

范围决定缺席在哪儿有效

新闻组层级可能包含由另一方维护的分支。chkscope 为此提供纳入和排除规则：普通前缀指定纳入范围，带感叹号的前缀指定排除范围；计算时先纳入、后排除，不受书写顺序影响。

于是，一份清单可以表达“对这棵层级做完整对账，但不要推断那条子树”。在有效范围内，缺席具有删除含义；在范围外，同样的缺席不说明任何事。正文还应避免夹带范围外的组，因为旧软件可能不理解 chkscope，从而错误处理本不该触及的名字。

保存证据时，如果只留正文、不留有效范围，就等于丢掉解释缺席所需的边界。目录对账的最小证据单位不是名称列表，而是列表加范围。

递增序号抵挡旧状态回流

chksernr 是正值，清单每次改变都必须增大，不能下降；同一范围的后续清单继续携带新值。服务器记住自己已经接受的序号后，应拒绝更小的序号，也应谨慎拒绝没有序号的后续清单。

它不是全球时间戳，也不声称给整个 Netnews 排序。它只给同一范围的一系列完整快照建立前后关系。控制文章可能延迟、绕路或被重放；序号让已经采用新版的服务器不至于被旧副本悄悄拉回过去。

标准甚至不为序号设置固定数值上限，只受头字段总长度约束，并提醒实现不要假设它能装进机器的原生整数。这一点防止了一个长寿目录被短寿数据类型截断。

格式主动承认自己不负责授权

IANA 登记的 application/news-checkgroups 描述了组名、说明和审核标记如何编码。登记同时明确指出：该媒体类型不含授权信息，授权必须从其他机制获得。

这句否定非常重要。一份语法正确、内容完整、序号最新的清单仍可能来自无权管理该层级的人。反过来，即便发布者可信，服务器也可以选择人工复核、保留本地例外或完全不执行。

RFC 5537 要求组控制文章带有 Approved，但这个字段只是审批归属，不会自动证明该身份对某台服务器具有管理权。每个代理仍须采用自己的认证和授权安排，而且没有任何 Netnews 代理被强制执行控制消息。

查询结果只说明被查询的服务器

RFC 3977 定义的 LIST ACTIVE 会返回某台服务器已知的组及其状态。这是本地库存观察，不是层级权威快照，更不是其他服务器已经执行同一控制文章的证明。

把它与可信的 checkgroups 正文比较，可以找出少项、多项以及审核状态差异，却不能单靠差异解释原因。服务器可能拒绝了消息、保留了例外、处在人工复核中，或者相关名称其实落在排除范围。

因此，准确说法应落到具体对象和时间：“这份范围明确的清单请求移除某组，而这台服务器仍在提供它。”笼统说“该层级已经删除”会把请求、本地执行和全网状态混成一个不存在的事实。

注册的是协议工具，不是目录主人

RFC 5536 把控制文章定义为除普通存储和转发之外还请求动作的文章。IANA 消息头字段注册表 将 Control 记为永久字段；媒体类型注册则稳定了专用正文的解释方式。

这些注册让不同实现能够识别同一种工具，但不会列出所有新闻组、任命每个层级的管理者、认证审批者，或记录各服务器是否执行。标准化回答“如何表达”，没有替各节点回答“由谁决定”。

对账无需虚构中央所有者

checkgroups 的历史价值，在于它把四种容易混淆的属性拆开：完整性决定遗漏是否有含义；范围决定含义在哪里成立；序号决定哪个版本更新；授权和执行决定本地目录是否改变。

拆开以后，分歧不再只能被叫作“不同步”。一台服务器可以证明自己依据哪个快照删除了项目，另一台可以证明自己有意保留了哪个例外。两者对请求的理解一致，对自身目录的治理选择不同。

分布式协调并不一定要把所有副本变成同一副本。它更需要一种可审计的语言：清楚描述整套集合，同时不冒充集合的所有者。

来源