American MemoryThe National Digital Library Program: Archived Documentation

The Library of Congress / Ameritech National Digital Library Competition (1996-1999)

Handle Server [May 4, 1998]

Overview   |   More on Handles and Naming Authorities   |   A Global System of Handle Servers

The CNRI Handle System is distributed across many computers

The process of resolving handles in a global environment involves a sequence of messages between several computers. Figure 1 shows a simple but realistic configuration. The user has a web browser that incorporates a module (e.g. the CNRI Handle System Resolver browser extension) that recognizes handles and knows the Internet name of the Global Handle Registry, a computer at CNRI. The global registry knows about all local handle servers. The example assumes that the Library has a local handle server which has records for items in NDLP collections. These records link each registered handle with a URL (Uniform Resource Locator) or other form of locator. If presented with the handle for an item in an NDLP collection, a sequence of four messages would "resolve" the handle into a URL, which the browser could then use to request the item in a fifth message. An informal description of the messages follows the diagram.

Figure 1. Resolution of handles (basic)

Diagrams are almost essential for this 

Imagine that the web browser detects the following handle: hdl:loc.pnp/det.4a32371t. The handle may be in an HTML or SGML document, such as a finding aid, have been retrieved through a search of bibliographic records, be entered directly by a user who has a reference, or any other means.

A sequence of messages resolves the handle and retrieves the item

Given the handle URN:hdl:loc.pnp/det.4a32371t, the following messages are exchanged:

  1. Request from Handle System Resolver within browser (HSR) to Global Handle Registry (GHR):
    Which handle server manages names for "loc.pnp"?
  2. Response from GHR to HSR:
    Local handle server (LHS) at
  3. Request from HSR to LHS:
    What is the URL for "4a32371t"?
  4. From LHS to HSR:
    URL is "//"

    The handle has now been resolved into a URL. The final message is exactly the same as the message that would have been sent if the web browser encountered a link specified by a URL rather than a handle.

  5. Request from web browser to digital archive:
    Get "//"

The handle system can save time by remembering earlier conversations

The key to efficient handle resolution on a global scale is built round the concept of caching. Instead of all web browsers in the world going directly to the Global Handle Registry with requests, requests can be sent to a closer handle caching server, which can carry out all the handle resolution conversations and remember a lot of handle server locations and URLs in a large cache. Figure 2 shows this configuration. When a new handle is encountered, more messages (6 instead of 4) may be needed to resolve a handle into a URL, but the caching server can be configured with a large cache so that a substantial proportion of the messages are unnecessary.

Figure 2. Resolution of handles (with intermediate caching server)

Diagrams are almost essential for this 

The handle system is extensible

As the use of handles grows, subsidiary local handle servers can be added to manage names under delegated authority and caching servers can be added or expanded. No changes are needed in the process or the component software as this extension happens.

The handle system is very like an existing Internet service

The resolution process may seem complicated, but a very similar process is invoked every time an Internet domain name is used. When a user follows a link to, (the name of LC's WWW server and home page), the name must be resolved into its numeric IP address, currently When a user starts a LOCIS session by opening a Telnet connection to, the same resolution process is used to get the address No message can be sent on the Internet without an address in the numeric form, but the software does the resolution behind the scenes; users are usually unaware of the process. Some web browsers display messages on the status of resolution; these messages may occasionally be on the screen long enough to be read.

The domain name system was developed to solve the same type of problem as the handle system. The names used to access services can stay the same even when those services are transferred to different computers. Short mnemonic names are easier to transcribe and remember than strings of numbers. Basic name resolution software is incorporated into all of the utility software packages that support Internet access. Just as with CNRI's handle system, the domain name system has a central registration server, decentralized name servers that provide the authoritative name-to-address translations for certain domains, and a network of communicating caching name servers.


  1. The diagrams represent the ideal situation in which the Handle System Resolver (HSR) is incorporated into the browser. However, the resolution process can be carried out on an intermediate server. In particular, the URL formed by preceding any handle with or (and dropping the "URN:hdl:" scheme prefix) will invoke the handle resolution software on the corresponding "proxy" handle-server.
  2. For simplicity, this explanation assumed that handles will always be resolved to URLs. There are other potential forms of locator, including one that retrieves items from the repository under development with CNRI. The resolution process remains the same.
  3. Other proposals for resolving URNs will have a generally similar structure, with a central authoritative system, distributed subsidiary systems, and caching at intermediate stages. Some proposals suggest extending and modifying the existing Domain Name Service to provide resolution for URNs as well as domain names.