摘要

  • ECRIT 活跃草案为 LoST 增加有序的计划变更轮询、指定时间的 asOf 验证，以及 revalidateAfter 复验建议。客户端可以据此筛出可能受影响的记录并提前准备替换项。
  • 草案明确指出，在不同时间发出相同的未来 asOf 查询，结果可能不同。服务器回答的是查询当下对未来的认识，并不保证未来映射不变，更不能证明客户端已完成切换。
  • 文章建议把准备阶段和生效阶段写成相互关联、彼此独立的两份验证凭据。这是 Daniel Kade 的编辑性方案，不是 IETF 要求，也不代表该机制已经部署。

同一个门牌位置，两套时间状态

草案采用市政兼并作为典型情形。某片区域在变更前不属于一座城市，地址里的相应行政层级可能为空或填写其他值；生效之后，同一地点需要写入新城市名称。街道改名或重新编号也会产生类似效果。

《计划变更前后的位置验证》第 18 版目前是一份 ECRIT 活跃 Internet-Draft。它仍是进行中的标准工作，不是 RFC；公开文本也不能证明任何运营商已经采用，更不能证明现实中发生过某次失败。

RFC 5222 定义了 LoST。客户端提供位置与服务标识，服务器返回对应服务的 URI 及相关信息。客户端还可以要求验证民用地址的组成部分，服务器说明哪些部分有效、被忽略或无效。RFC 5139 提供了草案示例所依赖的民用位置格式。

如果没有计划变更通知，持有大量位置记录的客户端只能周期性重验整个数据库。周期太长会错过生效点，太短则给双方带来负载。草案的目标，是让服务器指出可能变化的范围，并让客户端在生效之前测试新记录。

这里最容易被遗漏的是证据时态。周一为周五发出的查询，不会产生周五的观测。它只会产生一份周一形成、面向周五的判断。

三只时钟各有职责

第一只时钟属于计划变更序列。独立的 REST/JSON 接口提供版本查询、轮询和 ChangeSet 获取。ChangeSet 包含有序标识、生效时间和部分位置。客户端保存上次收到的标识，下次请求它之后的新增项。

第二只时钟属于 asOf。客户端可以在 findService 中指定日期和时区，要求服务器按照该时点验证位置。服务器返回的是它在查询时刻所知、预计届时生效的状态。如果响应针对的不是当前时间，就必须回显 asOf，其中的映射也必须标为 NO-CACHE。

第三只时钟属于复验。revalidateAfter 告诉客户端何时可以考虑再次验证。NO-EXPIRATION 的含义很克制：服务器目前不知道会影响结果的计划变更，因此没有建议具体复验时间。它不是永久有效承诺。

三者分别回答“序列里有什么新通知”“现在看来未来会怎样”“何时值得再问”。它们都不回答“行政行为已经如期完成”“本地数据库已经执行”“当前服务映射不会再变”或“紧急通信已经送达”。

如果控制台把三只时钟压成一个绿色“已验证”，就会制造虚假的权力集中。服务器只发布自己掌握的数据，却在界面上被描述成替客户端的执行结果背书。

部分位置只是候选选择器

服务器无需枚举每一个完整门牌。草案定义的部分位置由名称空间、元素名和值组成。客户端用这些字段与本地记录比较；所有给出的字段都匹配时，该记录“可能受影响”。未给出的字段不参与判断。

因此，一个选择器可以覆盖某个行政分区内的所有街道，也可以覆盖一条街而不列出全部门牌。它解决的是怎样缩小检查范围，并没有直接决定每条记录的最终内容。

“可能”必须进入审计记录。客户端需要保存 ChangeSet、本地数据库快照、匹配规则、候选记录、排除项和人工例外。只保留“受影响 432 条”这样的汇总数字，会让后续人员无法判断差异究竟来自边界变化、数据修正、模式解释还是过滤错误。

这正是薄协调与本地决定的分工。共同层负责传播可互操作的字段与顺序，本地运营者负责将其转化为自身运行状态。Lu Heng 关于最小初始规范、本地化未来决定与自愿采用的论述，为这种分工提供了治理尺度：共同规则应严格而有限，不能顺势接管参与者之后的每一次选择。

可修正的未来比早到的确定性更可靠

草案第 4 节直接说明：服务器随时可能得知新的计划内或计划外变更。两个在不同日期发出的查询，即使使用相同的未来 asOf，也可能得到不同结果。服务器不保证同一位置下一次查询仍然相同。

这不是协议缺陷，而是知识变化的诚实表示。兼并可能延期，街道清单可能修订，数据源可能迟到，另一项变更可能抢先生效。如果早期预测不能调整，系统维护的是工单一致性，而不是现实一致性。

NO-CACHE 将这种克制写进协议行为。草案还要求，客户端在真正需要联系某项服务时，仍应当时使用 LoST。未来验证用于准备位置数据，不能替代当下的服务解析。

ECRIT 工作组章程关注利用位置和路由信息，使用户与相应的紧急响应中心通信；它还要求方案跨区域、跨司法辖区可用，并允许一个辖区内存在独立委派，而非依赖单一中央权威。因此必须防止两种跳跃：地址验证不是端到端通信成功证明，一个服务器的计划状态也不是所有独立客户端的执行证明。

Lu Heng 强调的“现实而非倡议才是产品”要求把句子说完整：哪个服务器，在什么查询时刻，针对哪个未来时间，返回了什么。只有实际生效后的另一份观测，才有资格回答后半句。

有序序列也会失去开头

草案预计客户端每隔数分钟轮询一次。正常情况下，客户端携带上次的 ChangeSet 标识；没有新标识返回时，只能说明该标识是服务器当前所知序列的末端。

新客户端或遗失位置的客户端可以不带标识轮询，服务器会返回仍然保存的全部 ChangeSet。“仍然”是关键。草案并不要求永久保存，反而举例说明：变化少的服务区可能保留十二个月，变化频繁的地区可能只保留三个月。

停机超过保留窗口之后，服务器留下的序列可以完全有序，对该客户端却并不完整。正确状态不是“已同步”，而是“连续性未知”。客户端应当建立新的当前基线，记录缺口，并从新纪元继续跟踪。

空轮询同样不能证明过去的 ChangeSet 已被正确处理，也不能证明不存在计划外变更。它只证明客户端提交的标识与服务器当前清单之间的关系。

Lu Heng 在 The Policy Mirror 中区分账本和王座。这里也一样：尊重服务器记录的权威边界，不等于让它替没有观测过的下游动作作证。

把准备凭据和切换凭据分别保存

准备凭据应当包括服务器身份、接口版本、轮询时刻、前一个标识、新增标识与生效时间；还应保存部分位置、本地快照、匹配逻辑、候选数量、排除项和例外。验证部分要连接位置、服务、asOf、响应、revalidateAfter、缓存状态、时钟来源与草案版本。

切换凭据从实际操作开始：本地接受的生效时间、旧记录停用时刻、新记录启用时刻、当时的重新验证、与准备答案的差异、延期或失败项、回滚状态，以及关闭变更的责任主体。

“两阶段验证凭据”是本文提出的治理形式，不属于草案规定。位置数据库可能敏感，逐条证据可以放在受保护视图，公共视图只展示 ChangeSet 参考、时间范围、数量和未解决例外。摘要值可以绑定两种视图，却不能证明底层决定必然正确。

如果周五答案与周一不同，两份记录都应该留下。周一记录解释当时为何做出准备决定；周五记录说明实际遇到的状态。用后者覆盖前者会丢失历史，只保留前者则会否定现实。

复验间隔是一项成本分配决定

草案把复验周期描述为时效、服务器负载、底层数据稳定性和本地政策之间的平衡。它举例称，成熟稳定地区可能采用六个月以上，快速增长地区可能采用 20 至 30 天。这些数字是情境示例，不是全球服务等级。

服务器理解自身数据源和容量，客户端理解记录过期的代价。revalidateAfter 提供建议，而不替客户端承担风险。客户端可以偏离建议，但应当留下决定人、理由、适用范围和复审触发器。

过长间隔会让无效数据滞留；过密轮询又可能影响 LoST 服务器的其他处理，草案的安全考虑明确指出这种负担。新鲜度与可用性消耗同一份能力。治理不能靠一个神奇天数解决，只能把建议、选择和实际负载放在同一证据链里。

可以说什么，不能说什么

准备凭据可以证明某客户端在某时刻从某服务器取得某 ChangeSet，以特定规则筛选本地快照，并得到一份未来验证结果。切换凭据可以证明该客户端后来启用了哪些记录，以及当时复验的结果。

两者相加，仍不能单独证明行政行为的法律效力、所有 LoST 服务器的数据一致性、服务映射之后未变，或某次紧急通信成功到达。那些结论需要处于相应层次的证据。

行政主体改变边界，LoST 服务器表达数据，客户端改变本地记录，当下查询返回当前服务，通信系统尝试交付。可靠治理不是寻找一个能代替所有动词的状态，而是让每个动词都带着自己的见证者。

来源