摘要

  • RIPE Database 查询页现在能查看并对比部分对象的旧版本；RIPE 93 的报告说，首批只覆盖少数对象类型。
  • 网页界面让既有历史更容易查到，却没有因此扩大记录的覆盖范围、保存周期或公开字段；官方指南仍未跟上。

一个对象页只告诉你现在是什么样。真正棘手的问题常在事后出现：这个字段何时变成现在这样？RIPE NCC 已把答案的一部分放到了查询页。搜索对象后点开版本历史，选择时间，再比较两版；这条路径不再需要用户先记住一串终端命令。

RIPE NCC 的十月会员更新把这项功能列为数据库进展。RIPE 93 的数据库工作组运行报告解释了界面现在可以列版本、查看指定版本并比较差异。我实际检查了 RIPE NCC 的 AS3333 查询结果：aut-num 对象下出现 Version History 按钮；打开后进入 Object History 页面，能选择日期、执行 Compare，并打开 XML 或 JSON。页面显示的最新版本时间为 2026 年 3 月 19 日。至少对这一类对象，新入口已经可用。

新的是入口，不是历史数据本身。数据库此前就保存旧版本；命令行客户端一直能列出和比较版本；RIPEstat 的数据库组件也早已通过历史 API 展示数据。RIPE 93 的报告说，查询页的第一版只支持少量对象类型，之后可以扩展。十月更新只写“部分对象”，没有公布清单。

更奇怪的是，官方说明文档还停留在旧路径。Historical Queries 页面仍说历史查询标记只能从命令行使用，网页查询和 REST API 都不支持。另一组官方 REST API 文档却列出版本列表和单个版本的接口；查询页现在又能直接打开 Object History。用户当然可以自己拼出完整路径，但说明书不该把找新功能变成一场考古。

这项变化的实际价值很清楚。网络工程师会核对登记对象中的持有人、资源描述和路由相关字段。若现在的值与昨天的材料不同，逐个保存响应、手工做 diff 很费时间。网页把当前对象、旧版和差异放在一处，减少了查证成本，也让更多需要核验的人能看见记录变化。

但差异页说明不了做决定的理由。公开版本元数据包含版本号、日期和操作类型。日期由数据库在处理更新时生成，并非提交者填写。文档中的版本记录没有提交人或变更理由字段。diff 能指出哪个属性发生变化，不能告诉读者为什么提交了这次变化。

这条历史还有明确边界。RIPE 的指南说，可查询的是仍然存在的运行对象，记录从最近一次创建或重新创建开始。对象若被删除后再建，公开历史覆盖新一轮生命周期并标出删除日期，却不会补回旧生命周期的完整链条。PERSON 和 ROLE 对象没有历史查询，含电子邮件地址的属性也会被过滤。这些是隐私和连续性的具体界线，不能等使用者把页面当成完整审计日志后才发现。

眼前缺的是对象类型清单。RIPE 93 只说首批支持很少。按钮出现，说明该结果有历史视图；按钮不出现时，公开资料没告诉用户这是类型不支持、没有可显示历史，还是另有条件。会员更新没列类型，历史查询指南仍把用户送回命令行。

RIPE NCC 应当用一页说明把查询界面、API 和证据边界接起来：公布支持的对象类型与上线日期；让查询页按钮链接到相应 API；说明按钮缺席代表什么；并在入口处解释时间戳、删除、重新创建和个人数据过滤规则。覆盖范围扩大时更新同一份说明。一个新按钮不该要求用户对照三份文档才能知道它能证明什么。

历史现在更容易看见了。官方操作指南还在让读者去别处找。

来源