Network Working Group                                     Sam X. Sun
INTERNET-DRAFT                                                  CNRI
Expires Jan, 16, 1999                                  July 16, 1998

        Handle System: A Persistent Global Name Service
                        Overview and Syntax

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in

   To learn the current status of any Internet-Draft, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on (Africa),
   (Europe), (Pacific Rim), (US East
   Coast), or (US West Coast).


   The Handle System (r) is a comprehensive system  for assigning,
   managing, and resolving persistent identifiers, known as
   'handles' for digital objects and other resources on the Internet.
   Handles can be used as Uniform Resource Names (URNs). The Handle
   System defines:(a) an open set of protocols, (b) a global namespace,
   and (c) a distributed service model that provides the global name
   service. The system allows Internet resources to be named as handles.
   A handle may contain the information necessary to locate and access
   its named resources. This associated information can be changed as
   needed to reflect the current state of the identified resource
   without changing the handle, thus allowing the name of the item to
   persist over changes of location and other state information.
   Combined with a centrally administered naming authority registration
   service, the Handle System provides a general purpose, distributed
   global name service for the reliable management of information on
   networks over long periods of time. (Note that in this document we
   do not attempt to distinguish between the terms 'name' and
   'indentifier' and will use them interchangably.)

1. Introduction

   The Handle System is a distributed information system that provides
   a persistent naming service for use on networks such as the
   Internet. Handles can be used to identify any network resources.

   Each handle may be assigned with a set of typed values that describes
   its named object. The Handle System provides the handle resolution
   service that allows these values to be retrieved. It also provides
   the handle administration service that allows individual handles to
   have their own administrator(s) assigned, and be administrated over
   the distributed environment.

   The Handle System ensures that every handle is unique within the
   context of the Handle System and may be retained and resolved over
   long time periods. The resolution information associated with each
   handle can be changed as needed, allowing the handle to persist over
   changes in location and other states of the named resource.

   Specifically, the Handle System was designed to address the
   following problems in network resource identification:

   * Persistence

     A named resource can outlast any specific computer system or
     organization. Any resource name which is inextricably linked
     with a specific system or name of an organization will not be
     able to survive the demise or radical change of that computer
     system or organization. By separating the object's name from
     location, ownership, and other state information, the Handle
     System allows that identifier to persist over time.

   * Location independence

     With handles, the name of the item is unrelated to the location
     of the item. This allows easy reorganization of information.
     Handles make it possible to transfer resources from one
     organization to another without affecting or breaking the
     existing user references (i.e., handles) to those collections.
     This is not possible using location based references.

   * Multiple instances of an item

     A single handle can refer to more than one instance of a network
     resource. A network service may thus define multiple entry points
     for its service with a single handle name. This allows the service
     to distribute its service load into multiple instances.

   The Handle System has been implemented and is currently in use in
   a number of prototype projects, including efforts with the Library
   of Congress, the Association of American Publishers, the Defense
   Technical Information Center, and the United States Information

   This is the first of a series of planned documents that will
   specify the handle protocol and services, and relate the Handle
   System to other IETF activities in URN/URI/URL working groups.
   This document provides a concise overview of the system and the
   syntax of handles. Additional information can be found on CNRI
   and related project web sites [4, 5, 6, 8, 16, 17, 18, 19].

2. Handle Syntax

   Every handle in the Handle System is defined in two parts:
   its naming authority, otherwise know as its prefix, and a unique
   local name under that naming authority, otherwise known as its
   suffix. The Handle System protocol mandates UTF-8 [2] as the only
   encoding for any handles specified in the protocol packet.

   The naming authority identifies the administrative unit of the
   underlying handles. It is globally unique and will be persistent
   once obtained. Naming authorities may consist of any UTF-8 encoded
   characters defined in the Unicode 2.0 [1] standard except '.'
   (%x0E) or '/' (%x2F). ASCII characters in the naming authority
   are case insensitive and are converted into upper case before
   resolution taking place.

   The local name under the naming authority may consist of any
   UTF-8 encoded characters defined in the Unicode 2.0. It does not
   impose any reserved or excluded characters. ACSII characters
   within the local name are case insensitive, and are converted
   into upper case before resolution taking place.

   The following is the handle syntax described in ABNF [21]

      <Handle>           = <Naming Authority> "/" <Local Name>

      <Naming Authority> = *( <Naming Authority>  "." ) <NA Name>

      <Local Name>       = 1*( %x00-FF )
                            ; any octets that map to UTF-8 encoded
                            ; Unicode 2.0 characters.

        <NA Name>          = 1*( %x00-2D  /  %x30-FF )
                            ; any octets that map to UTF-8 encoded
                            ; Unicode 2.0 characters except octets
                            ; %x2E-2F which map to ASCII characters
                            ; '.' and '/'.

   Here are some examples of valid handles that may be used in the
   Handle System protocol:





3. Handle data

   A handle within the Handle System is associated with, and can
   be resolved to, one or more elements of typed data. Examples of
   data types in use include URLs, object request brokers, and
   other URNs. Other examples might include e-mail addresses or
   public key certificates. There is a controlled set of named
   types accepted by the system. This list can be extended as
   needed at the system level.

   Each handle will also have its administrative data. The
   administrative data, e.g., permissions to create handles or
   edit handle data, is initially provided by the handle server when
   the handle was first created. The administrative data can be used
   to define the handle administrator that manages the handle data.
   This administrative data is not returned as part of the handle
   resolution but is used for handle administration only.

   Other than the relationship between the Global Handle Registry
   and local handle services described above, there are no
   hierarchical relationships assumed among handle records.  Note,
   however, that handles can include in their associated data
   references to other handles, thus allowing hierarchical or other
   relationships to be constructed as needed.

4. Using Handles in the World Wide Web

4.1 Handle URI syntax

   The Handle Syntax in section 2 defines the encoding rules for
   handles transferred over the wire via the Handle System protocol.
   Handles may also be referenced as a URI [22], which can be used in
   Web browsers or in HTML mark-up documents to refer to persistent
   Internet resources. The Handle URI syntax defines the syntax
   rule for handles specified in the URI format.

   Handles defined as a Handle URI may be resolved by the Handle
   System Resolver [4]. The Handle System Resolver will convert the
   URI into the Handle (as defined in section 2) before doing the

   The Handle URI Syntax is defined as follows:

      <Handle URI> = "hdl:" [ <Modifier> "@" ] <HandleRef>

        <Modifier>   = [ <Encoding> ] [ "type=" <Type-id> ]

        <Encoding>   = 1*40( %x01-7F )
                                ; A registered charset name [23] from IANA,
                                ; which may be any printable ASCII characters.

        <Type-id>    = 1*(%x30-39)
                                ; digits 0 - 9.

      <HandleRef>  = 1*( %x00-%xFF )
                                ; Octets that encodes a <Handle> using the
                                ; <encoding> in the optional <Modifier>.
                                ; If no <Modifier> specified, UTF-8 encoding
                                ; is the default encoding.

   When UTF-8 is the encoding used, the Handle URI Syntax has two
   reserved characters, % and ". The character % is used for hex encoding,
   which is necessary to allow any handles specified from the standard
   keyboard. And the character " is reserved to allow handles to be
   separated from the surrounding text in HTML documents. Reserved
   characters must be hex encoded when used in the URI context. The
   choice of % and hex encoding is also compatible with the current URI
   practice. Because some browser implementation (incorrectly!) drops
   the # character when processing the URI regardless of its scheme, hex
   encoding of character # is also recommended.

   Examples of handles using Handle URI Syntax are:


      (which refers to handle "cnri.dlib/july95-arms")



      (which refers to handle "handle-with-hex-encoding/handle%abc")

   It's worth noting that the handle namespace by itself does not
   impose any hex or escape encoding, nor does the underlying
   Handle System. The reserved characters and hex encoding are
   introduced only when handles are used in the URI context. It is
   the client software's responsibility to decode any hex encoding
   in the handle URI before sending the handles out for resolution.
   And on systems where other character set encoding is used, it is
   also the client software's responsibility to convert a natively
   displayed handle to its UTF-8 encoding before sending it out
   for resolution.

4.2 Handle Resolution service from Web browsers

   Handles specified using Handle URI Syntax (ie, hdl:<HandleRef>)
   can be resolved from a Web browser directly using the Handle
   System Resolver [4]. The Resolver is a freely available
   extension to the current popular Web browsers. It resolves
   handles into corresponding URIs, which are then retrieved by
   the browser in the normal fashion.  This is the suggested way
   to resolve the handles in the future, because it provides
   better performance, is more scalable, and is locally

   Handles can also be resolved using proxy services using Handle
   Proxy Syntax (ie, http:<proxy>/<handle>). In this case, the
   proxy server performs the handle resolution task, and sends
   the resulting URL to the client browser for processing.
   Currently, CNRI provides global handle proxy server through
   "", and "". The proxy server allows
   handles to be resolved without additional software for the
   client. For example, a handle "cnri.dlib/july95-arms" may be
   entered as ""
   resolvable by any browser.

   It is worth noting that even though using the proxy server
   approach is straight-forward and doesn't require any customer
   software customization, it has the effect of connecting the
   handles with the proxy server's URL location. Hence the
   selection of a proxy server should be made with care.

4.3 Creating handles for network resources

   The Handle System allows handles to be created in a distributed
   fashion. Organizations in need of providing a naming service
   for their persistent internet resources will be able to contact
   CNRI or other organizations to register for their own handle
   naming authority, as well as their own local handle services.
   This will enable them to create handles for their own
   organizational use. Policies and procedures for Naming Authority
   registration are currently under development.

   As an initiative for general public service, CNRI has established
   a public handle registration service for the IETF community. This
   service provides an open channel to allow individuals to create
   handles and experiment with the handle system. The service is
   provided for testing purposes only. Future availability of this
   service is not guaranteed. Details on how to use this service, as
   well as its terms and conditions can be obtained from

5. Handle System Service Architecture

   The Handle System is distributed, scalable, and designed for
   widespread deployment. The current implementation consists of one
   global service and many local handle services. Each handle
   service consists of one of more physically distributed handle
   servers. (Currently, the global service consists of two servers
   in Virginia and two in California. A European location is
   planned.) And each handle server can have one or more secondary
   servers for mirroring. In addition, handle caching servers are
   provided for faster resolution service for a local environment,
   and they can also be used to provide proxy service through

5.1 Handle services

   The Handle System consists of many services. Each service is
   responsible for part of the handle namespace. One specific
   service, called the Global Handle Registry, is globally unique,
   and has a special function, which is to know of the existence,
   location, and namespace responsibilities of all other public
   services, or local handle services. There can be an unlimited
   number of local handle services, managed by various organizations.
   In the current implementation each local handle service is
   registered with the Global Handle Registry to ensure efficient
   resolution. Policies and procedures for disconnected local handle
   services are under development. The primary issue here is to
   guarantee identifier uniqueness in disconnected systems.

5.2 Handle servers within a service

   Each handle service consists of one or more handle servers.
   Typically, each handle server runs on a separate computer but
   multiple handle servers can run on a single computer. Within a
   handle service, the distribution of handles across its constituent
   servers is determined by a hash table such that each of N servers
   within a service will be responsible for 1/N handles. The number
   of servers can be adjusted as required to meet the needs of a

5.3 Server replication

   Additionally, it may be desirable to mirror the contents of any of
   the handle servers within a service, presumably on a separate
   computer. This is referred to as replication and is accomplished
   by creating one or more additional servers whose sole purpose is
   to mirror the contents of the original server. Within each set of
   replicated servers, the initial server is called the primary server
   and all others are called secondary servers. The creation and
   administration of handles always takes place on the primary server,
   but resolution can use either the primary or any of its secondaries.
   This provides fault tolerance, as well as the potential for
   performance improvement.

5.4 Caching Server

   The Handle System Caching Server has been built to reduce the
   network traffic between handle clients and handle services and
   its use is strongly encouraged. Caching handle data or routing
   information on the caching server allows some handle resolution
   to be performed within an organization's local area network.

5.5 Proxy Server

   The Handle System Proxy Server has been developed to act as a
   client to the Handle System, allowing handles to be resolved using
   Handle Proxy Syntax (ie, http:<proxy server>/<handle>). Using
   this syntax, the browser passes a handle to the proxy server,
   which in turn passes the handle to the appropriate handle
   service for resolution. If the handle can be resolved into one
   or more URLs, a URL is returned from the handle
   server to the proxy, and from the proxy to the client browser.

5.6 Handle System Resolver

   The Handle System Resolver [4] is a software component which
   extends Netscape or Microsoft Web browsers, and allows handles
   to be resolved using Handle URI Syntax (ie, hdl:<handle>). Using
   this syntax, the browser passes the handle directly to the
   appropriate handle service for resolution. If the handle can
   be resolved into one or more URLs, one of the URLs is returned to
   the browser which then transparently retrieves and displays the
   intended content.

6. Handle resolution

   Handle clients and handle services use the Handle Resolution
   Protocol [5] to conduct resolution transactions. The Handle
   Resolution protocol uses registered port number 2641. By
   default, a handle resolution request will be answered with
   all of the typed data associated with a handle, with the
   exception of the administrative data. It is also possible
   to request data only of a certain type.

   Handle clients that do not know which handle service to
   query for a given handle start with the Global Handle
   Registry, which is guaranteed to know which service contains
   a given handle. Within a given service, a client uses the hash
   table specific to the service to discover the individual
   server, or set of replicated servers, which can resolve the
   given handle.

   A number of handle resolution clients have been constructed,
   all of which utilize the Handle Client Library [6], which
   is currently implemented as a C library. The clients include
   a Web proxy server, the Handle System Resolver [4], and the
   Grail Web browser [7].

7. Handle administration

   Handle System administration is carried out using the
   Handle System Administration Protocol [8]. This protocol
   allows the creation and administration of handles and their
   associated data within the Handle System.  A series of APIs
   currently under construction on top of this protocol will be
   made publicly available.

8. Security Consideration

   The Handle System has been designed to enable secure
   transactions between clients and servers and to allow
   secure and stable storage of handle data. Development and
   documentation of secure practices and policies is underway.

   A handle does not in itself pose a security threat. When
   specified or used in URL context, it is subject to all
   the security considerations in the URL specification [3].

9. Handle System and URL/URN/URI

   While the Handle System is designed to be usable in many
   contexts and is not a subset or extension of current UR* schemes,
   it can be used in conjunction with those schemes. When used
   within those schemes it is, of course, subject to their
   constraints. The Handle System is designed to provide all the
   fundamental requirements outlined in the URN/URI specifications
   [9,10]. On the other hand, the Handle System differs from the
   current proposed URN implementations [11,12,13] discussed in the
   IETF URN working group in the following ways.

   First of all, the Handle System defines a namespace independent
   of URI, and is not subject to the current namespace constraints
   of URI. The namespace of handles is Unicode based, and imposes no
   reserved or excluded characters on the handle string. This
   allows handles to be specified in any national language natively
   in a globally unique and unambiguous manner. The elimination of
   any reserved characters also allows any legacy naming system,
   such as SICI [14], to be used with no or minimum change.

   The Handle System is designed to support, instead of exclude, the
   use of user friendly names in any native language. There are
   situations in which using descriptive names may hurt the persistence
   of the name once the identified object changes its association.
   Objects of this nature may be better served using non-descriptive
   names; for example, digits only. On the other hand, there are
   objects for which descriptive names are desirable.

   The current URN/URI was defined "generally to be for machine,
   rather than human, consumption" [20]. It uses a subset of ASCII
   character set, and requires a set of reserved/excluded characters.
   A Human Friendly Name Service is expected to work with it.

   URN services may be used to resolve handles from the Handle System.
   For example, the handle "cnri.dlib/july95-arms" may be specified as
   "urn:hdl:cnri.dlib/july95-arms". This will allow any URN-aware
   browsers to resolve the handle as a URN. Handles specified as an URN
   must follow the URN syntax [13].

10. History and Acknowledgment

   The initial design and implementation of the Handle System was
   part of the Computer Science Technical Reports project, funded by
   the Defense Advanced Projects Agency (DARPA) under Grant No.
   MDA-972-92-J-1029. One aspect of this project was to develop a
   framework for the underlying infrastructure of digital libraries.
   It is described in a paper by Robert Kahn and Robert Wilensky [15].
   The first implementation was created at CNRI in the fall of 1994.
   Subsequent work on the Handle System has been supported in part
   by the Advanced Research Projects Agency under Grant No.

   The following people have contributed to the Handle System design
   and implementation: David Ely, William Arms, Navjeet Chabbewal,
   Judith Grass, Robert Kahn, Timothy Kendall, Connie McLindon,
   Charles Orth, Ed Overly, Varna Puvvada, John Stewart, Allison
   Yu-McNamara, Ron Ely, Catherine Rey, Jane Euler, Larry Lannom,
   and Sam Sun. We also want to acknowledge the contribution of the
   other members of the Computer Science Technical Reports project.

11. Author's Address

   Sam X. Sun
   1895 Preston White Dr.
   Suite 100
   Reston, VA 20191-5434
   (703) 620-8990

12. References

   [1]  The Unicode Consortium, "The Unicode Standard,
        Version 2.0", Addison-Wesley Developers Press, 1996.
        ISBN 0-201-48345-9

   [2]  Yergeau, Francois, "UTF-8, A Transform Format for Unicode
        and ISO10646", RFC2044, October 1996.

   [3]  Berners-Lee, T., Masinter, L., McCahill, M., et al.,
        "Uniform Resource Locators (URL)", RFC1738, December 1994.

   [4]  Handle System Resolver.

   [5]  Handle System Client Library download site.

   [6]  Handle Resolution Protocol.

   [7]  The Grail Internet Browser.

   [8]  Handle Administration Protocol.

   [9]  Sollins, K. and L. Masinter, "Functional Requirements
        for Uniform Resource Names", RFC 1737, December 1994.

   [10] Berners-Lee, T., "Universal Resource Identifiers
        in WWW" RFC 1630, June 1994.

   [11] Daniel, Ron and Michael Mealling, "Resolution of
        Uniform Resource Identifiers using the Domain Name
        System", RFC 2168, June 1997.

   [12] Daniel, Jr., Ron, "A Trivial Convention for using
        HTTP in URN Resolution", RFC-2169, June 1997.

   [13] Moats, Ryan, "URN Syntax", RFC-2141, May 1997.

   [14] Serial Item and Contribution Identifier (SICI) Standard.

   [15] Kahn, Robert and Wilensky, Robert. "A Framework for
        Distributed Digital Object Services", May, 1995.

   [16] Digital Object Identifier System.

   [17] National Digital Library Program.

   [18] The CNRI Registry.

   [19] Defense Virtual Library.

   [20] Sollins, K., "Architectural Principles of Uniform Resource
        Name Resolution", September 26, 1997, Work in Progress.

   [21] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997,

   [22] T. Berners-Lee, L. Masinter, R. Fielding, "Uniform Resource
        Identifiers (URI): Generic Syntax", work in progress,
        June 1998,

   [23] List of IANA registered charset names.

Expires Jan 16, 1999