Handle Management System

1. Overview

The Handle Management System (HMS) is used to retrieve location data associated with a "handle". A handle is a printable string which unambiguously identifies this location data. Handles may be used, for example, to identify digital objects stored within a digital library. In this instance, the location data associated with the handle would include one or more "object pointers". An object pointer identifies the "storage facility and /or rights management system" locations.

The HMS is comprised of three component types, namely Handle Generators, Handle Servers and the Handle Server Directory:

Handle Generators create globally unambiguous handles that can be associated with digital objects.
Handle Servers store the handle and associated location information and process handle query requests from clients to resolve handles. If a requested handle is found in the Handle Server, the location data associated with it is returned to the client.
The Handle Server Directory provides a list of Handle Servers in operation.

This document describes the interfaces to the Handle Management System.

2. Introduction

2.1. Handles

In order to retrieve a digital object, an identifier that is unambiguously associated with the object must be provided. This identifier should have the following properties:

The identifier must be unambiguous. The identifier can point to only one object; however an object may have multiple identifiers associated with it.
An object identifier must be essentially permanent, since copyrights on digital objects may last for 150 years (assuming life of the object's author plus 75 years).
The identifier should not have any location information encoded in the identifier's namespace, since the object may be located at multiple and changing locations over time.
Since the number of digital objects created is expected to increase, the identifier's namespace is variable and unrestricted.
Once a user acquires an object's handle, he should be able to use the handle to ascertain the current location of the object.
Multiple authorities should be able to generate the identifiers.

In addition, the following constraints on the use of an object identifier are desirable:

Users of an object do not need to know its location(s), only its handle.
Objects may be moved from one storage facility to another without affecting users.
Users should be able to choose object providers based upon the terms and conditions associated with an object, including its costs.

An identifier that meets these criteria is called an object handle.

2.2. Information Associated with Handles

The Handle Management System associates one or more types of data with handles. These types of data may include:

Object Pointers to Repositories
Universal Resource Locators (URLs)
Electronic Mail Addresses (if a handle represents a person or mailable entity)
Distinguished Names (if a handle represents a personal or titled entity)

The types of data that can be associated with a handle are still under discussion. However, a digital object located in the Digital Library System has its own type, an Object Pointer.

Object pointers consist of two components:

Domain name of a Repository or Digital Library System
Domain Name of a Rights Management System

2.2.1. Associating Data with Handles

The Handle Management System provides one or more Handle Servers to provide mapping between Handles and its associated data. Handle Servers have the following characteristics:

A Handle Server holds data associated with a subset of all handles.
Handles are assigned to Handle Servers based upon "hash" values computed on the handles.
Handle Servers are assigned ranges of hash values.
The set of all hash values is partitioned among the set of all Handle Servers.

The Handle Server Directory identifies the existing Handle Servers and holds a table which associates hash ranges with domain names of Handle Servers.

2.2.2. Using Handles to Obtain Data

Given a handle, the following steps are followed to obtain a set of data associated with the handle:

A client program/system downloads the "hash range -> Handle Server domain name" table from the Handle Server Directory for future use.
At a later time, the program/system obtains a handle for which pointers are desired.
If the program/system "knows" the hash algorithm for the Handle Server service, it generates the hash code for the handle. The program/system consults the "hash range -> Handle Server domain name" table to determine the domain name of the appropriate Handle Server.
Otherwise, the program/system selects a Handle Server at random from the "hash range->Handle Server domain name" table.
The program/system sends the handle to the Handle Server as part of a "Request Pointer Information" UDP packet. The program/system can optionally request the Handle Server to perform the following additional activities:
- If the request was sent to the wrong Handle Server, the server should optionally forward the request to the correct server.
- The Handle Server should return only those types specified in the request.
- The Handle Server may digitally sign the response.
The Handle Server returns its response to the requesting program/system:
- A set of the requested data.
- "Not Responsible for Handle." In this case, the handle was sent to the wrong handle server, and the request did not contain the "forward request on invalid server" option. The client program/system should download the "hash range -> Handle Server domain name" table from the Handle Server Directory and attempt the mapping again.
- "Handle Not Found." The request was sent to the correct Handle Server, but the requested handle could not be found.

dely@cnri.reston.va.us
1/26/95