摘要

  • RFC 5005 明确指出分页订阅源具有损失性；即便所有可见分页链接都返回成功，也不能证明得到了一致、完整的瞬时集合。
  • 归档关系只提供重建路线。遍历是否完成、怎样处理重复与删除、保存了什么状态、向读者展示了什么，仍需分别取证。

一个决策看板显示：当前订阅文档可访问，prev-archive 能打开，本地已有数万条记录。于是“历史覆盖”被标成绿色。

这个绿色状态把四件事压成了一件事：发布者怎样描述订阅源，采集器实际走过哪些链接，本地怎样合并并保留结果，读者最后看到了什么。

RFC 5005 恰好提供了拆开它们的语言。完整订阅源由一个文档表示逻辑订阅源的全部条目。分页订阅源把内容分散在若干临时页面。归档订阅源以包含近期变化的订阅文档为入口，再以较稳定的归档文档承载较早条目。规范没有定义把这些类型混合使用时的语义。

分页模式的限制最直接。RFC 5005 称它是有损的：客户端翻页期间，条目可能被加入或修改，而且客户端不一定察觉。first、last、previous、next 只是导航关系，不是冻结屏障。全部请求都成功，也只证明若干次请求成功；客户端不应把结果宣称为连贯或完整。

归档模式给出更强的能力，却仍不是结果证明。prev-archive 指向紧邻的较早归档，next-archive 可以指向较新的归档，current 可以回到当前订阅文档。某个归档文档的内容和地址应当保持稳定，客户端才可以把已经抓取的归档视为已处理。

“应当稳定”并非“已经不可变”。这是协议建议，不是内容哈希，也不是外部见证。RFC 5005 提醒：如果发布者修改旧归档，有些客户端可能永远不知道。因此，需要让所有用户看见的重要修订，宜重新放入当前订阅文档。

重建还要求客户端真的行走这条链。它读取一个尚未处理的 prev-archive，合并其中条目，继续向前，直到遇到已经处理的链接、没有更早链接的链头，或者错误。发布者无须提供全部归档；403、404 与 410 都可能成为停止点。客户端也无须始终保存或重建全部内容，但不能在不完整时对用户保持沉默。

因此，“任务结束”至少包含四种不同状态：到达最早归档；到达此前验证过的锚点；因响应错误停止；因请求次数、存储或人工干预策略停止。把它们都写成 completed=true，等于主动丢掉证据边界。

重复条目又带来一层判断。规范建议采用更新时间较新的条目；时间相同或缺失时，优先级需要客户端决定。RFC 4287 定义 Atom 的标识、更新时间和链接结构，却不会替不同实现完成这项判断。RFC 6721 后来加入明确的删除条目元素，因为基础 Atom 本身无法告诉已经处理过某条目的客户端：该条目后来被移除了。

fh:complete 也不能越过层级。它是发布者对单个文档的声明：该文档包含逻辑订阅源的全部条目，未出现的条目不应被视为其中一部分。它并不证明缓存拿到最新字节、旧记录已清理、安全上下文一致、页面正确渲染，更不证明任何人读过或据此行动。

一份可辩护的重建凭证应记录：

  1. 当前订阅文档的身份、抓取时间与验证器；
  2. 声明的订阅源类型及实际观察到的关系图；
  3. 每个 IRI、重定向、响应、认证上下文和内容哈希；
  4. 遍历顺序、重试、资源上限与准确停止原因；
  5. 重复、同时间戳、无时间戳和删除标记的处理规则；
  6. 本地保留状态的修订号、时间截点与完整性状态；
  7. 实际向用户展示的不完整警告；
  8. 对读者可见结果的独立读回。

这是一项治理建议，不是 RFC 5005 暗藏的合规字段。它遵循 Heng Lu 对现实层的区分：表示、传输、物化状态与人的观察，必须由证据连接，不能因为字段方便而合并。

规范没有证明任何具体平台的归档稳定，也没有证明某个采集器完整遍历、某项删除真实发生或某位读者受到影响。两项已验证勘误分别修正示例 UUID，并明确 Atom 链接目标应称为 IRI；它们不改变上述证据边界。

领导层真正要问的是：这个观察者能够为截至什么时间的哪一段历史负责，在哪条边上停止，又把哪些不确定性诚实地留给读者？

来源