摘要

  • RFC 5139 用更丰富的 XML 市政地址格式取代 RFC 4119 的原始形式，并吸收 RFC 4776 的 DHCP 地址类型。
  • 主路、路段、支路、次支路、建筑、单元、房间和座位等字段能保留扁平字符串会丢失的地方差异。
  • 模式验证只证明一份地址陈述符合表示合同，不证明人或设备此刻在该处。
  • 多语言形式应放在独立地址块中；语言偏好能选择显示，却不能裁决互相冲突的事实。
  • XML token 会折叠普通空白，因此原始文档与应用拿到的值是两张不同收据。
  • 把市政与地理位置拼成一个复合位置之前，必须证明来源、时间和确定方法一致。
  • 字段越多不代表越新：静态名录可能详细而陈旧，刚测得的网络位置可能粗略却当前。
  • 签名能确认陈述者，不会自动让地址内容准确。
  • 市政精度对应一个不确定区域；房间或座位字段也不证明实际占用。
  • PIDF-LO 的接收者、用途、保留、转发和精度缩减规则独立于地址语法。
  • LoST 验证与 SIP 传递证明的是路由阶段，不是呼叫受理、派遣或到达结果。
  • 领导层应保存从观察、授权、映射到现场结果的分层证据，禁止用一个“有效”状态吞掉未知和冲突。

最容易误导人的，是最细的字段

一个只有城市的地址看起来不确定，操作者会主动核实。一个写到房间和座位的对象却容易被当作事实。细节制造了心理上的现场感，但细节可能来自员工名录、安装记录、用户输入或长期缓存。目标早已移动，字段仍可全部有效。

RFC 5139 解决的是表示损失。不同国家的道路结构并不总能压成“街道+门牌号”。规范加入 RD、RDSEC、RDBR 与 RDSUBBR，因为同一个号码可在多个路段重复，同名小路也可能只有通过所连接的主路才能区分。HNO 属于所提供的最具体道路层级；主路方向词不能随意套到支路；旧的 A6 不再兼任街名。

这类规则让接收方按同一层级解释数据，却不验证数据真假。错误门牌号仍可被放在正确元素里。两套本地资料也可能按不同国家规则组织同一地址。两位大写国家代码限制格式，不证明目标在该国。

运行证据必须保留字段顺序、模式版本、国家配置、扩展元素以及未识别信息。地理编码器若只返回一项，还要记录候选数量、归一化了哪些字段、使用哪一版资料。数据库命中唯一一行，只能证明索引选择唯一，不能证明物理地点唯一。

语言匹配不是事实仲裁

除 country 与语言中立的 PLC 外，RFC 5139 允许地址元素使用 xml:lang。书写系统可进入语言标签的 script 子标签。每个 civicAddress 应使用一种语言或一致组合，同一地点的不同语言形式应作为同一 tuple 中的多个地址块存在。

从 RFC 4776 转换时会暴露结构差异：DHCP 形式可按语言或文字重复同一元素，XML 地址块中每个元素只有一次。转换因此可能为每种语言建立一个块，并复制语言中立值。

已知接收者偏好时，可以按语言权重选择值。但权重相同、没有匹配偏好，或同一语言出现冲突值时，规范允许任意选择。任意选择是保持互操作的退路，不是“真值已确定”。

日志若只保存胜出文本，就会抹去冲突。系统应记录全部候选、语言标签、偏好列表、权重与选择原因。RFC 5646 规定怎样标记语言与文字，不证明两个名称一定指向同一地点。等价关系需要本地权威、稳定地点标识或人工核验。

解析器已经改变了输入

RFC 5139 的市政值以 XML Schema token 为基础。普通空白会被归一化和折叠，多行或多空格写法可能在应用层变成同一个值；需要保留的空格可以用字符引用表达。

因此，原始字节、XML 文档、解析树和值库中的字符串并不是同一对象。原文签名不能自动证明应用实际比较的值；应用日志也不能还原所有原始细节。

模式还接受其他命名空间的扩展元素及任意属性。开放性有利于演进，却意味着两个都能通过验证的实现可能理解不同信息。关键系统应保存不可变原文、解析器与模式版本、结果值、未知扩展、警告和丢弃字段。单独显示“模式有效”会把转换边界藏起来。

地址必须带着观察故事

RFC 5491 区分目标、来源、位置确定方法和传送位置的配置协议。设备位置也不天然等于持有人的位置。手工填写、DHCP 配置、位置服务器与公司名录拥有不同证据权力和不同寿命。

市政与地理描述若要组成一个复合位置，应当具有共同来源、共同时间和共同确定方法。把静态名录里的房间号加到刚测得的网络区域上，会让结果表面更精确，实际却可能更错。

收据至少应绑定目标标识、来源、方法、采集接口、观察时间、签发时间和到期时间。RFC 7378 进一步说明：认证可以确认哪一来源作出陈述，但真实来源仍可能判断错误、被攻陷，或描述了另一个目标。来源可追责，不等于内容为真。

完整度与新鲜度没有必然关系。组织应让“当前”这个词只能由仍在有效期内的观察来授权，而不能由字段数量授权。

精度、置信与新鲜度是三条轴

RFC 7459 把位置视为估计。自动取得的市政地址，其不确定范围与最精确可信元素覆盖的区域有关。建筑小于城市，房间小于建筑，但房间仍是区域；座位名称也不证明有人坐在那里。

缺少细节可能因为未知、无关或隐私策略主动删减。缺少不确定性信息绝不代表不确定性为零。精度讲“陈述有多细”，置信讲“目标落在区域内的可能性”，新鲜度讲“陈述何时适用”。三者不能合并成一个分数。

地理编码又会产生新判断：它可能返回多个候选、中心点、入口、地块或屋顶。派生坐标必须与原地址、数据集版本、候选和歧义一同保留。由房间地址算出的点不是对房间的测量；落在建筑内的坐标也不能自动继承房间号。

IANA 的 CAtype 注册与 RFC 4589 的地点类型让字段具有共享含义；它们不认证具体值。RFC 6848 让扩展受控，也不使扩展内容自动可靠。

隐私规则决定可以看多少

PIDF-LO 不只是字段容器，还带有使用规则。RFC 6280 把目标、规则制定者、位置服务器和接收者分开。能解析楼层不代表有权看到楼层。

RFC 6772 允许按策略降低位置精度。来源知道房间，而接收者只得到城市，可能恰恰说明保护机制正常工作。下游再从其他数据库“补齐”房间，会绕过原来的授权。

授权应包含接收者、目的、精度、保留期限、再传递与撤销。地址中的国家表示被描述地点，不表示数据存储地、处理地或适用法域。把对象地理位置当作数据主权标签，是又一次层级混淆。

不可逆风险来自复制。一旦精确位置进入工单、分析和备份，之后修改政策也很难召回所有副本。发布前最小化，比事后承诺删除更可靠。

映射成功之后，现实还没有结束

LoST 能用服务与位置映射服务 URI，也能给出市政验证结果。SIP 能携带或引用位置。它们应分别记录请求、验证警告、映射边界、返回 URI、到期时间、权限判断与传递结果。

正确映射不证明目标在地址处；位置传到端点，也不证明呼叫被正确受理、地址被正确理解、资源被派出或人员到达。每一步都有新的决策者与失败方式。

端到端测试应覆盖：完整但陈旧的地址、最近但粗略的位置、语言版本冲突、同名支路、被隐私策略隐藏的房间、多个编码候选、未获授权的接收者、过期映射，以及映射成功后的现场失败。系统只有在每层都准确表达所知与未知时才算通过。

RFC 5139 让第一层更少损失。成熟治理的标志，是不让这项进步越权替代后面的现实证据。

来源

  1. RFC 5139 HTML
  2. RFC 5139 纯文本
  3. RFC Editor 的 RFC 5139 记录
  4. IETF Datatracker 的 RFC 5139 记录
  5. RFC 5139 历史
  6. RFC 5139 勘误检索
  7. RFC 4119：PIDF-LO
  8. RFC 4776：DHCP 市政地址选项
  9. RFC 5491：PIDF-LO 使用说明
  10. RFC 7459：位置不确定性与置信
  11. RFC 7378：可信位置
  12. RFC 6280：互联网位置与隐私架构
  13. RFC 5222：LoST
  14. RFC 6442：SIP 中的位置传递
  15. RFC 6772：地理位置策略
  16. RFC 6848：市政位置扩展
  17. RFC 5646：语言标签
  18. RFC 4589：位置类型注册表
  19. IANA 市政地址类型注册表
  20. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  21. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  22. Running-Code Primary