Separate Handles from Names on the Internet

Those who design and implement the Internet have improved its utility to users by providing meaningful ways to denote recipients of messages abstracted from details of network topology. Routes describe the concrete steps by which a message reaches its recipient from a particular starting point. Addresses refer to the recipient’s location, independent of the starting point. Domain names provide humanly meaningful, memorable, even guessable, descriptions of recipients, independent of the starting and target points and of the network connections between them.

This description also skipped a step. In between addresses and names a layer of handles should refer to recipients, independent of location, but that do not carry human meaning. The need for handles is obscured by the fact that, ignoring social and economic forces, domain names provide all the functionality of handles, plus the extra value of human meaning. But this extra value can attract conflict among the various parties wishing to use the same name, making domain names costly and sometimes impossible to defend. It is therefore time to introduce a separate collection of meaningless handles, providing only part of the value of domain names while avoiding the conflicts inherent in the assignment of meaningful names.

Fortunately, all of the software required for a system of handles is already in the current domain name system. We need only find a sponsor willing to support a handle domain and assign meaningless numerical handles promiscuously to all who request them. Because public-key signatures allow self-assignment of handles, the sponsor would have no responsibility for the content of the domain.

Back to Top

Pseudohistory of Network Reference

To illustrate the need for all four types of reference—routes, addresses, handles, and names—I’ve constructed a partly fictional but plausible story of network development as it might have happened.

Nonportable routes. Because the network was unable to deliver messages without routes, the Unix-to-Unix CoPy system directed all messages by routes of the form host1!host2...!hostn, describing the entire sequence of steps along the route. Each host kept its own table of hosts with which it communicated directly. System administration required little more than agreeing on the general format for describing routes; all operational routing details were handled independently by hosts.

Routes allowed distributed support for delivery but were not portable to other starting locations. If Sally at the host gargoyle discovered the route to a great online candy store run by Grampa and wished to share it with her friend Paul at foghorn, she could not merely describe it to Paul; she had to translate the route. Even if Sally were selfish and kept the candy supply to herself, she had to translate the route when she moved from gargoyle to juniper. Sally could rest immobile at gargoyle and still find that a change in network topology invalidated her route to Grampa’s candy.

Portable addresses on a static network. The Internet used numerical IP addresses to refer to hosts independent of starting point. The IP routing protocols delivered messages according to incrementally computed routes that did not need to be written explicitly. IP addresses did not encode network topology directly. Efficient routing depended on some amount of numeric clustering of addresses in subnets, and addresses could not be assigned freely.

With IP addresses to pass around, Sally, Paul, and Grampa were all happy, until the candy store’s address changed: once because Grampa moved his server from space rented on a shared computer to his own computer; once because he moved the store to another state with lower business taxes; and several other times because network topology had changed.

Portable domain names across movement and network reconfigurations. The designers of the Internet realized early on that using the network required the ability to refer permanently and reliably to an agent whose address might change. They invented domain names of the form bottomdomain.subdomain...topdomain to refer permanently to the addresses of individual agents. Domain names could be assigned independent of network topology. Hierarchical translation of domain names to IP addresses, along with local caching of the resulting addresses, made the two-step translation from domain names to routes almost as efficient as translation from addresses to routes [1].

Grampa could thus acquire candy.example in the fictitious top-level domain example and subdivide his business into chocolate. candy.example, halvah.candy.example, and so on at will. (The Internet Engineering Task Force encourages all example domain names be given as candy.example to avoid accidental collision with real domain names.) Sally could keep track of example (and perhaps her favorite subdomains), use these domain names from any host on the network, and communicate them to Paul at will. Furthermore, whenever his own mobility or a change in network topology caused the address of the candy store to change, Grampa could merely update the entry for example in the appropriate authoritative table and let it spread around to all the local caches, including Sally’s and Paul’s.

So far, I’ve illustrated the value of domain names for permanent reference to an agent in spite of the changes of address, which is the function of handles. But Grampa and all of his actual and potential customers got a big bonus as well. The domain name candy.example served as a humanly meaningful name. Sally and Paul found candy.example easy to remember, type in their email to one another, spell out over the telephone, and even guess before they knew of the candy store or when they might lose their record of its name. Since it was just as easy to implement meaningful names as meaningless handles, there was no clear reason to support a separate layer of handles.

Conflict over domain names and their use as handles. Unfortunately, the very knowledge of the humanly meaningful semantics associated with candy.example, giving it value as a name, became incompatible with its function as a handle. A number of larger and more powerful candy companies, as well as the multinational corporation C&Y, Inc., all claimed rights to candy.example, which was then taken from Grampa. The bonus value of candy.example as a name led to administrative action violating its use as a handle [7].

It is tempting to blame those nasty big companies for stomping on Grampa, but humanly meaningful names are inherently subject to forces beyond the authority of any individual handle owner. Human meaning, by definition, is determined by human communities. Individuals may determine the human meaning of a name among a circle of friends who accept their influence. But it is fundamentally infeasible to keep human meaning in line with the arbitrary exercise of authority we would like to invest in the owner of a handle. No matter how cleverly we assign names to start with, some change in society will ruin the scheme.

We might invest lots of effort improving the fairness with which conflicts over domain names are resolved and supply more and more domain names to trade-off mnemonic quality against cost. But Grampa’s ownership of candy.example is inherently a lucky and unsustainable windfall we cannot provide to everybody who wants it. Whatever contest we set up to determine ownership, only the winner of that contest may have it.

Many network resources enjoy an economic “network effect” whereby one party’s holdings become more valuable due to other parties’ holdings. But humanly meaningful names are limited by the scarcity of human memory and attention, leading in many cases to a reverse network effect in which other uses of my name reduce the value of its distinct reference to me.

Handles separated from names. At this point, my story of network reference ceases to be history and becomes planning for the future. If we are unable to avoid conflict over network names, we can at least provide conflict-free permanent handles. By locating a system of handles without human meaning at a level of abstraction between names and addresses, we can provide Sally, Paul, and other lovers of grandfatherly candy a permanent meaningless handle (such as h0061A38F9A3540B9) by which they may reach Grampa (for as long as he cares to respond). We can’t help Grampa and his customers hold on to the wonderful mnemonic value of candy.example, but they can’t keep it anyway, and it’s better to keep the handle than fight a losing battle for the name and keep nothing.

Without candy.example, how will Grampa attract attention to his business? The same way he did before his unsustainable domain-name windfall. Although Grampa’s candy handle is opaque and unmemorable, friends and satisfied customers will share copies of it using Web browsers and other software catering to users’ desire to keep track of unmemorable handles. In a pinch, they’ll type it or speak it to one another as, say, a 16-digit hexadecimal number (similar to a 16-digit credit card number). The handle will hide behind the scenes in pointers (such as the links in Web pages and their technical successors). People will keep personal directories that resolve “My favorite candy store” to Grampa’s candy handle. Grampa will advertise in venues that match his natural clientele and advertising budget, and these venues will associate his handle locally with humanly meaningful words, pictures, and other tokens, since Grampa himself can’t afford to acquire and defend a global name assignment. Aggressive indexing services (such as Yahoo and Google) will organize Grampa’s candy handle into their own presentations of the informational structure of the Web and its technical successors. And—as long as global domain names last—Grampa will still be able to fight for candy.example or make a strategic retreat to grampascandy.example or further back to grampascandyonmainstreetintinytownusaearthsolarsystem.example or yet something else. But in the long run, he will get more satisfaction from the alternatives.

Back to Top

Routes, Addresses, Handles, Names

The figure outlines my proposed four-level system of reference, including the objects being referred to and the parties with authority over them. The translation of a more abstract reference into a more concrete reference is called “resolution.” The boxes in the figure represent three types of entities:

• Parties. The items in blue rounded rectangular boxes on the top row represent the three types of parties with authority over resolution: a single network administration; any number of individual network members; or any number of overlapping human communities;
• Reference. The items in black square boxes in the middle row represent the four types of references; and
• Concepts. The items in gold ovals in the bottom row represent the types of mental concepts the four types of reference tokens are intended to capture. The act of message delivery in the network is precisely defined, but moving from left to right, the concepts become less objective and more ambiguous, as suggested by the fuzzier boundaries.

The lines and arrows in the figure represent four types of relations:

• Authority. The red lines from the top row to the middle row represent the authority of the three types of parties over the three types of resolutions. The multiple connections from individual members to arrows from handles to addresses indicate that each handle owner has separate authority over his or her handle(s). The squiggly red lines from communities to the name handle resolution suggest the complexity of their collective exercise of authority;
• Resolution. The black right-left arrows in the middle row represent the three types of resolutions, implemented through tables in various network hosts and routers;
• Conceptual connections. The gold left-right arrows in the bottom row represent the conceptual connections that allow each of these concepts to denote one to its right: each delivery leads to a particular location; each location contains a particular agent; and each agent is responsible for data or services with a particular human meaning; and
• Associations. The green up-down arrows between the middle row and bottom row represent the intended associations of deliveries with routes, locations with addresses, agents with handles, and meanings with names. The association of routes with deliveries is determined precisely and formally through network operations. From left to right, the associations become less objective and more ambiguous, as suggested by the fuzzier arrows.

Back to Top

Implementing a Handle Domain

An Open Network Handle System would add the missing fourth level of reference between names and addresses. The same sorts of caching strategies used in the current Domain Name System (DNS) make the three-step resolution of names through handles and addresses to routes as efficient as two- or one-step resolution.

Since the DNS was designed to support network handles that just happen to be meaningful, no extensive software development or deployment project is required to support an open network handle system. All that’s needed is a nice sponsor to provide a handle domain within the current system of domain names (such as handleroot.nicesponsor.org) and provide random-looking numerical handles (such as h0061A38F9A3540B9) promiscuously to all who ask for them. This handle may be implemented under DNS as h0061A38F9A3540B9.handleroot.nicesponsor.org. There is no need for the root of the handle system to be a top-level domain in DNS. Handle owners may freely define subdomains below their handles, as domain owners do today.

The sponsor’s main administrative burden in this Open Network Handle System is the authentication of updates to the handle address resolution tables. Because an individual handle has almost no intrinsic value beyond that created by the owner at the assigned address, there is no need to reliably identify handle owners with real-world people or institutions. It is important only to minimize the accidental and malicious capture of handles after they are assigned and used. To avoid being a party to a dispute, the sponsor should minimize its contact with handle owners.

The precise design of the authentication mechanism in the system should be allowed to vary. The sponsor may offer handle owners some alternatives allowing them to trade off authentication overhead against security, depending on the owners’ resources and the value of a particular handle. A natural starting point is to provide self-assigned handles containing public-key signatures, as well as conventional password-protected handles.

Self-assigned handles allow a person querying a handle and the handle’s owner to authenticate their communication without relying on the integrity of the handle servers in between that merely facilitate the connection. This idea has been proposed in a number of related applications [3, 5, 6, 8] but has not been applied to network handles. (Scott Nelson suggested the use of hashed public keys as self-assigned handles to me in a private correspondence.) Almost all of the functionality required is already in the security extensions to DNS [4, 9].

A complete Open Network Handle System would allow users to make the following updates to handle address tables:

• Create a new handle;
• (Re)assign an address temporarily to a handle;
• Temporarily delegate one handle to another handle, possibly with a different owner;
• Cancel a handle irrevocably;
• Transfer a handle irrevocably to another handle, usually with a different authentication key; and
• Mark a handle’s security irrevocably as compromised.

Typical scenarios using these operations to support creation of handle hierarchies, convert to new authentication methods, or transfer handles connected with the sale of a business are described in [9].

Back to Top

Conclusion

Problems with robust reference to resources on the Internet are widely recognized and being addressed by a variety of ambitious and potentially valuable projects, including the development of governance systems for DNS by ICANN, Tim Berners-Lee’s Semantic Web project [2], and the Internet Engineering Task Force (www.ietf.org) working groups on Uniform Resource Identifiers [11] and Uniform Resource Names [10]. These efforts all wrestle directly with human meaning in some form, and all have the potential to add much value to network operations. But they all deal with unsolved problems that preclude immediate wide deployment.

The Permanent URL (PURL) service of the Online Computer Library Center (www.oclc.org) [12] offers free handles, providing an immediate useful solution to the problem of permanent reference to documents and services that wander the Web. The PURL service assigns meaningful names on a first-come-first-served basis, exposing PURL administrators to the same sorts of disputes that plague the DNS when their success attracts the wrong sort of attention. The PURL service applies only to URL addresses.

The time is ripe for the Open Network Handle System to operate as a domain within the DNS offering meaningless numerical handles freely and promiscuously to all who ask. Handles that resolve to IP numbers provide a strategic level of service at the foundation of Internet addressing. Future expansion to higher-level addresses, including User Datagram Protocol addresses, URLs, and more would be valuable but should not be allowed to delay implementation of resolution to IP numbers.

The cost of operating the name server for the Open Network Handle System would be comparable to the cost of operating a top-level domain server. Moreover, the Internet community would be motivated to provide additional servers to share the load. There is no need for special approval from any Internet authority—the Internet Engineering Task Force, www.ietf.org, ICANN, or the Internet Assigned Numbers Authority, IANA, www.iana.org—since the handle domain uses the current DNS without modification. We may try out the utility of a handle layer without jeopardizing any other network service. For more, please see the Computing Research Repository archive at arxiv.org/corr/home.

Back to Top

Back to Top

Back to Top

Back to top