Network Working Group                                 Sam X. Sun
INTERNET-DRAFT                                        Larry Lannom
draft-sun-handle-system-03.txt                        CNRI
                                                      July, 1999


                      Handle System Overview


Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. 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 progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].


Abstract

The Handle System is a general-purpose global name service that allows
secured name resolution and administration over the public Internet.
The Handle System manages handles, which are unique names for digital
objects and other Internet resources. This document provides an
overview of the Handle System in terms of its namespace and service
architecture, as well as its relationship to other Internet services
such as DNS, LDAP/X.500, and URN.

1. Introduction

This document provides an overview of the Handle System½, a distributed
information system designed to provide an efficient, extensible, and
secured global name service for use on networks such as the Internet.
The Handle System includes an open protocol, a namespace, and a
reference implementation of the protocol. The protocol enables a
distributed computer system to store names, or handles, of digital
resources and resolve those handles into the information necessary to
locate, access, and otherwise make use of the resources. These
associated values 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
current state information. Each handle may have its own
administrator(s) and administration can be done in a distributed
environment. The name-to-value bindings may also be secured, allowing
handles to be used in trust management applications.

The Handle System provides a confederated name service that allows any
existing local namespace to join the global handle namespace by
obtaining a unique handle system naming authority. Local names and
their value-binding(s) remain intact after joining the Handle System.
Any handle request to the local namespace may be processed by a service
interface speaking the handle system protocol which would map the
handle request into the local name. Combined with the unique naming
authority, any local name is guaranteed unique under the global handle
namespace.

There are several services that are in use today to provide name
service for Internet resources, of which the Domain Name System (DNS)
[2,3] is the most widely used. DNS is designed "to provide a mechanism
for naming resources in such a way that the names are mappable into IP
addresses and are usable in different hosts, networks, protocol
families, internets, and administrative organizations" [3]. The growth
of the Internet has increased demands for various extensions to DNS,
and even its use as a general purpose resource naming system, but its
importance in basic network routing has led to great caution in
implementing such extensions and a general conclusion that DNS is not
the place to look for general purpose resource naming. An additional
factor which argues against using DNS as a general purpose naming
system is the DNS administrative model. DNS names are typically managed
by the network administrator(s) at the DNS zone level, with no
provision for a per name administrative structure, and no facilities
for anyone other than network administrators to create or manage names.
This is appropriate for domain name administration but less so for
general purpose resource name administration. The Handle System has
been designed from the start to serve as a naming system for very large
numbers of entities and to allow administration at the name level. The
handle system data model allows access control to be defined at the
level of each handle data. Each handle can further define its own
administrator(s) to manage the handle data via the handle system
authentication protocol.

URLs (Uniform Resource Locators) [4] allow certain Internet resources
to be named as a combination of a DNS name and local name. The local
name may be a local file path, or a reference to some local service,
e.g. a cgi-bin script. This combination of DNS name and local name
provides a flexible administrative model for naming and managing
individual Internet resources. There are, however, several key
limitations. Most URL schemes (e.g., http) are defined for resolution
service only. Any URL administration has to be done either at the local
host, or via some other network service such as NFS. Using a URL as a
name typically ties the Internet resource to its current network
location, and to its local file path when the file path is part of the
URL. When the resource moves from one location to another, for whatever
reason, the URL breaks.

The Handle System is designed to overcome these limitations and to add
significant increased functionality. Specifically, the Handle System is
designed with the following objectives:

Uniqueness: Every handle is globally unique within the Handle System.

Persistence: A handle is not derived in any way from the entity which
it names, but is assigned to it independently. While an existing name,
or even a mnemonic, may be included in a handle for convenience, the
only operational connection between a handle and the entity it names is
maintained within the Handle System. This of course does not guarantee
persistence, which is a function of administrative care, but it does
allow the same name to persist over changes of location, ownership, and
other state conditions. For example, when a named resource moves from
one location to another, the handle may be kept valid by updating its
value in the Handle System to reflect the new location.

Multiple Instances: A single handle can refer to multiple instances of
a resource, at different and possibly changing locations in a network.
Applications can take advantage of this to increase performance and
reliability. For example, a network service may define multiple entry
points for its service with a single handle and so distribute the
service load.

Extensible Namespace: Existing local namespaces may join the handle
namespace by acquiring a unique handle naming authority. This allows
local namespaces to be introduced into a global context while avoiding
conflict with existing namespaces. Use of naming authorities also
allows delegation of service, both resolution and administration, to a
local handle service.

International Support: The handle namespace is based on Unicode 2.0
[1], which includes most of the characters currently used around the
world, facilitating the use of the system in any native environment.
The handle protocol mandates UTF-8 [5] as the encoding used for
handles.

Distributed Service Model: The Handle System defines a hierarchical
service model such that any local handle namespace may be serviced
either by a corresponding local handle service or by the global service
or by both. The global service, known as the Global Handle Registry,
can be used to dispatch any handle service request to the responsible
local handle service. The distributed service model allows replication
of any given service into multiple service sites and each service site
may further distribute its service into a cluster of individual
servers. (Note that local here refers only to namespace and
administrative concerns. A local handle service could in fact have many
service sites distributed across the Internet.)

Secured Name Service: The handle protocol allows handle servers to
authenticate their clients and to provide data integrity service upon
client request. Public key and/or secret key cryptography may be used.
This may be used to prevent eavesdroppers from forging client requests
or tampering with server responses.

Distributed Administration Service: Each handle may define its own
administrator(s) or administrative group(s). This, combined with the
handle system authentication protocol, allows handles to be managed
securely over the public network by authorized administrators at any
network location.

Efficient Resolution Service: The handle protocol is designed to allow
highly efficient name resolution performance. To avoid resolution being
affected by computationally costly administration service, separate
service interfaces (i.e., server processes and their associated
communication ports) for handle name resolution and administration may
be defined by any handle service.

This document provides an overview of the handle namespace and service
architecture. It also compares the Handle System with other existing
Internet services, protocols, and specifications (e.g., DNS [2,3], URLs
[4], X.500/LDAP [6.7.8], and URN [9,10]). Other planned documents
describing the Handle System include: The "Handle Namespace and Service
Definition" [11] describing the handle namespace syntax and its
semantics. It will also present the handle data and service model. The
"Handle Protocol Specification" [12] specifying the message layout of
the handle protocol between and among handle clients and servers. The
"Handle Application Programming Interface (API) Specification" [13]
describing a high-level application programming interface for
developing applications using handle service. Finally, the "Handle URI
Syntax" [14] will specify the syntax for handles as used in the world-
wide-web environment.

2. Handle Namespace

Every handle consists of two parts: its naming authority, otherwise
known as its prefix, and a unique local name under the naming
authority, otherwise known as its suffix. The naming authority and
local name are separated by the ASCII character "/". A handle may thus
be defined as

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

For example, "10.1045/january99-bearman" is a handle for an article
published in D-Lib magazine [15]. It is defined under the Handle Naming
Authority "10.1045", and its Handle Local Name is "january99-bearman".
(For details of handle syntax definition, see "Handle System Namespace
and Service Definition" [11].)

The handle namespace can be considered as superset of many local
namespaces, with each local namespace having its own unique handle
naming authority. The naming authority identifies the administrative
unit of creation, although not necessarily continuing administration,
of the associated handles. Each naming authority is guaranteed to be
globally unique within the Handle System. Any existing local namespace
can join the global handle namespace by obtaining a unique naming
authority, with the resulting handles being a combination of naming
authority and local name as shown above.

Handles may consist of any printable characters from the Universal
Character Set, two-octet form (UCS-2) of ISO/IEC 10646, which is the
exact character set defined by Unicode v2.0. The UCS-2 character set
encompasses most characters used in every major language written today.
To allow compatibility with most of the existing systems and prevent
ambiguity among different encoding, handle protocol mandates UTF-8 to
be the only encoding used for handles. The UTF-8 encoding preserves any
ASCII encoded names, which allows maximum compatibility to existing
systems without causing naming conflict. Some encoding issues over the
global namespace and the choice of UTF-8 encoding are discussed in
[16].

By default, handles are case sensitive. However, any handle service,
including the global service, may define its namespace such that all
ASCII characters within any handle are case insensitive.

Handle naming authorities are defined in a hierarchical fashion, i.e.,
a tree structure. Each node and leaf of the tree is given a label that
corresponds to a naming authority segment. The parent node presents the
parent naming authority of its child nodes. Unlike DNS, handle naming
authorities are constructed left to right, concatenating the labels
from the root of the tree to the node that represents the naming
authority. Each label is separated by the octet used for ASCII
character "." (0x2E). For example, a naming authority for the National
Digital Library Program ("ndlp") at the Library of Congress ("loc") is
defined as "loc.ndlp".

Each naming authority may have many child naming authorities registered
underneath. Any child naming authority can only be registered by its
parent after its parent naming authority is registered. However, there
is no intrinsic administrative relationship between the namespaces
represented by the parent and child naming authorities. The parent
namespace and its child namespaces may be served by different handle
services, and they may or may not share any administration privileges
among each other.

Every handle is defined under a naming authority. The naming authority
and the local name are separated by the octet used for ASCII character
"/" (0x2F). The collection of local names under a naming authority is
the local namespace for that naming authority. Any local name must be
unique under its local namespace. The uniqueness of  a naming authority
and a local name under that authority ensures that any handle is
globally unique within the context of the Handle System.

3. Handle System Architecture

The Handle System defines a hierarchical service model. The top level
consists of a single global service, known as the Global Handle
Registry. The lower level consists of all other handle services, which
are generically known as local handle services. The Global Handle
Registry provides a handle service (for resolution) and can be used to
manage any handle namespace. It is unique among handle services only in
that it provides the service used to manage the namespace of handle
naming authorities, all of which are managed as handles. The state
information of these naming authority handles is the service
information that clients can use to access and utilize associated local
services.

The local handle service layer consists of all local handle services
managing all handles under their naming authorities, providing
resolution and administration service for these local names. Local
services are intended to be hosted by organizations with administrative
responsibility for the handles within the service or acting on behalf
of the responsible organizations.

A second important aspect of Handle System architecture is its
distributed nature. The Handle System as a whole consists of a number
of individual handle services, each of which consists of one or more
handle service sites, where each site replicates the complete
individual handle service, at least for the purposes of handle
resolution. Each handle service site in turn consists of one or more
handle servers. There are no design limits on the total number of
handle services which constitute the Handle System, there are no design
limits on the number of sites which make up each service, and there are
no limits on the number of servers which make up each site. Replication
by site, within a service, does not require that each site contain the
same number of servers; that is, while each site will have the same
replicated set of handles, each site may allocate that set of handles
across a different number of servers. This distributed approach is
intended to aid scalability and to mitigate problems of single point
failure.

Figure 3.1 illustrates a potential handle service that consists of two
service sites, one located at the US East coast and the other at the US
West coast. The East coast service site consists of four host computers
that process all the client requests, and the West coast service site,
with more powerful computers deployed, decides two host servers will
suffice. The number of service sites for any Handle System, as well as
the number of servers that are used by any service site, may be added
or removed dynamically according to the service requirement.


    -------------------------              ------------------
   |  ---------   ---------  |            |  -----    -----  |
   | |         | |         | |            | |  S  |  |  S  | |
   | | server1 | | server2 | |            | |  E  |  |  E  | |
   | |         | |         | |            | |  R  |  |  R  | |
   |  ---------   ---------  |            | |  V  |  |  V  | |
   |  ---------   ---------  |            | |  E  |  |  E  | |
   | |         | |         | |            | |  R  |  |  R  | |
   | | Server3 | | Server4 | |            | |     |  |     | |
   | |         | |         | |            | |  1  |  |  2  | |
   |  ---------   ---------  |            |  -----    -----  |
    -------------------------               ------------------

      Handle Service Site 1                Handle Service Site 2
         (US East Coast)                     (US West Coast)


    Fig. 3.1 Handle service configured with two service sites.


Each handle service manages a sub-namespace under the Handle System.
The sub-namespace typically consists of handles under a number of
naming authorities. The handle service is called the "home" service of
these naming authorities and is the only one that provides resolution
and administration service for its handles. Before resolving a handle,
a client has to determine the "home" service of the handle in question.
The "home" service of each handle is the "home" service of its naming
authority and is registered at the Global Handle Registry. This
determination is carried out by the client software.

The Global Handle Registry manages naming authority handles. Each
naming authority handle maintains the service information that
describes the "home" service of the naming authority. The service
information lists the service sites of the handle service, as well as
the interface to each handle server within each site. To find the
"home" service for any handle, a client can query the Global Handle
Registry for the service information that is maintained by the
corresponding naming authority handle. The service information provides
the necessary information for clients to communicate with the "home"
service for any request.

Figure 3.2 shows an example of a typical handle resolution process
where the "home service" is a local handle service. In this case, the
client is trying to resolve the handle "cnri.dlib/july95-arms" and has
to find its "home" service from the global handle registry. The "home"
service is determined by sending a query to the Global Handle Registry
for the corresponding naming authority handle. The Global Handle
Registry returns the service information that describes the local
handle service that is responsible for handles under the naming
authority "cnri.dlib", including the handle "cnri.dlib/july95-arms".
The service information allows the client to identify the local handle
service in order to resolve the handle.



   ------------------------
  |                        |    4. Result of client request
  | Client with global     |  <-------------------------------.
  |  service information   |                                  |
  |                        |  ----------------------------.   |
   ------------------------     3. Request to responsible |   |
             |   ^                 local handle service   |   |
 1. Client   |   |                                        |   |
 query for   |   |                                        |   |
 naming      |   | 2. Service information                 |   |
 authority   |   |    for "cnri.dlib"                     V   |
 "cnri.dlib" |   |                                -------------------
             |   |                               |                   |
             V   |                               | Local service     |
        ---------------                          | responsible for   |
       |               |                         | naming authority  |
       | Global Handle |                         | "cnri.dlib"       |
       |   Registry    |                         |                   |
       |               |                          -------------------
        ---------------

           Fig. 3.2  Handle resolution starting with global


To improve resolution performance, any client may choose to cache the
service information returned from the Global Handle Registry and use it
for subsequent queries. A separate handle caching server, either stand-
alone or as a piece of a general caching mechanism, may also be used to
provide shared caching within a local community. Given a cached
resolution result, subsequent queries of the same handle may be
answered locally without contacting any handle service. Given cached
service information, clients can send their requests directly to the
responsible handle service without contacting the Global Handle
Registry.

4. Handle System Service and Security

The Handle System provides handle resolution service, as well as handle
administration service over the public Internet. Each handle can be
assigned a set of values. Clients use the handle resolution service to
resolve any handle into its set of values. Each value has a data type
and a unique value index. Clients can query for specific handle values
based on data type or value index.

The handle administration service deals with client requests to manage
handles, including adding handles, deleting handles or updating their
values. It also deals with naming authority administration via naming
authority handles. Each handle can define its own administrator(s) and
each administrator is granted a certain set of permissions. The handle
system authentication protocol authenticates the handle administrator
before fulfilling any administrative request.

The Handle System provides authentication and data integrity services,
depending on client request. By default, the handle resolution service
does not require any client authentication. However, resolution
requests for confidential data assigned to any handle (by its
administrator), as well as all administration requests (e.g. adding or
deleting handle values) require authentication of the client as having
the requisite authority. When authentication is required, the
responsible handle server will issue a challenge to the requesting
client before carrying out the client's request. To satisfy the
authentication requirement, the client must send back the correct
response that identifies itself as the administrator or otherwise in
possession of the appropriate credentials. The handle server will
respond to the initial request only after successful authentication of
the client. Handle clients may choose to use either secret key or
public key cryptography for authentication.

Handle clients may also request digitally signed responses from any
handle server, to ensure data integrity. Additionally, any handle
server or its clients have the option to set up a secured communication
session. Information transferred within the secured session will be
encrypted with a session key to ensure data confidentiality.

The Handle System provides service options for the safe transmission of
information between client and server. This does not imply any
credentials of the handle values. Incorrect values assigned to handles
by any of the administrators may very well mislead clients. On the
other hand, any handle value record may contain references to other
handle value records to provide additional credentials. For example, a
value record R (e.g., a claim) of any handle may contain a reference to
some other value record (from another handle) that contains a digital
signature for the value record R. Clients who trust the signature could
then trust the value record R.

Handle system security depends on both client and server host security
at every step in the transaction. It assumes the client host has not
been tampered with and that client software will convey reliably the
received data to the client. The client of any handle service must also
assume that any handle servers involved have not been compromised. To
trust the Global Handle Service means to trust that it will rightfully
direct the client request to the responsible Handle Local Service. To
trust a Local Handle Service means to trust that it will correctly
respond with the data that was entered by the administrator. A Local
Handle Service typically supports a set of naming authorities. Thus,
trusting a Local Handle Service means trusting its naming authority.

5. The Handle System and other Internet Services

There are a number of existing and proposed Internet identifier
services or specifications that by design or intent cover some of the
functionality proposed for the Handle System. This section briefly
reviews them in relationship to the Handle System.

5.1 Domain Name Service (DNS)

The Domain Name Service, or DNS, was originally designed and is heavily
used for mapping domain names into IP Addresses for network routing
purposes. RFC1034 [2] and RFC1035 [3] provide detailed descriptions of
its design and implementation. The growth of the Internet has increased
demands for various extensions to DNS, and even its possible use as a
general purpose resource naming system. However, any such use has the
potential to slow down the network address translation, and alter its
effectiveness in network routing. DNS implementation typically does not
scale well when large amount of data is associated with any particular
DNS name, and is generally considered not adequate to support a very
large number of DNS names used for naming any kind of resources over
the Internet.

An additional factor that argues against using DNS as a general purpose
naming system is the DNS administrative model. DNS names are typically
managed by the network administrator(s) at the DNS zone level, with no
provision for a per name administrative structure, and no facilities
for anyone other than network administrators to create or manage names.
This is appropriate for domain name administration but less so for
general-purpose resource name administration.

The Handle System differs from DNS in its distributed administration
and service model, as well as its secured service protocol (see section
4). Each handle within the Handle System may define its own
administrator(s), and the Handle System defines a distributed
administration and access control model that allows an individual
handle and its contents to be managed securely over the public network.
The Handle System service model allows any of its service sites to
dynamically configure its service distribution among a cluster of
servers to accommodate increased service requests. This also allows
less powerful computers to be used together to support any huge number
of handles.

5.2 Directory Services (X.500/LDAP)

X.500 [6] is the OSI Directory Standard defined by ISO and the ITU. It
is designed "to provide a white pages service that would return either
the telephone numbers or X.400 O/R addresses of people", and is
"concerned mainly with providing the name server service for Open
Systems Interconnection (OSI) applications" [7]. X.500 defines a
hierarchical data and information model with a set of protocols to
allow global name lookup and search. The protocol, however, has proved
difficult to implement and there has been difficulty in getting "client
access integrated into existing products" [17]. LDAP (Lightweight
Directory Access Protocol) [8] has overcome many of these difficulties
by making the protocol simpler, and easier to implement. Some concern
remains, however, that as LDAP is emerging from a local directory
access protocol (LDAP v2) into a distributed service protocol (LDAP
v3), it faces many issues not addressed in its original design,
resulting in new complications [22].

The fundamental difference between a name resolution service such as
the Handle System and a directory service such as LDAP is search
capability. The added functionality of being able to search a directory
service necessarily carries with it added complexity. A pure name
service, such as the Handle System can, in comparison, be designed
solely around efficient resolution of known items without addressing
functions and data structures required for discovery of unknown items
based on incomplete criteria.

Directory services such as LDAP or WHOIS++ [18,19] may be used in
tandem with the Handle System to provide reverse name lookup service.
Existing corporate directory services, for example, could provide a
single interface to both services. The handle interface would provide a
highly efficient name resolution service, while the directory service
interface would provide an extended search capability. Handles could
also be used, for example, in LDAP service referral such that LDAP
services could be referenced independent of network location.

5.3 Uniform Resource Names (URN)

The IETF URN Working Group [23] has defined a syntax, possible
resolution mechanisms, and namespace registration procedure for a
resource identifier intended to cover a large array of existing and
potential namespaces. Namespaces are to be registered and assigned
unique Namespace Ids (NIDs). Any resolution services associated with
these namespaces require further registration with a Resolution
Discovery System (RDS) which clients could use to begin, or discover,
the appropriate resolution mechanisms.

The objectives and some of the approaches of the URN and Handle System
efforts have enough in common that some observers might think that they
are in contention. This is not the case. The URN effort is explicitly
designed to accommodate multiple identifier namespaces and resolution
systems. The Handle System is one such case, with a very specific data
and service model, and a protocol that supports name resolution and
administration. URNs and the Handle System may interact in variety of
ways, the most obvious of which is that handles could be registered as
a URN namespace, which is to say, they could be used as a type of URN.
It would also be possible to use the Handle System as a type of RDS for
other URN namespaces. The success of either system however, is not
dependent upon the success of the other.

6. History of the Handle System

The Handle System was originally conceived and developed at CNRI as
part of the Computer Science Technical Reports (CSTR) project, funded
by the Defense Advanced Projects Agency (DARPA) under Grant No. MDA-
972-92-J-1029. One aspect of this early digital library project, which
was also a major factor the evolution of the Networked Computer Science
Technical Reference Library (NCSTRL) [21] and related activities, was
to develop a framework for the underlying infrastructure of digital
libraries. It is described in a paper by Robert Kahn and Robert
Wilensky [20]. The first implementation was created at CNRI in the fall
of 1994 in an effort led by David Ely.

Early adopters of the Handle System have included the Library of
Congress, the Defense Technical Information Center (DTIC), and the
International DOI Foundation (IDF). Feedback from these organizations
as well as NCSTRL, other digital library projects, and related IETF
efforts as mentioned above have all contributed to the evolution of the
Handle System. Current status and available software, both client and
server, can be found at http://www.handle.net.

7. Acknowledgements

This work is derived from the earlier versions of the handle system
implementation. Design ideas are based on those discussed within the
handle system development team, including David Ely, Charles Orth,
Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, and Stephanie
Nguyen. Their contributions to this work are gratefully acknowledged.

8. AuthorËs Address

Sam X. Sun
Corporation for National Research Initiatives (CNRI)
1895 Preston White Dr.     Suite 100
Reston, VA 20191
USA
Phone:    703-262-5316
Email:    ssun@cnri.reston.va.us

Larry Lannom
Corporation for National Research Initiatives (CNRI)
1895 Preston White Dr.     Suite 100
Reston, VA 20191
USA
Phone:    703-620-8990
Email:    llannom@cnri.reston.va.us

9. References and Bibliography

[1] The Unicode Consortium, "The Unicode Standard, Version 2.0",
Addison-Wesley Developers Press, 1996, ISBN 0-201-48345-9
[2] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC1034,
November 1987, http://info.internet.isi.edu:80/in-
notes/rfc/files/rfc1034.txt
[3] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC1035, November 1987, http://info.internet.isi.edu:80/in-
notes/rfc/files/rfc1035.txt
[4] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform
Resource Locators (URL)", RFC1738, December 1994,
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1738.txt
[5] Yergeau, Francois, "UTF-8, A Transform Format for Unicode and
ISO10646", RFC2044, October 1996, http://info.internet.isi.edu:80/in-
notes/rfc/files/rfc2044.txt
[6] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models, and
Services", 1993.
[7] D W Chadwick, "Understanding X.500 - The Directory", Chapman & Hall
ISBN: 0-412-43020-7,
http://www.salford.ac.uk/its024/X500.htm
[8] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997,
http://info.internet.isi.edu/in-notes/rfc/files/rfc2251.txt
[9] Sollins, K., and L. Masinter, "Functional Requirements for Uniform
Resource Names", RFC 1737, December 1994,
http://info.internet.isi.edu/in-notes/rfc/files/rfc1737.txt
[10] Sollins, K. "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998, ftp://ftp.isi.edu/in-
notes/rfc2276.txt
[11] Sun, S., Reiley, S., Lannom, L., "Handle System Namespace
and Service Definition", ietf draft, work in progress.
[12] "Handle System Protocol Specification", work in progress.
[13] "Handle System Application Programming Interface (API)
Specification", work in progress.
[14] "Handle System URI Syntax", work in progress.
[15] D-Lib Magazine, http://www.dlib.org
[16] Sam X. Sun, "Internationalization of the Handle System - A
Persistent Global Name Service",
Proceeding of 12th International Unicode Conference, April, 1998,
http://www.cnri.reston.va.us/unicode-paper.ps
[17] D Goodman, C Robbins, "Understanding LDAP & X.500", August 1997,
http://www.eema.org/understanding_ldap.html
[18] Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
"Architecture of the Whois++ service", RFC 1835, August 1995,
http://info.internet.isi.edu/in-notes/rfc/files/rfc1913.txt
[19] Weider, C., J. Fullton, and S. Spero, "Architecture of the Whois++
Index Service", RFC 1913, February 1996,
http://info.internet.isi.edu/in-notes/rfc/files/rfc1914.txt
[20] Kahn, Robert and Wilensky, Robert. "A Framework for Distributed
Digital Object Services", May, 1995,
http://www.cnri.reston.va.us/tmp_hp/k-w.html
[21] The Networked Computer Science Technical Reports Library (NCSTRL),
http://www.ncstrl.org/
[22] David Goodman, Colin Robbins. "Understanding LDAP & X.500", August
1997,
http://www.eema.org/understanding_ldap.html
[23] IETF Uniform Resource Names (URN) Working Group, April, 1998,
http://www.ietf.org/html.charters/urn-charter.html