摘要

  • RFC 9877 定义了 geofeed1 RDAP 一致性标识，以及用于 IP 网络对象的 rel=geofeed 链接。
  • 客户端应使用权威 RDAP bootstrap，识别最具体对象，并以有限方式检查父对象。
  • 前缀包含、HTTPS、可选 RPKI 签名、合理刷新和隐私审查都是边界控制，不是准确性保证。

RDAP 首先解决的是发现路径和登记责任。RFC 9224 的 bootstrap 可以把客户端引向负责该资源登记的权威服务。RFC 9082 所描述的查询通常返回覆盖目标地址的最具体网络对象。但相关 geofeed 链接可能挂在较不具体的父对象上，因此 RFC 9877 允许客户端进行有界的父对象遍历；这不是无限向上搜索的许可。

链接应使用 rel=geofeed 和 HTTPS href，并最好声明 type=application/geofeed+csv。注册的媒体类型有助于识别预期的 CSV 表示。一个对象可以没有链接，也可以有多个链接，通常是零个或一个；多个语言版本应使用 hreflang。这些字段说明怎样发现 feed，却没有证明 feed 的内容准确、完整、最新或在所有司法辖区都可合法使用。

最重要的约束是前缀包含。客户端使用发现的 feed 时，必须忽略地址范围超出承载该链接的 RDAP 网络对象范围的条目。只有完成这一检查，条目才可能参与服务定位、访问策略或分析。HTTPS 保护传输到端点的连接，但单凭 HTTPS 不能证明端点对每个前缀都有权威性，也不能认证文件中的每一行。若存在 RPKI 签名，它可以增加验证信号，却不会把地理声明变成确定事实。

RFC 9877 标准化的是发现和链接关系，不是数据抓取及使用策略。消费者需要自行制定接受、冲突处理和回退规则，并遵守刷新纪律，避免频繁进行实时 RDAP 查询。记录承载对象、范围、链接和获取时间，可以让使用决定可追溯；反复查询不会使陈旧数据自动变新。

隐私同样不可省略。即使 geofeed 描述的是网络范围，发布者也不应暴露个人位置。网络范围的精细程度以及与其他数据的组合都应接受隐私审查。上述 RFC 并未证明全球 RIR 部署、客户端普及、内容准确性、完整性或普遍法律许可。

来源