Summary

  • RFC 2167 used a hierarchy of authority areas to send a query up toward a parent or down toward a more specific custodian, not to certify a directory record.
  • Its own counterexample placed a howard.md.us object under va.us: the object could exist in a server's database yet be unreachable through the intended RWhois tree.

Imagine looking for howard.md.us at a server responsible for va.us. The server has a perfectly valid connection and perhaps many well-maintained records. It is still the wrong branch. RFC 2167 says it cannot answer this question authoritatively and must point the client up to us or the root. Now place the howard.md.us object inside the va.us database. The bytes are stored, but the intended path will not lead to them. The RFC calls the record misplaced and unable to be found within the tree.

That is the sharper historical insight in the June 1997 Informational specification of Referral Whois, or RWhois, version 1.5. It did not merely distribute an old central Whois table over more machines. It proposed a rule for finding the part of a distributed directory presumed to hold an answer. Domain names and CIDR-described networks lend themselves to hierarchical labels; a person's name alone does not reveal its place in such a hierarchy. The architecture depended on the label and the storage location agreeing. A record placed at a higher, less-specific area might still be discovered in many cases, the RFC cautioned.

Wrong-branch placement is the especially revealing failure, not a claim that every imperfect filing is invisible.

An authority area joined a lexical label to a database under a server's control. Parent areas kept pointers to children; children kept a path back up. RWhois distinguished a punt referral toward a parent from a link referral toward a descendant. A referral carried a server location, port and area. The next server might return data, an error or further referrals, and multiple referrals could be followed in any order. This was a route toward a presumed maintainer, not a guarantee that the endpoint was reachable, current or right about the object. For terms without a usable hierarchy, the proposal allowed a separate indexing server to return referrals. That qualification matters: the tree was a powerful lookup rule, not a universal way to infer every person's location from a name.

The routing rule also shaped what a negative answer meant. Within its area, a server could return an object, a referral to a more specific area or no object. An out-of-area server had to refer upward rather than pronounce absence. But even the right area's negative reply relied on the record having been registered in the expected part of the tree and on the relevant area pointers and accessible data. A cleanly routed search cannot discover a record filed in a sibling's drawer. A response describes this directory's state and path, not the global nonexistence of a person, network or entitlement.

Custody and vocabulary were local as well. Each area could define its own classes and attributes; a shared core schema was recommended for interoperability but was not imposed by a parent. The referral class exposed the referred area and a server URL. It did not adjudicate whether two areas used a contact field in the same way. An application reading a returned row would still need to know which maintainer supplied it, what the local fields meant and what other evidence could support the real-world assertion.

RFC 2167 separated registration from copying. Exactly one master server registered data for an area; slave servers could answer authoritatively from replicated material but could not register it. Replication could be complete or incremental and could cover a subset of classes or attributes. The Start of Authority serial and refresh/retry intervals helped a slave decide when to check and transfer changes. Those controls make a copy operationally useful; they do not turn a copied field into an independently verified identity. Nor do they make a stale copy impossible at every instant.

The guardian mechanism introduced yet another boundary. A guardian could govern additions, changes, deletion or private viewing for an area or object, with password and PGP methods discussed in the RFC. Authenticating a permitted updater is different from proving that the updater's assertion about a resource is substantively correct. Restricting who may see a contact is different from confirming that the named contact is reachable. These are meaningful controls, but they answer different questions.

The document described a protocol and architecture, not a census of installations or a recorded transaction. It explicitly carried Informational status rather than claiming to specify an Internet standard. Nothing in this evidence establishes that a particular 1997 query traversed the illustrated path, that a live record was wrongly filed, or that today's WHOIS or RDAP services follow this design. The enduring analytical lesson is more precise: discovery, placement, maintenance, access and verification must be evidenced separately. A referral can locate a custodian. It cannot certify the custodian's record.

Sources and evidence limits

The primary account is RFC 2167, especially §§2.1–2.6 and 4; the RFC Editor record supplies bibliographic status. RFC 1714 is its predecessor, and RFC 954 documents the earlier NICNAME/WHOIS context. These texts support the specified design, not deployment prevalence, actual identity, allocation validity, a successful lookup, an authorized change or a contemporary service claim.