Request for Comments: 3650 L. Lannom
Category: Informational B. Boesch
CNRI
November 2003
Handle System Overview
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
IESG Note
Several groups within the IETF and IRTF have discussed the Handle
System and its relationship to existing systems of identifiers. The
IESG wishes to point out that these discussions have not resulted in
IETF consensus on the described Handle System, nor on how it might
fit into the IETF architecture for identifiers. Though there has
been discussion of handles as a form of URI, specifically as a URN,
these documents describe an alternate view of how namespaces and
identifiers might work on the Internet and include characterizations
of existing systems which may not match the IETF consensus view.
Abstract
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 URNs. The
Handle System is a general-purpose global name service that allows
secured name resolution and administration over networks such as the
Internet. The Handle System manages handles, which are unique names
for digital objects and other Internet resources.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivations. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Handle Namespace . . . . . . . . . . . . . . . . . . . . . . . 7
4. Handle System Architecture . . . . . . . . . . . . . . . . . . 8
5. Handle System Security . . . . . . . . . . . . . . . . . . . . 11
6. The Handle System and other Internet Services. . . . . . . . . 12
6.1. Domain Name Service (DNS). . . . . . . . . . . . . . . . 13
6.2. Directory Services (X.500/LDAP). . . . . . . . . . . . . 13
6.3. Uniform Resource Identifier (URI)/Uniform Resource Name
(URN). . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
7.1. General Security Practice. . . . . . . . . . . . . . . . 15
7.2. Privacy Protection . . . . . . . . . . . . . . . . . . . 16
7.3. Caching and Proxy Servers. . . . . . . . . . . . . . . . 16
7.4. Mirroring. . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. Denial of Service (DoS). . . . . . . . . . . . . . . . . 17
8. History of the Handle System . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References and Bibliography. . . . . . . . . . . . . . . . . . 19
11. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 20
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21
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. This allows 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 Handle System supports secured handle
resolution. Security services such as data confidentiality, data
integrity, and non-repudiation are provided upon client request.
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) remains 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. Combined
with the unique naming authority, any local name is guaranteed unique
under the global handle namespace.
There are several services used today to provide name service for
Internet resources. Among these, 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 raised demands for various extensions to
DNS. There are also attempts to use DNS as a general-purpose
resource naming system. However, the importance of DNS in basic
network routing has led to great caution in implementing any DNS
extension or overloading the DNS for general-purpose resource naming.
An additional factor which argues against using DNS as a general-
purpose naming service is the DNS administrative model. DNS names
are typically managed by the network administrator(s) at the DNS zone
level. There is no provision for per-name administrative structure
and no facilities for anyone other than the network administrator to
create or manage DNS names. This is appropriate for domain name
administration, but less so for general-purpose resource naming.
The Handle System has been designed from the start to serve as a
general-purpose naming service. It is designed to accommodate very
large numbers of entities and to allow distributed administration
over the public Internet. The Handle System data model allows access
control to be defined at the level of each of the data values
associated with a given handle. Each handle can further define its
own set of administrators that are independent from the network or
host administrator.
Traditional 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
a DNS name and a local name provides a flexible administrative model
for naming and managing individual Internet resources. However, the
URL practice also has some key limitations. Most URL schemes (e.g.,
http) are defined for resolution 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. For example, a URL will be
tied 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. It is especially difficult to work around
this problem when the reason for the location change is change in
ownership of an asset, as ownership is generally reflected in the
domain name.
The Handle System is designed to overcome these limitations and to
add significant functionality. Specifically, the Handle System is
designed with the following objectives:
- Uniqueness: Every handle is globally unique within the Handle
System.
- Persistence: Handles may be used as persistent identifiers for
Internet resources. A handle does not have to be derived from
the entity that it names. 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 so as to distribute the service
load.
- Multiple Attributes: A single handle can refer to multiple
attributes of a resource, including associated services,
available through any method at different and possibly changing
network locations. Handles can thus be used as persistent
entry points into an evolving world of services associated with
identified resources.
- 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
3.0 [17], which includes most of the characters currently used
around the world. This allows handles to be used 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 by a corresponding local handle service, 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 System allows secured name
resolution and administration over the public Internet. The
Handle System protocol defines standard mechanisms for both
client and server authentication, as well as service
authorization. It also provides security options to assure
data integrity and confidentiality.
- Distributed Administration Service: Each handle may define its
own administrator(s) or administrator group(s). Ownership of
each handle is defined in terms of its administrator or
administrator groups. This, combined with the Handle System
authentication protocol, allows any handle to be managed
securely over the public network by its administrator 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]). Details of
the handle system data and service model, as well as its
communication protocol, are specified in separate documents. They
can be found under the Handle System website at
http://www.handle.net.
2. Motivations
Since there are a number of name related projects in the Internet
community, it is worth defining exactly where we believe the Handle
System fits. Unfortunately, that is particularly hard because the
other primary naming schemes either take an abstract services
approach (e.g., URI/URN), or an approach to name resolution absent of
a self-contained framework for reliable yet distributed
administration of the underlying databases (e.g., DNS). This makes
categorizing the Handle System difficult.
The Handle System crosses boundaries. Looked at as a name resolution
system, it might be compared to DNS. If used to implement a URI/URN
namespace, it could be used with any URI/URN scheme. If used for
distributed information updates and administration, it could be
considered a simplified-version of a distributed database system.
It is probably best to view the Handle System as a name-attribute
binding service with a specific protocol for securely creating,
updating, maintaining, and accessing a distributed database. It is
designed to be an enabling service for secured information and
resource sharing over networks such as the public Internet.
Applications of the Handle System could include meta-data services
for digital publications, identity management services for virtual
identities, or any other applications that require resolution and/or
administration of globally unique identifiers.
In the spirit of exploration, the Handle System has been designed to
have high performance for name resolution and to push the boundaries
of distributed access control and administration. Unlike most
conventional systems (even distributed systems) that are designed to
have a relatively small number of broadly empowered administrators,
the Handle System allows extremely fine granularity of administrative
control. It has a unique self-contained administrative framework
that de-couples the ownership of each handle from the system
administrators and allows access control to be defined for each
handle value.
It should be noted, that as with all real systems, the Handle System
is a compromise between a number of technical and practical concerns.
There are also different opinions within the IETF on where the Handle
System fits in relation to other existing Internet name services. It
is with the goal of exposing a broader community to the concepts,
approach, specific decisions, tradeoffs and results that we are
writing this RFC.
3. 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:
<Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>
The naming authority and local name are separated by the ASCII
character "/". The collection of local names under a naming
authority defines the local handle 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.
For example, "10.1045/january99-bearman" is a handle for an article
published in D-Lib magazine [12]. Its naming authority is "10.1045"
and its local name is "january99-bearman". The handle namespace can
be considered a superset of many local namespaces, with each local
namespace having a unique naming authority under the Handle System.
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 so
that any local name under the namespace can be globally referenced as
a combination of the naming authority and the local name as shown
above.
Naming authorities under the Handle System are defined in a
hierarchical fashion resembling a tree structure. Each node and leaf
of the tree is given a label that corresponds to a naming authority
segment. The parent node notifies 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 has been
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.
Handles may consist of any printable characters from the Universal
Character Set (UCS-2) of ISO/IEC 10646, which is the exact character
set defined by Unicode v3.0 [17]. 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
to prevent ambiguity among different encodings, the Handle System
protocol mandates UTF-8 to be the only encoding used for handles.
The UTF-8 encoding preserves any ASCII encoded names so as to allow
maximum compatibility with existing systems without causing naming
conflict. Some encoding issues over the global namespace and the
choice of UTF-8 encoding are discussed in [13].
By default, handles are case sensitive. However, any individual
handle service may define its namespace such that ASCII characters
within any handle under that namespace are case insensitive.
4. Handle System Architecture
The Handle System defines a hierarchical service model. The top
level consists of a single handle service, known as the Global Handle
Registry (GHR). The lower level consists of all other handle
services, generically known as Local Handle Services (LHS).
The Global Handle Registry can be used to manage any handle
namespace. It is unique among handle services only in that it
provides the service used to manage naming authorities, all of which
are managed as handles. The naming authority handle provides
information that clients can use to access and utilize the local
handle service for handles under the naming authority.
Local Handle Services are intended to be hosted by organizations with
administrative responsibility for handles under certain naming
authorities. A Local Handle Service may be responsible for any
number of local handle namespaces, each identified by a unique naming
authority. The Local Handle Service and its responsible set of local
handle namespaces must be registered with the Global Handle Registry.
One important aspect of the Handle System is its distributed
architecture. The Handle System as a whole consists of a number of
individual handle services. Each of these services may consist of
one or more service sites. Each service site is a complete
replication of every other site in the service in terms of handle
resolution. Each service site may consist of one or more handle
servers. All handles, and hence all handle requests, directed at a
given service site will be evenly distributed across these handle
servers. The Handle System as a whole may consist of any number of
handle services. There are no design limits on the number of handle
services or on the number of sites which make up each service, nor
are there any limits on the number of servers that make up each site.
Replication among any service site does not require that each site
contain the same number of servers. In other words, 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, accommodate any
large-scale of operation, and mitigate problems of single point
failure.
Figure 3.1 illustrates a potential handle service that consists of
two service sites: one located on the U.S. east coast and the other
on the U.S. west coast. The east coast service site consists of four
server computers. The west coast service site, with more powerful
computers deployed, decides two servers will suffice. The number of
service sites for any handle service, as well as the number of
servers that are used by any service site, may be added or removed
dynamically depending on the service requirement.
------------------------- ------------------
| --------- --------- | | ----- ----- |
| | | | | | | | S | | S | |
| | server1 | | server2 | | | | E | | E | |
| | | | | | | | R | | R | |
| --------- --------- | | | V | | V | |
| --------- --------- | | | E | | E | |
| | | | | | | | R | | R | |
| | Server3 | | Server4 | | | | | | | |
| | | | | | | | 1 | | 2 | |