Summary

  • The query page now exposes history for selected objects. RIPE 93 described a small initial set, and its presenter said the view would simplify staff queries.
  • RIPE NCC has not named the supported types, while the official guide still describes historical queries as a command-line task.

The RIPE Database’s new Version History button solves the command-line trip on results where it appears. The official Historical Queries guide still describes the history flags as command-line-only and unavailable through the web query form or REST. RIPE NCC calls the objects “selected,” but has not said which types make the list.

RIPE NCC announced the page in its October Member Update. At RIPE 93, the Database team described list, show and diff views and said the initial support covered a small number of object types, with more easy to add. The presenter also said the page would simplify internal queries: staff had used a command-line equivalent to inspect history. That is a recorded use case for the change, not a claim about a particular member’s operation.

I checked the query result for AS3333 on 31 October 2026. The aut-num result showed Version History; Object History opened with a date selector, Compare, and XML and JSON links. The newest entry was version 104, processed on 19 March 2026. That is the Database’s processing timestamp, not the date of my check.

The stored history predates the page. RIPE’s command-line client could list and compare versions, and RIPEstat had a Database widget using the history API. The October change shortens the route from a current query to an older version. Separate REST documentation describes endpoints for listing and retrieving versions; Historical Queries says its flags do not work through the web form or REST. The public documents do not give users one current map of those routes.

The diff answers a narrow question: which attributes differ between two stored versions? RIPE’s version model records a revision, date and operation. The server sets the date when it processes an update; the public model has no field for the submitting actor or the reason. The comparison proves a change in recorded content, not the decision that produced it.

History also stops at defined boundaries. For existing operational objects, RIPE’s guide starts with the latest creation or recreation. When an object is deleted and recreated, the public trail records the deletion date and newer lifecycle, not the earlier one as a continuous history. PERSON and ROLE history is unavailable, and email-bearing attributes are filtered.

If the button is missing, public material does not say whether the type is unsupported, the object has no history, or another condition applies. A current support list would tell users what a result proves and what the absence of the control means. The web route is real; its scope remains unpublished.

Sources