RealNames offered an appealing shortcut: enter an ordinary company or product name and reach its website. Its 2002 closure illustrates how a useful naming service can depend on a browser vendor's decision to keep routing users to it. Understanding that dependency helps separate a service's technology from its route to customers.
A familiar phrase became a website destination
Microsoft's June 1999 announcement described a licensing and marketing agreement with Centraal for RealNames in MSN Search and Internet Explorer 5 AutoSearch. In March 2000, Microsoft announced a further agreement and an equity stake of approximately 20 percent. It described routing a company or product name directly to an official website.
- A person enters a registered phrase in a supported browser or search interface.
- The interface sends the input through its keyword service integration.
- The service associates the phrase with a destination URL.
- The browser opens that website through the usual web-addressing path.
The distinction matters: a keyword-to-URL mapping sits above the destination website's domain and hosting arrangements. Losing the shortcut affects that discovery route; the destination can still be reachable through its ordinary URL if its domain, DNS and hosting remain operational. A bookmark to that URL and a paid phrase in another company's naming system have different dependencies.
Natural-language input also creates an interpretation question. A phrase might be a brand, a general subject or an ambiguous name. Direct navigation needs rules for choosing a destination; a search-results page offers several possible answers. That product choice is central to understanding the dispute.
Read the closure through dated, attributed records
- June 1999: Microsoft's announcement established the planned MSN Search and AutoSearch integration.
- March 2000: its new announcement described a closer commercial relationship and investment.
- May–June 2002: RealNames founder Keith Teare described notification that the integration would end and the company's resulting closure.
In Teare's published account of the termination, he said MSN managers told RealNames on May 7 that keyword routing would be discontinued when the contract period ended, identifying June 28 as the switch date. He described closing the company, dismissing 83 employees and disruption for registries and resellers. These are the founder's statements about the event and its consequences.
Teare also attributed Microsoft's decision to a desire for control over search and browser navigation. That is his interpretation of motive. The earlier Microsoft announcements establish the integration and commercial relationship; they do not establish why Microsoft later chose to end it. The defensible lesson is narrower and more useful: a company distributing through another company's interface needs a plan for withdrawal of that access.
Closure, notification and the end of a service contract can fall on different dates. When reconstructing a shutdown, attach each date to its event and source. A single “closed on” label can obscure the wind-down customers actually experienced.
An open protocol and a distribution agreement solve different problems
The Common Name Resolution Protocol, RFC 3367, published in August 2002, specifies a way to resolve common names using contextual information such as language and geography. It allows services to return matching records and resource identifiers. The protocol concerns exchanges between clients and resolution services.
A protocol document makes a technical exchange describable and implementable. A browser still needs an implementation, service selection and product policy, while a commercial operator needs users, reliable operation and workable agreements. Protocol publication therefore answers a different question from “Will a particular browser continue to send customers to this service?” RealNames makes those layers unusually visible.
Turn the case into a service-dependency review
Before adopting a discovery platform, hosted directory, marketplace or naming shortcut, draw the actual route from the user's first action to your destination. For every step, name the operator and the agreement or setting that keeps it working. Include the domain registrar, DNS provider and hosting service where relevant; a familiar brand may supply several layers.
| Dependency | Evidence to obtain | Fallback to test |
|---|---|---|
| Entry point | Who controls the browser, directory or app where customers start? | A direct URL that a customer can use independently |
| Commercial access | Applicable renewal, termination and change-notice provisions | A named owner and an actionable exit timetable |
| Mapping and data | Which records can be exported and who controls destination changes? | An export opened and reconciled in a usable format |
| Customer continuity | Which permitted channels reach existing customers? | A tested communication and alternative-access plan |
The service-dependency worksheet records each operator, notice provision, export and fallback test. Review it when a contract, integration or customer entry point changes. For a fuller transition involving products, orders and URLs, see legacy-store migration planning.