Summary

  • RFC 1913 let Whois++ servers advertise compact “forward knowledge”: deduplicated tokens that indicated which lower servers might contain a matching record. The summary supported query routing, not record-level proof.
  • Multiple indexing paths reduced dependence on one hierarchy, but they produced a graph that clients had to traverse. Freshness, loop control, endpoint recovery, search fan-out and possible charges remained separate responsibilities.
  • The idea was later generalised as the Common Indexing Protocol, while Whois++ itself was moved to Historic in 2006 after an IETF review described it as defined but not used.

The useful disappearance

The small example in RFC 1913 is more revealing than its network diagram. Three records contain two users, one domain and a handful of fields. Their centroid retains each template name, each attribute name and one occurrence of every word found under that attribute. “Smith” appears once in the summary whether it belonged to one record or a thousand. “Beer,” “Labatt” and “Molson” remain as independent tokens; the fact that two words once shared a field value does not.

That is not a damaged database. It is an intentionally smaller claim. An index server does not need every underlying record in order to decide that a lower server might deserve the next query. It needs enough forward knowledge to prune branches that cannot help.

The distinction matters because every compression deletes evidence. A centroid did not identify the matching record, count matches, preserve phrase order, explain who supplied a value or certify that the value remained present at query time. A match meant: under the indexing state available here, this token appeared in this template and attribute somewhere below. The next step was a referral, not a conclusion.

A mesh above records

The broader RFC 1835 — Architecture of the WHOIS++ service, published in August 1995, tried to move beyond the loose, human-readable records of older WHOIS. It introduced typed templates and structured attribute-value pairs. It also separated base servers, which held filled templates, from index servers, which held forward knowledge and pointers. One physical machine could perform both roles, but the logical distinction remained.

That distinction answered a scaling problem. A single global directory would concentrate storage, traffic and failure. A rigid hierarchy would make discovery depend on knowing where information belonged, burden high-level nodes and struggle with “yellow pages” questions that cut across geographic or administrative branches. A user looking for a service, rather than a named record in a known subtree, needed another route.

RFC 1913 — Architecture of the Whois++ Index Service, published in February 1996, placed a mesh over the records. Any index server could collect and combine the centroids of base servers or other index servers. A server could be indexed in more than one hierarchy: geographical, administrative or topological paths could overlap. Record identity no longer dictated the only navigation path.

This was decentralisation by indirection. The authoritative material stayed with the base server; the mesh moved hints. A specialist index could choose particular templates or fields. Alternate parents could improve reach and resilience. Users did not have to know a record's location before searching for it.

But no new path acquired the reality stored at its destination. The more useful the mesh became as a guide, the more important it was to name the epistemic boundary: the guide knew why another server might be worth asking.

A change crossed several clocks

Forward knowledge could not remain useful without maintenance. RFC 1913 specified authenticated polling. A poller could request a full centroid or changes for selected templates and fields. A polled server could also send DATA-CHANGED to announce that its centroid had changed. The receiver then decided whether and when to poll.

The sequence contained several different events: a base record changed; its centroid changed; a notice was sent; the notice was accepted; a poll was made; a change report was authenticated; an index incorporated it; and higher indexes later learned the new state. The protocol's reply code 227 made the boundary explicit. It meant that a change transmission had been accepted and logged for further action. It did not mean that every index had applied or propagated the change.

This creates two symmetrical hazards. Old positive knowledge can send a client toward a server whose matching token has disappeared. Missing or delayed new knowledge can prune a server that now holds a match. The RFCs do not quantify either failure rate, and the architecture should not be condemned for evidence it never claimed to supply. The operational lesson is narrower: an index timestamp or update receipt cannot stand in for an end-to-end freshness proof.

The client inherited the graph

The mesh looked hierarchical in diagrams, but it was not a tree. The same server could have multiple parents. That made alternate paths possible and cycles inevitable enough to require explicit controls. RFC 1913 proposed hop counts for polling relationships, with a maximum of eight in its version. For query referrals, it offered the second approach: let the client remember where it had already been.

RFC 1914 — How to Interact with a Whois++ Mesh made that client responsibility concrete. A client opened a connection, issued a query, received records and referrals, closed the connection, then chose which referred server to contact next. Its algorithm maintained a set of already queried servers and could expand outward by asking who polled whom.

The starting point still mattered. A local server exposed the part of the mesh it knew. Expansion could reach a wider view, but it was neither free nor automatically wise. RFC 1914 warned that blind expansion could create exponentially growing resource cost. Some parts of the mesh might charge for responses. A client might therefore blacklist an expensive server, decline a branch or let a user stop the search.

Completeness was no longer a property of one response. It depended on the initial servers, available referrals, loop detection, expansion rules, time, budget, blacklists and the continued availability of each target. The protocol could describe an algorithm for finding all records in the reachable mesh; the operator still chose what “reachable” and “worth pursuing” meant in practice.

A location hint could age before the query arrived

RFC 1914 also exposed a more prosaic failure. The hostname, IP address and port in a referral could have been cached since the last poll, perhaps several weeks earlier. A failed connection did not necessarily mean the server identity had vanished. The client could take the stable server handle to a Directory of Servers and ask for the latest known endpoint.

That was a sensible separation of identity from location. It supported mobility without asking every cached referral to remain current. Yet “latest known” was still bounded. The second lookup could return a newer host and still fail. RFC 1913 distinguished a desired server that was unreachable from a reachable host whose service was unavailable. A handle could repair one stale pointer; it could not manufacture a live process.

Security boundaries were equally incomplete. RFC 1913 said security issues were not discussed in that memo. RFC 1914 told clients to support blacklists because fake Whois++ servers might appear. Those statements document design limits, not a history of observed attacks. They do show that referral was a decision point: following a pointer exposed the client to another administrative domain and another claim about what data it served.

The idea escaped the product

In August 1999, RFC 2651 — The Architecture of the Common Indexing Protocol described CIP as an evolution and refinement of the distributed indexing ideas introduced by Whois++. It extracted index passing from the directory protocol, generalised the possible index objects and called the exchanged material hints used for query routing. Clients still needed a native data-access protocol to obtain the actual results.

That lineage is important. A protocol can fail to become a durable public service while one of its distinctions survives. Whois++ had coupled a particular centroid to a template-based directory. CIP tried to preserve the reusable mechanism: servers exchange compact knowledge so later queries can be directed toward probable data holders.

The retirement record is just as precise. RFC 4450 — Getting Rid of the Cruft, published in March 2006, reported a conservative review of old Proposed Standards. It placed RFCs 1835, 1913 and 1914 in the set to be moved to Historic and named Whois++ among protocols “defined but not used.” That does not erase experiments or software—the later CIP RFC itself mentions Digger. It records the IETF review's judgment that the standards no longer represented current documented practice worth maintaining as Proposed Standards.

The historical result is therefore not a morality play about centralisation defeating decentralisation. The mesh solved a real discovery problem, and its abstraction continued. What did not disappear was the cost of every handoff between a hint and a fact.

Sources

  • RFC 1835, RFC 1913, RFC 1914, RFC 2651 and RFC 4450 are linked once in the analysis above.