Summary

  • RFC 1914 did not give a WHOIS++ client one authoritative directory root; it gave the client referrals and made it responsible for deciding where to ask next.
  • The client’s visited-server set prevented loops, but the same client also chose the starting point, expansion depth, cache lifetime, blacklist and stopping condition.
  • A record found on one path was evidence of that path. An empty result was never evidence of global absence unless the explored mesh, failures, exclusions and budget were also known.

A reply could be another question

The basic transaction was deliberately small. A client connected to a WHOIS++ server, sent a query, received a reply and closed the connection. The reply might contain records. It might instead contain one or more SERVER-TO-ASK blocks that named other servers. After parsing the response, the client chose whether to contact them.

That last step carried more authority than the simple protocol exchange suggested. A server could advertise a possible next hop, but it did not compel the client to follow it. Nor did it promise that the referred server was reachable, inexpensive, trustworthy or able to return the desired record. The referral was forward knowledge: a reason to look elsewhere, not the answer itself.

RFC 1914 recommended starting with a configured server that was as local as practical. Locality reduced some cost, but it did not define the records’ geography. A server in one country could have indexed an organisation in another. If the user wanted records constrained to the United States, the country condition had to appear in the query. The place where a question entered the mesh and the scope of the question were separate facts.

The graph forced the client to remember

The diagrams looked partly hierarchical, yet the document stressed that the mesh was not necessarily a tree. One base server could feed more than one index hierarchy. Organisations could create shortcut relationships. A referral could therefore lead back toward a server already visited.

RFC 1914 put all loop detection in the client. Its illustrative algorithm maintained a QueriedServers set as well as lists of starting servers, servers still to ask and answers already collected. Before sending a query, the client checked whether that server had been queried. The loop was prevented not because the mesh prohibited cycles, but because the client carried memory across transactions.

This matters for evidence. A log containing only the final records cannot show whether another branch was skipped as a duplicate, excluded by policy, unreachable or never discovered. A log containing only hostnames may also miss identity continuity if an endpoint changed. The traversal object includes the starting server, every referral received, the handle and endpoint advertised, the decision to follow, the connection result, the answer returned and the visited-set state that prevented repetition.

Expansion bought possible recall at a real price

If the first search returned nothing, or if the user wanted broader coverage, the client could ask about polled-by and polled-for relationships. Those answers revealed other index servers, and the client could repeat the original query against them. Search scope expanded by discovering the graph itself.

But RFC 1914 refused to call expansion free. Blindly following the mesh could make resource consumption grow exponentially. Some parts of the contemplated WHOIS++ environment charged for responses, so the expansion could also grow a monetary bill. The document did not recommend automatic expansion without restraint. It expected sophisticated clients to cut off selected servers and allowed a user to stop a long transaction.

Completeness was therefore not a binary server property. It depended on how many referral edges the client followed, which branches it rejected, how long it waited, what it could afford and whether the user accepted another round. A fast client could look complete by returning early. A comprehensive client could look broken while it waited on remote branches. Neither performance number made sense without the traversal policy.

The Directory of Servers did not remove the starting choice

RFC 1914 offered another navigation device: a special Directory of Servers. It held server-handle records with a current hostname and port, plus descriptive attributes. In the version described, the address of this special directory itself had to be preconfigured. The document proposed showing the discovered servers to the user and did not yet recommend fully automatic selection.

The apparent bootstrap solution therefore still contained a bootstrap. Someone configured where the Directory of Servers lived. Its records helped a user choose a better entrance, but did not become a universal root with authority over all underlying data.

The server handle also provided continuity when endpoint data grew stale. A SERVER-TO-ASK hostname or address could have been copied during a poll weeks earlier. If connection failed, the client could query the special directory by stable handle and obtain the last known hostname. That was useful repair, but “last known” remained a bounded claim. It did not prove the replacement endpoint was alive or that it served the same records.

A centroid said where a word might exist

RFC 1913 explains the forward knowledge beneath the referrals. A WHOIS++ server could generate a centroid: template names, attribute names and a de-duplicated list of words that occurred in those attributes somewhere in its records. An index server searched such summaries to decide which underlying servers might satisfy a query.

The compactness was the point. An index did not need every record to route a search. But the compression created an evidence ceiling. A token in a centroid did not identify the record containing it, show whether two query terms occurred in the same record, prove freshness or establish the truth of the underlying field. It justified a referral. The base server still had to answer.

This split resembles routing without being routing. The centroid helped select a directory path, not an IP path. The selected endpoint still had to be resolved and contacted; the query still had to be understood; the local database still decided what records existed and what access policy applied.

A blacklist was refusal, not authentication

RFC 1914 warned that a fake WHOIS++ server could appear and said clients should support a blacklist. That gave the user or operator a local refusal control. It did not authenticate every server absent from the list. A server could be unknown rather than approved, or compromised after being trusted.

The security boundary was consequently distributed too. The index server asserted a referral. The Directory of Servers asserted a last-known navigation record. DNS mapped a hostname at a moment. The remote server presented whatever protocol and authentication evidence it supported. The client combined those inputs with local policy. No single receipt spoke for the entire chain.

CIP preserved the burden because it was also control

In 1999, RFC 2651 generalised the indexing architecture as the Common Indexing Protocol. It acknowledged the obvious criticism: the client seemed to receive all the hard work. Its answer was that client responsibility also gave the client control over result-set size, search speed and depth. The architecture again rejected a single root for scaling reasons, retained cycle handling and treated the entry point as consequential.

That later reuse did not prove that WHOIS++ became universal. Nor did the TISDAG mesh scenarios documented in RFC 2968 prove global deployment. They show that the coordination problem survived the first vocabulary. A distributed index could avoid one central database while still needing agreements about index objects, referral semantics, query mappings, security and where a client should begin.

Published in February 1996, RFC 1914 is now Historic, and the WNILS working group is concluded. Those statuses locate the documents in the standards record. They do not supply a deployment curve, query-volume record, actual response-price figures or a precise retirement date. The strongest historical claim is narrower: the specification made the cost of decentralised discovery explicit before a result could be called complete.

Absence needed a traversal receipt

The durable lesson is not that every directory should make clients crawl a graph. It is that a negative answer belongs to an explored scope. To defend “not found,” an operator would need the original query, its explicit geographic and field constraints, the initial server, centroid or referral versions, every discovered edge, visited-set history, cache ages, endpoint resolution, connection failures, blacklist decisions, cost and time limits, user cancellations and the final answer set.

Without that record, “no result” can mean no record on the first server, no centroid token, an unreachable referred host, a stale address, a pruned expensive branch, a cycle already visited, a user stop or a genuinely exhausted reachable mesh. RFC 1914 made the client responsible for telling those stories apart. The mesh had no mandatory root; completeness still needed an accountable owner.

Sources