Update on the CNRI handle server

URNs and the CNRI Handle Management System
==========================================

In preparation for the URN discussion at the IETF meeting next
week, here is an update on the Handle Management System
implemented here at CNRI.

The Handle Management System was developed as part of the
ARPA-funded CS-TR project, as a naming scheme for digital library
objects.  (See:  http://www.cnri.reston.va.us/home/cstr.html.)  In
this project, particular emphasis has been given to creating a
framework for managing digital objects that incorporate intellectual
property rights over very long periods of time.

A.  Technical Information

How handles fit within the architecture of the digital library
is described in a paper by Robert Kahn and Robert Wilensky:
http://WWW.CNRI.Reston.VA.US/home/cstr/arch/k-w.html.
(This is the discussion draft of February 2, 1995.  A new draft is
in preparation.)

An introduction to the Handle Management System by David Ely,
correct as of fall 1994, is:
http://WWW.CNRI.Reston.VA.US/home/cstr/handle-intro.html

Code and full documentation is available by anonymous ftp from:
cnri.reston.va.us/handles

B.  Major Differences between Handles and Other URNs

1.  Most URN proposals use domain names as an authority
naming scheme and DNS to resolve URNs.  Handles use a separate
authority naming scheme.  This is hierarchical in the sense
that, if n1 is a naming authority, then n1 can create a sub-
naming authority n1.n2.  However, the handle name space is
flat in the sense that each handle is considered an opaque
string for the purpose of resolution.

Potential advantages of this approach over using DNS are:
(a) it is easier to provide persistence over very long time
periods, even when organizations change names, merge, go out
of business, etc.; (b) it appears possible to scale up the
design without limit; (c) the names are based on the
information needs of organizations, not the communications
needs;  (d) there is no risk of overloading DNS.

2.  Handles are a general purpose class of identifier.  The
objects that handles identify can be referenced directly
(e.g., by a URL), or by giving the identity of a repository.
Alternatively,  handles can be used as identifiers for
catalogs, indexes, URCs, or other indirect retrieval methods,
which may themselves use handles to identify objects.

C.  Recent Developments

1.  The global handle server described in David Ely's paper
has been operational for several months.  This includes both
the global handle service and the caching server for local
operation.  CNRI will soon have eight servers available, capable
of resolving about 1,500  handles per second.  Several large sets
of handles are being loaded.  (The largest has approximately 2
million handles mapped into URLs.)  A second generation of
administrative tools for managing handles is being implemented.
We expect that support for handles will be included with one of
the major web browsers in a release during the summer.

2.  Since the handle server design is consistent in all
fundamentals with the URN requirements in RFC 1737, the
intention is to offer the handle system as a URN name scheme,
"hdl".  This will require minor changes in allowable
character sets, use of separators, etc., but no major
problems are expected.

3.  We are now concentrating our efforts on implementing a
Local Handle Server (se below) to minimize the frequency with
which clients have to interact with the global handle service and
to allow organizations control over their own destiny.

D.  The Local Handle Server

A Local Handle Server allows a naming authority: (a) to
create handles that are not registered with the global naming
authority; (b) to resolve handles locally without interaction
with the global naming authority.  The typical use of a local
handle server will be by an organization, such as a company
or university.  It will allow the creation and resolution of
handles within the organization to be carried out
independently of the global handle server.

The details of the local handle server are currently being
worked through.  The basic design is that any naming authority
n1.n2...nk can operate a local handle server.  This creates a
hierarchy of handle servers associated with the naming authority
hierarchy.  Handle servers can be public or private.  Each public
handle server is registered with the handle server
next to it in the hierarchy and with other handle
servers up to and including the global handle server.  Handles
are registered with the handle server closest to the naming
authority in the hierarchy and optionally with other handle
servers up to and including the global handle server.

Bill Arms
3/28/95

Received on Wednesday, 29 March 1995 12:13:14 UTC