Summary

  • Whois 1.124 added plain-text and unformatted Versions API responses. RIPE NCC’s documentation dates production deployment to 27 August 2026; this is a September examination of that feature.
  • The selected historical object is filtered before it reaches either output branch. The plain-text body bypasses the structured branch’s explicit revision field, so a saved text file is neither a self-contained revision receipt nor an archive of the original update request.

A historical object saved as a text file looks reassuringly complete. The key is visible, the attributes are readable, and a colleague can compare it without an XML or JSON wrapper. But one piece of information may have remained in the request that produced the file: which revision was selected.

This is a hypothetical filing problem, not a reported mistake by a RIPE Database user. It explains why a useful new representation deserves a precise description. Plain text can simplify reading without carrying everything that identified the response.

Whois 1.124 lists two additions to the Versions API: text/plain responses and unformatted responses. The official documentation records release-candidate deployment on 13 August and production deployment on 27 August. Its version-specific endpoint includes source, object type, key and requested version number. This September review follows the corresponding published source at 9095208c158c9d6630e6b1eac33e845d2c537d3d. It is not a test of every present installation.

The history is curated before it is printed

In the reviewed service, the version request selects an object type and uses SHOW_VERSION for the requested number. The query runs through the REST-origin query path and returns a VersionWithRpslResponseObject.

That object is not an archived HTTP or email submission. The historical query executor first applies its filtering functions for email, authentication, changed and personal-data attributes to the RpslObject. Only then does it wrap the object with the requested historical revision.

The distinction is structural. A different output format does not send the query back to an unfiltered original transaction. Nor does invoking a filter prove that every field of every object changes. Some visible RPSL text might happen to match text previously submitted. The API still supplies a processed historical object, not a guarantee of original-request identity.

This is a reasonable boundary. Making historical records useful does not require republishing authentication material or personal data that the history service filters. An investigator’s desire for a readable record is not a reason to undo those protections.

One response body keeps less of the envelope

The service then reads the Accept header. If it contains text/plain, the handler returns the historical RpslObject’s string representation and leaves the method at that point.

The other branch continues into the structured mapper. It passes the unformatted parameter’s interpreted setting to the server-side object mapper, sets the resulting WhoisObject’s historical version, and places it inside WhoisResources. That outer response also carries software-version, error and terms information.

The revision assignment therefore belongs to the structured branch. The plain-text branch does not execute it. Similarly, the unformatted mapper invocation is after the early plain-text return; it should not be described as a switch that retrieves original submissions in every media type.

This is a claim about the reviewed body-producing path. It is not an audit of every HTTP header, interceptor or proxy. The request URI still identifies the selected revision. Ordinary object fields or user-written remarks can also contain dates and other identifying text. They are not substitutes for assuming that the structured revision field is present in a detached plain-text body.

A software release number and an object’s historical revision answer different questions. One identifies the service’s code; the other identifies the requested position in an object’s history. A capture that preserves one should not silently stand in for the other.

Keep readability and identity together

Plain text has a strong practical case. It is easy to inspect, save and compare in existing tools. A structured response adds an envelope that those tools may find inconvenient. Neither representation is inherently the wrong choice.

The filing decision is what to keep alongside it. Preserve the exact request URI, source, object type, key and requested revision; record the response representation and capture time. Keep response headers and the structured historical revision when they are available. Hash the actual captured body, while noting which representation was hashed.

A body hash can show that captured bytes have not changed. It cannot supply a missing request context, restore filtered fields or establish who approved the original transaction. Different representations can produce different bytes without demonstrating a change in the underlying resource record.

The professional implication is narrow but important: historical content, revision identity and transaction evidence are related objects of inquiry, not the same proof.

Sources