Summary

  • RFC 2345 separated finding a company's web information from administering DNS or deciding rights in a name; its Experimental service accepted a putative company name and returned URL/name pairs.
  • Matching, spelling variants and even the meaning of the displayed “company name” were left to each server, so protocol conformance did not establish the correctness of a result.
  • The demonstration could rank and truncate matches, open a sole result automatically, and return “not found” from one finite database; none of those outcomes proved completeness or authority.
  • Domain registration, DNS delegation, page control, certificates, corporate identity and service performance remained separate evidence layers.
  • The durable lesson is not that simplicity failed. It is that a simple locator must not be promoted into an identity credential or a service receipt.

The result card looked more complete than it was

Imagine a browser window with one answer in it. The company name is familiar. The URL looks plausible. There is no competing row, no warning and no score. The next click feels almost administrative: the machine has found the company.

RFC 2345 was built to create nearly that experience. A client sent a name to a commercially provided WHOIS server. The server returned one or more lines, each containing a URL followed by a display string called a company name. One match could be fetched immediately. Several matches could be shown as a list from which the user chose.

That convenience solved a real late-1990s problem. Guessing that the “XYZ Company” must live at www.xyz.com loaded information discovery onto DNS naming conventions. It also confused three different disputes: how domains were administered, who had rights in a name, and how a person could find web information for an entity whose ordinary name they knew. RFC 2345 deliberately took the third problem out of the first two.

The protocol's restraint was sound. The error begins when the narrow answer is read as if it settled the questions the memo had separated.

The server, not the protocol, decided what matched

The request did not carry a corporate identifier, jurisdiction, registration number or authenticated claim. It carried a putative company name.

RFC 2345 left the meaning of that input to the server. Each provider could decide which spellings, abbreviations or variants it would accept. The specification went further: whether the resulting match decision was correct was outside its scope. Case-insensitive handling supplied one mechanical convention, but it did not define entity resolution.

This matters because names are not keys. A short trading name can belong to unrelated businesses in several countries. A parent, subsidiary and product may share a brand. A company may have changed its legal name while keeping a familiar public name. Transliteration can produce several Latin spellings. Punctuation and corporate suffixes can disappear without making the remaining words unique.

A compliant server could handle those tensions carefully, or poorly. Conformance showed that the exchange used the agreed line format. It did not certify the provider's normalization rules, source records, conflict handling or editorial judgment.

“Company name” was a display field, not a legal identity

The response looked structured because every line had two visible pieces. The first was a URL. The rest of the line was called a company name.

But RFC 2345 deliberately declined to standardize the semantics of that second piece. It might be only a name. It might append a location or type of business. It might contain some other server-chosen description. The field existed to help a person select a URL, not to carry a certified corporate identity.

That design reduced the amount of interpretation a client had to perform. It also meant that a consumer could not infer what evidence lay behind the label. The line had no standard place for a legal registry, company number, jurisdiction, source date, editor, confidence score, correction history or relationship between the named entity and the domain.

The absence was not an accidental bug. It was the price of the experiment's minimalism.

A URL located a resource; it did not convey title

RFC 1738 described a URL as a compact representation for locating and accessing an Internet resource. That function was already useful enough. RFC 2345 placed such a locator beside a human-readable company string.

Neither document turned the URL into a deed.

The domain might be registered by the named company, a parent, a subsidiary, an agency, a hosting provider, a distributor or an unrelated party. The page might be official, historical, delegated, compromised or redirected. Even a correct association at the time of editorial review could later change.

RFC 1738 explicitly warned that a URL had no general guarantee of continuing to point to the same object. RFC 2345 identified an additional risk: if the translation server were spoofed, it could return the wrong URL for a company. The suggested defence was attention to certificates, signatures and other authenticity signals—not faith in the mapping line.

The line therefore supported a bounded claim: this directory supplied this location for this display label at this time. Domain registration, delegation and page control each required their own evidence.

One result could trigger too much confidence

The proposed client behaviour made ambiguity visible when there were several matches. It could show the names and let the user choose. A single result was treated differently: the client could ask for confirmation or fetch the URL as if the user had typed it.

The demonstration client chose the faster branch. When it found only one database match, it launched the default browser and navigated there without further user intervention.

“Only one” sounded like uniqueness. It meant only one match under one provider's data, matching rules and current search. Another directory could hold a different entry. A spelling variant could have missed a record. A legitimate company could be absent. Two legal entities could have been merged by normalization. The top result could simply be the survivor of a ranking and truncation process.

Automatic navigation converted a directory judgment into user action. That did not make the judgment wrong, but it raised the cost of hiding its scope.

Ten lines did not make an exhaustive directory

The demonstration server contained approximately 209,000 entries supplied by Dun & Bradstreet. When ten or more records matched, it returned only the top ten. The client displayed between two and ten names sorted by score.

Those details expose three different limits.

First, the database was finite. “Not found” meant that the submitted string did not match anything in that database. It did not mean that the company did not exist, had no website or could not be found elsewhere.

Second, ranking mattered. The protocol did not standardize the score, its features or its interpretation. A high position was a provider decision, not a neutral property of the company-domain relationship.

Third, truncation made a successful answer potentially incomplete by design. Ten returned lines could coexist with further matches that the client never saw.

The demo also offered no path for additions or changes and disclaimed responsibility for accuracy. Those were not marginal caveats. They described the maintenance boundary of the only concrete implementation documented in the RFC.

Directory quality lived outside the wire format

RFC 2345 stated the central limit plainly: result quality depended on the underlying directory and the editorial and research work used to construct it. Neither was a matter for the protocol.

The wire format could be perfectly implemented while the directory was stale. A parser could separate the URL from the label without knowing whether an editor had verified the association. A server could answer quickly from cache while preserving an old error. A client could render every character correctly while concealing the source and age of the record.

This is why transport correctness and information correctness need separate receipts. For the former, one can capture the query, response bytes, variation number and parse result. For the latter, one needs provenance, effective time, source comparison, entity-resolution rules, change history and a correction route.

RFC 2345 standardized the first layer. It intentionally left the second to providers and market pressure.

Provider choice changed the answer's frame

The memo saw no technical need for one provider or for a registry of providers. It expected clients to allow server choice.

That pluralism was useful. Competing directories could try different sources, markets, languages or editorial methods. But provider selection became part of the evidence. The same input could yield different candidate sets, rankings and “not found” outcomes without either server violating the protocol.

The response therefore could not be evaluated without the service identity. A captured result missing the provider, query time and exact input was weaker than it looked. Repeating it against another server was not merely a redundancy check; it tested a separate editorial system.

The market might reward better mappings, as the authors hoped. A user examining one response could not infer that competition had already selected a trustworthy winner.

Finding the page still preceded proving the service

Suppose the mapping was accurate and the page genuinely belonged to the named company. The user's practical task was still unfinished.

DNS had to resolve. The network path had to work. The server had to answer. TLS evidence had to fit the hostname and the relying context. Redirects had to remain within an acceptable control chain. The page had to offer the expected product, support or information. A transaction might still fail. A support queue might still be abandoned. A polished website might describe a service that was unavailable in the user's region.

RFC 2345 promised none of those outcomes. Its client could navigate to a site; it could not certify that the visit produced reliable service.

That final distinction is easy to overlook because web navigation joins discovery and use in one gesture. Evidence should keep them apart: a directory result, a domain-control record, an authenticated page and a completed service transaction are four different receipts.