摘要

  • RFC 5222 的 findServiceResponse 可以留下被采用的位置、映射来源与版本、有效期、服务边界、解析路径和联系 URI；这些字段共同证明映射发生过，却没有一个字段证明呼叫已经接通。
  • 协议没有掩饰降级状态：地址字段可能未检查，过期映射可以作为普通响应返回，默认映射和服务替代必须带警告，HTTP 200 也可能承载 LoST 错误。
  • 可靠运营必须保留一条可拼接但不可混同的证据链：位置从何而来、映射为何适用、缓存为何可复用、边界如何取得、会话是否建立、响应方是否接收、服务是否产生结果。

一次成功翻译，被写成了一次成功救援

先构造一个审计场景，而不是声称发生过真实事故。08:14:02，终端提交一份 civic 位置，请求 urn:service:sos.police，要求验证地址并索取服务边界。08:14:03，递归 LoST 解析器返回 SIP URI、locationUsed、一条 via 路径，以及 source、sourceId、lastUpdated、expires 四个关键属性。

08:14:04，监控面板显示“路由成功”。但到 08:14:20，记录里仍没有 SIP 会话建立、应答中心接受、媒体建立或现场服务的任何凭证。面板关于 XML 事务并没有说谎；它只是悄悄把“映射”换成了“送达”。

RFC 5222 的工作范围恰恰能阻止这种偷换。LoST 将位置与服务标识符翻译成一个或多个服务 URI，并返回与映射有关的信息。它不拥有后续信令，不控制目的端，也无法观察实际服务是否发生。

locationUsed 只回答“用了哪一份输入”

一条请求可以携带多个 location 元素。服务器选择自己能够处理的一项，并在响应中用 locationUsed 返回其 ID。这是有价值的因果记录：审计者知道哪份位置驱动了结果。

但它没有回答位置如何取得、观测发生在何时、误差有多大、设备此后是否移动，也没有证明位置属于当前呼叫者。RFC 4119、RFC 5139 与 RFC 5491 分别提供位置对象、civic 表示和 PIDF-LO 使用约束。RFC 5985、RFC 5986、RFC 6155 又把位置交付、本地 LIS 发现和设备身份拆成独立机制。

这些规范的分工说明了一个重要事实：格式正确不等于人在那里，选中输入也不等于输入真实。LoST 可以忠实地处理一份已经过时的位置；此时映射行为正确，运营结论仍可能错误。

civic 验证也有严格边界。客户端设置 validateLocation=true 后，服务器可把字段列入 valid、invalid 或 unchecked。valid 表示该字段被识别并用于计算；unchecked 表示未检查且未用于结果。字段互相矛盾时，本地策略决定取舍；选择 geodetic 输入时，civic 验证会被忽略。它验证的是映射键，而不是人的现实在场。

一张地图至少同时运行着四只钟

每个映射都必须包含 source、sourceId 和 lastUpdated。权威来源创建这些值，缓存不得修改。相同 source/sourceId 下出现更晚的 lastUpdated，接收方就有依据替换旧版本。

这是一套明确的版本凭证，却不是“世界最新”证明。lastUpdated 说明该来源何时更新这条映射，并不说明终端何时移动、DNS 何时改变、联系 URI 何时接受过最后一次会话，或应答机构何时调整过能力。

第四个时钟是 expires。它可以是绝对时间，也可以是 NO-CACHE 或 NO-EXPIRATION。RFC 5222 甚至允许服务器在别无选择时，以普通、非警告响应返回过期映射；客户端必须检查 expires 并按本地策略决定丢弃还是暂用。

空间又构成另一只钟：设备一旦越过服务区域，缓存即使尚未到期也应失效。因此，审计记录至少要保留位置观测时间、映射 lastUpdated、映射 expires、重用时的位置和会话尝试时间。用面板查询时间覆盖它们，会把“哪一层陈旧”这个最关键的问题抹掉。

NO-EXPIRATION 尤其容易被误读。它是一个映射有效期策略值，不是关于机构、网络、号码或服务永远不变的承诺。

边界引用不是边界本身

LoST 可以直接返回 serviceBoundary，也可以返回带来源和 key 的 serviceBoundaryReference。客户端可以表达偏好，但服务器决定给值、给引用还是省略。

若得到引用，客户端需要直接向所指权威服务器发出 getServiceBoundary；这一请求不递归。于是产生两个不同凭证：最初映射命名了哪条边界，以及后续请求实际取回了什么边界。

如果客户端从未解引用，就不能声称已经检验设备是否仍在区域内。如果取回了几何图形，却丢失 source/key、映射版本或比较时间，它只剩一块没有保管链的图形。RFC 5582 把这一机制放进更大的位置到 URL 架构中：边界给予的是有条件的复用范围，而不是永久管辖权。

path 能说明经过谁，不能替所有人背书

递归模式下，第一台 LoST 服务器代表请求者继续询问其他服务器；迭代模式下，它返回下一跳重定向。path 中的 via 项有助于定位循环、超时和警告来源。

这条路径仍不是全局信任证明。它没有自行证明 DHCP 或 DNS 发现结果可信、每一跳都检查了 TLS 身份、每个缓存都已经获得最新同步，也没有证明最终 URI 可达。

RFC 5223 定义 DHCP 发现 LoST 服务器；RFC 8917 为 LoST 验证服务增加独立发现标签；RFC 5069 讨论应急呼叫标记与映射的威胁。发现、传输身份、映射和验证必须衔接，正因为它们不能互相替代。

RFC 5222 要求实现 TLS，并建议实际使用和检查服务器身份，以降低查询篡改、冒充和缓存投毒。TLS 能保护双方交换的字节，却无法把错误位置变真，也无法让沉默的目的端接听。

HTTP 200 可能只是“成功送达了一个错误对象”

RFC 5222 规定所有 LoST 响应——包括 LoST 警告和错误——都通过 HTTP 2xx 承载，通常是 200 OK。因此 HTTP 成功只说明传输层完成，不能说明 XML 内是精确映射、默认映射、重定向还是错误。

locationValidationUnavailable 允许服务器返回映射，同时说明无法执行所请求的位置验证。serviceSubstitution 表明原服务 URN 被另一服务取代。defaultMappingReturned 则明确说明无法满足给定位置，只能返回一个默认 URI，例如附近的 PSAP。

默认映射可能是合理的降级选择。危险在于后续系统删除警告，把“附近的备用点”统计成“该位置的精确权威点”。一个运营上有价值的妥协，因状态丢失而变成错误承诺。

冻结的 RFC Editor 勘误页还列出两项 Verified、一项 Reported 和两项 Held for Document Update。Standards Track 表明标准地位，不表示文本从此不需要修正；勘误存在也不表示所有实现都错误。可审计的问题应是：实际运行的代码遵循了哪份文本和哪些修正。

后端同步的签名不能越级证明前端送达

RFC 6739 规定 LoST 节点之间如何同步映射。它沿用 source/sourceId/lastUpdated 指纹，禁止中间节点修改收到的映射，并要求权威映射服务器签署所分发的映射，防止不可信参与者冒领覆盖区域。

这为后端来源与完整性提供强证据，却没有证明某个客户端解析器已及时收到、安装并选用了最新版本，更没有证明返回 URI 后的会话完成。同步链、查询链和呼叫链是三条有关联但主体不同的链。

RFC 5031 用 URN 定义请求的是哪类服务；RFC 5012 给出应急上下文解析需求；RFC 6881 把终端与网络的应急呼叫实践纳入整体。URI 是“去哪里尝试”的答案，不是“已经有人接听”的收据。

把一句话拆回十二份证据

完整记录应当依次保存：位置来源与观测时间；被选位置 ID 和 profile；civic 字段验证结果；服务 URN；发现、DNS 与 TLS 身份；递归路径和重定向；source/sourceId/lastUpdated；expires、缓存年龄和移动判断；边界值或成功解引用；URI、服务号码和全部警告；下游会话结果；响应方接受与服务结果。

下一级没有凭证时，结论就应停在上一级。这不是降低 LoST 的价值，而是尊重它没有宣称控制的现实层。

Sources

  1. RFC 5222
  2. RFC 5222 Datatracker 文本
  3. RFC 5222 状态
  4. RFC 5222 历史
  5. RFC 5222 勘误
  6. RFC 5139
  7. RFC 4119
  8. RFC 5491
  9. RFC 5012
  10. RFC 5031
  11. RFC 5223
  12. RFC 6739
  13. RFC 6881
  14. RFC 5582
  15. RFC 5069
  16. RFC 8917
  17. RFC 5985
  18. RFC 5986
  19. RFC 6155
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption