WDIFF

draft-sun-handle-system-01.txt --> draft-sun-handle-system-02.txt

INTERNET-DRAFT Larry Lannom
draft-sun-handle-system-02.txt CNRI
Expires July,
June, 1999 draft-sun-handle-system-01.txt

Handle System: A Persistent Global Name Service System Overview and Syntax

Status of this Memo

This document is an Internet-Draft. 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.

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."

To learn the current status

The list of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast). 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 (r) is a comprehensive system for assigning,
managing, general-purpose global name service that allows
secured name resolution and resolving persistent identifiers, known as
'handles' administration over the public Internet.
The Handle System manages handles, which are unique names for digital
objects and other resources 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.
Handles can be used as Uniform Resource Names (URNs).
The Handle System defines:(a) includes an open set of protocols, (b) protocol, a global namespace, and (c) a distributed service model that provides
reference implementation of the global name
service. protocol. The protocol enables a
distributed computer system allows Internet resources to be named as handles.
A handle may contain store names, or handles, of digital
resources and resolve those handles into the information necessary to locate
locate, access, and access
its named otherwise make use of the resources. This These
associated information 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.
Combined with Each handle may have its own
administrator(s) and administration can be done in a centrally administered naming authority registration
service, the 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 general purpose, distributed
global confederated name service for the reliable management of information on
networks over long periods of time. (Note that in this document we
do not attempt allows any
existing local namespace to distinguish between join the terms 'name' and
'indentifier' and will use them interchangably.)

1. Introduction

The Handle System is global handle namespace by
obtaining a distributed information unique handle system that provides
a persistent naming service for use on networks such as authority. Local names and
their value-binding(s) remain intact after joining the
Internet. Handles can be used to identify any network resources.

Each Handle System.
Any handle request to the local namespace may be assigned with processed by 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
interface speaking the handle administration service that allows individual handles to
have their own administrator(s) assigned, and be administrated over system protocol which would map the distributed environment.

The Handle System ensures that every
handle request into the local name. Combined with the unique naming
authority, any local name is guaranteed unique within under the
context global handle
namespace.

There are several services that are in use today to provide name
service for Internet resources, of which the Handle 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 may be retained are usable in different hosts, networks, protocol
families, internets, and resolved over
long time periods. administrative organizations" [3]. The resolution information associated with each
handle can be changed as needed, allowing growth
of the handle Internet has increased demands for various extensions to persist over
changes DNS,
and even its use as a general purpose resource naming system, but its
importance in location basic network routing has led to great caution in
implementing such extensions and other states of the named resource.

Specifically, a general conclusion that DNS is not
the Handle System was designed place to address the
following problems in network resource identification:

* Persistence

A named resource can outlast any specific computer system or
organization. Any look for general purpose resource name naming. An additional
factor which is inextricably linked
with argues against using DNS as a specific general purpose naming
system or name of an organization will not be
able to survive is the demise or radical change of that computer
system or organization. By separating DNS administrative model. DNS names are typically managed
by the network administrator(s) at the object's DNS zone level, with no
provision for a per name from
location, ownership, administrative structure, and no facilities
for anyone other state information, the Handle
System allows that identifier than network administrators to persist over time.

* Location independence

With handles, the create or manage names.
This is appropriate for domain name of administration but less so for
general purpose resource name administration. The Handle System has
been designed from the item is unrelated start to the location
of the item. This allows easy reorganization serve as a naming system for very large
numbers of information.
Handles make it possible entities and to transfer allow administration at the name level.

URLs (Uniform Resource Locators) [4] allow certain Internet resources from one
organization
to another without affecting be named as a combination of a DNS name and local name. The local
name may be a local file path, or breaking the
existing user references (i.e., handles) a reference to those collections. some local service,
e.g. a cgi-bin script. This is not possible using location based references.

* Multiple instances of an item

A single handle can refer to more than one instance combination of DNS name and local name
provides a network
resource. A network service may thus define multiple entry points flexible administrative model for its naming and managing
individual Internet resources. There are, however, several key
limitations. Most URL schemes (e.g., http) are defined for resolution
service with a single handle name. This allows 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 distribute its service load into multiple instances.

The Handle System has been implemented current network
location, and is currently in use in
a number of prototype projects, including efforts with to its local file path when the Library file path is part of Congress, the Association of American Publishers,
URL. When the Defense
Technical Information Center, and the United States Information
Agency.

This is the first of a series of planned documents that will
specify the handle protocol and services, and relate resource moves from one location to another, for whatever
reason, the URL breaks.

The Handle System is designed to other IETF activities in URN/URI/URL working groups.
This document provides a concise overview of the system overcome these limitations and to add
significant increased functionality. Specifically, 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 System is
designed with the following objectives:

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

Persistence: A handle is defined not derived 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 way from the
underlying handles. It entity which
it names, but 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) assigned to it independently. While an existing name,
or '/' (%x2F). ASCII characters even a mnemonic, may be included in a handle for convenience, the naming authority
are case insensitive
only operational connection between a handle 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 entity it names is
maintained within the Unicode 2.0. It Handle System. This of course does not
impose any reserved or excluded characters. ACSII characters
within guarantee
persistence, which is a function of administrative care, but it does
allow the local same name are case insensitive, to persist over changes of location, ownership, and are converted
into upper case before resolution taking place.

The following is
other state conditions. For example, when a named resource moves from
one location to another, the handle syntax described in ABNF [21]
notation:

<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 kept valid by updating its
value in the Handle System protocol:

cnri.dlib/july95-arms

10.1002/0002-8231(199601)47:1<1:SPOTEO>2.3.TX;2-K

any-printable-characters/a-zA-Z0-9!@#$%^&*()_"<>,.?/`~|\

handles-in-germany/Universit~{#?~}-Karlsruhe

3. Handle data to reflect the new location.

Multiple Instances: A single handle within the Handle System is associated with, 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 resolved to, one or more elements introduced into a global context while avoiding
conflict with existing namespaces. Use of typed data. Examples naming authorities also
allows delegation of
data types in use include URLs, object request brokers, service, both resolution and
other URNs. Other examples might include e-mail addresses or
public key certificates. There is administration, to a controlled set
local handle service.

International Support: The handle namespace is based on Unicode 2.0
[1], which includes most of named
types accepted by the system. This list can be extended as
needed at characters currently used around the
world, facilitating the use of the system level.

Each in any native environment.
The handle will also have its administrative data. protocol mandates UTF-8 [5] as the encoding used for
handles.

Distributed Service Model: The
administrative data, e.g., permissions to create handles or
edit Handle System defines a hierarchical
service model such that any local handle data, is initially provided namespace may be serviced
either by the a corresponding local handle server when service or by the handle was first created. global service
or by both. The administrative data global service, known as the Global Handle Registry«,
can be used to define the dispatch any handle administrator that manages service request to the responsible
local handle data.
This administrative data is not returned as part 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
resolution but is 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 only. 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 than planned documents
describing the relationship 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

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 Global Handle Registry
and local total number of
handle services described above, which constitute the Handle System, 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 design
limits on the World Wide Web

4.1 Handle URI syntax

The Handle Syntax in section 2 defines number of sites which make up each service, and there are
no limits on the encoding rules for
handles transferred over number of servers which make up each site. Replication
by site, within a service, does not require that each site contain the wire via
same number of servers; that is, while each site will have the Handle System protocol.
Handles same
replicated set of handles, each site may also be referenced as allocate that set of handles
across a URI [22], which can be used in
Web browsers or in HTML mark-up documents different number of servers. This distributed approach is
intended to refer aid scalability and to persistent
Internet resources. The Handle URI syntax defines mitigate problems of single point
failure.

Figure 3.1 illustrates a potential handle service that consists of two
service sites, one located at the syntax
rule for handles specified in US East coast and the URI format.

Handles defined as a Handle URI may be resolved by other at the Handle
System Resolver [4]. US
West coast. The Handle System Resolver will convert the
URI into East coast service site consists of four host computers
that process all the Handle (as defined in section 2) before doing client requests, and the
resolution. West coast service site,
with more powerful computers deployed, decides two host servers will
suffice. The number of service sites for any Handle URI Syntax is defined System, as follows:

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

<Encoding> = 1*40( %x01-7F )
; A registered charset name [23] from IANA,
; which well as
the number of servers that are used by any service site, may be any printable ASCII characters.

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

<HandleRef> = 1*( %x00-%xFF )
; Octets that encodes 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 <Handle> using the
; <encoding> in sub-namespace under the optional <Modifier>.
; If no <Modifier> specified, UTF-8 encoding
; Handle System.
The sub-namespace typically consists of handles under a number of
naming authorities. The handle service is called the default encoding.

When UTF-8 "home" service of
these naming authorities and is the encoding used, the Handle URI Syntax has two
reserved characters, % only one that provides resolution
and ". The character % is used administration service for hex encoding,
which is necessary its handles. Before resolving a handle,
a client has to allow any handles specified from the standard
keyboard. And determine the character " is reserved to allow handles to be
separated from "home" service of the surrounding text in HTML documents. Reserved
characters must be hex encoded when used handle in the URI context. question.
The
choice "home" service of % and hex encoding each handle is also compatible with the current URI
practice. Because some browser implementation (incorrectly!) drops
the # character when processing the URI regardless "home" service of its scheme, hex
encoding of character # naming
authority and is also recommended.

Examples of handles using registered at the Global Handle URI Syntax are:

hdl:cnri.dlib/july95-arms

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

and

hdl:handle-with-hex-encoding/handle%25abc

(which refers to Registry. This
determination is carried out by the client software.

The Global Handle Registry manages naming authority handles. Each
naming authority handle "handle-with-hex-encoding/handle%abc")

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

4.2 Handle Resolution server within each site. To find the
"home" service from Web browsers

Handles specified using Handle URI Syntax (ie, hdl:<HandleRef>)
can be resolved from for any handle, a Web browser directly using client can query the Global Handle
System Resolver [4]. The Resolver is a freely available
extension to
Registry for the current popular Web browsers. It resolves
handles into corresponding URIs, which are then retrieved service information that is maintained by the browser in the normal fashion. This is
corresponding naming authority handle. The service information provides
the suggested way necessary information for clients to resolve communicate with the handles in ôhomeö
service for any request.

Figure 3.2 shows an example of a typical handle resolution process
where the future, because it provides
better performance, is more scalable, and "home service" is locally
configurable.

Handles can also be resolved using proxy services using Handle
Proxy Syntax (ie, http:<proxy>/<handle>). a local handle service. In this case, the
proxy server performs
client is trying to resolve the handle resolution task, "cnri.dlib/july95-arms" and sends
the resulting URL has
to find its "home" service from the client browser for processing.
Currently, CNRI provides global handle proxy server through
"hdl.handle.net", and "dx.doi.org". registry. The proxy server allows
handles ôhomeö
service is determined by sending a query to be resolved without additional software the Global Handle Registry
for the
client. For example, a handle "cnri.dlib/july95-arms" may be
entered as "http://hdl.handle.net/cnri.dlib/july95-arms"
resolvable by any browser.

It is worth noting corresponding naming authority handle. The Global Handle
Registry returns the service information that even though using describes the proxy server
approach local
handle service that is straight-forward and doesn't require any customer
software customization, it has responsible for handles under the effect of connecting naming
authority ôcnri.dlibö, including the
handles with handle ôcnri.dlib/july95-arms".
The service information allows the proxy server's URL location. Hence client to identify the
selection local handle
service in order to resolve the handle.

------------------------
| | 4. Result of a proxy server should be made client request
| Client with care.

4.3 Creating handles global | <------------------------------.
| service information | |
| | ---------------------------. |
------------------------ 3. Request to responsible | |
| ^ local handle service | |
1. Client | | | |
request | | | |
on "cnr | |2. Service information | |
i.dlib/ | | for "cnri.dlib" V |
july95- | | -------------------
arms" | | | |
V | | Local service |
--------------- | responsible for network resources

The |
| | | naming authority |
| Global Handle System allows handles | | "cnri.dlib" |
| Registry | | |
| | -------------------
---------------

Fig. 3.2 Handle resolution starting with global

To improve resolution performance, any client may choose to be created in a distributed
fashion. Organizations in need 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 providing a naming service
for their persistent internet resources will general caching mechanism, may also be able to contact
CNRI or other organizations used to register for their own handle
naming authority, as well as their own
provide shared caching within a 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 community. Given a public handle registration service for cached
resolution result, subsequent queries of the IETF community. This same handle may be
answered locally without contacting any handle service. Given cached
service provides an open channel to allow individuals information, clients can send their requests directly to create
handles and experiment with the
responsible 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
http://www.handle.net/ietf/handle/register_handle.html.

5. without contacting the Global Handle
Registry.

4. Handle System Service Architecture and Security

The Handle System is distributed, scalable, and designed for
widespread deployment. The current implementation consists of one
global service and many local provides handle services. Each resolution service, as well as handle
administration service consists of one of more physically distributed handle
servers. (Currently, over the global service consists of two servers
in Virginia and two in California. A European location is
planned.) And each public Internet. Each handle server can have one or more secondary
servers for mirroring. In addition, be
assigned a set of values. Clients use the handle caching servers are
provided for faster resolution service for to
resolve any handle into its set of values. Each value has a local environment, data type
and they a unique value index. Clients can also be used to provide proxy query for specific handle values
based on data type or value index.

The handle administration service through
firewalls.

5.1 Handle services 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 consists of many services. Each provides authentication and data integrity services,
depending on client request. By default, the handle resolution service is
responsible
does not require any client authentication. However, resolution
requests for part 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 handle namespace. One specific
service, called client as having
the Global Handle Registry, requisite authority. When authentication is globally unique,
and has required, the
responsible handle server will issue a special function, which is challenge to know of the existence,
location, and namespace responsibilities of all other public
services, 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 local handle services. There can be an unlimited
number otherwise in
possession of local handle services, managed by various organizations.
In the current implementation each local appropriate credentials. The handle service is
registered with server will
respond to the Global initial request only after successful authentication of
the client. Handle Registry clients may choose to ensure efficient
resolution. Policies and procedures use either secret key or
public key cryptography for disconnected local authentication.

Handle clients may also request digitally signed responses from any
handle
services are under development. The primary issue here is server, to
guarantee identifier uniqueness in disconnected systems.

5.2 Handle servers 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

Each handle service consists options for the safe transmission of one or more
information between client and server. This does not imply any
credentials of the handle servers.
Typically, each values. Incorrect values assigned to handles
by any of the administrators may very well mislead clients. On the
other hand, any handle server runs on a separate computer but
multiple value record may contain references to other
handle servers can run on value records to provide additional credentials. For example, a single computer. Within
value record R (e.g., a
handle service, the distribution claim) of handles across its constituent
servers is determined by any handle may contain a hash table such reference to
some other value record (from another handle) that each of N servers
within contains a service will be responsible digital
signature for 1/N handles. The number
of servers can be adjusted as required to meet the needs of a
service.

5.3 Server replication

Additionally, it may be desirable 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 mirror the contents client. The client of any of
the handle service must also
assume that any handle servers within a service, presumably on a separate
computer. This is referred involved have not been compromised. To
trust the Global Handle Service means to as replication and is accomplished
by creating one or more additional servers whose sole purpose is trust that it will rightfully
direct the client request to mirror the contents of responsible Handle Local Service. To
trust a Local Handle Service means to trust that it will correctly
respond with the original server. Within each data that was entered by the administrator. A Local
Handle Service typically supports a set of
replicated servers, the initial server is called the primary server
and all others are called secondary servers. naming authorities. Thus,
trusting a Local Handle Service means trusting its naming authority.

5. The creation Handle System and
administration other Internet Services

There are a number of handles always takes place on the primary server,
but resolution can use either the primary existing and proposed Internet identifier
services or any specifications that by design or intent cover some of its secondaries.
This provides fault tolerance, as well as the potential
functionality proposed for
performance improvement.

5.4 Caching Server

The the Handle System Caching Server has been built System. This section briefly
reviews them in relationship to reduce the
network traffic between handle clients and handle services Handle System.

5.1 Domain Name Service (DNS)

The Domain Name Service, or DNS, was originally designed and
its use is strongly encouraged. Caching handle data or heavily
used for mapping domain names into IP Addresses for network routing
information on the caching server allows some handle resolution
to be performed within an organization's local area network.

5.5 Proxy Server
purposes. RFC1034 [2] and RFC1035 [3] provide detailed descriptions of
its design and implementation. The Handle System Proxy Server growth of the Internet has been developed increased
demands for various extensions to act DNS, and even its possible use as a
client to the Handle System, allowing handles to be resolved using
Handle Proxy Syntax (ie, http:<proxy server>/<handle>). Using
this syntax,
general purpose resource naming system. However, any such use has the browser passes a handle
potential to slow down the proxy server,
which network address translation, and alter its
effectiveness in turn passes the handle 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 the appropriate handle
service support a very
large number of DNS names used for resolution. If naming any kind of resources over
the handle can be resolved into one
or more URLs, Internet.

An additional factor that argues against using DNS as a URL general purpose
naming system is returned from the handle
server to the proxy, and from DNS administrative model. DNS names are typically
managed by the proxy to network administrator(s) at the client browser.

5.6 Handle System Resolver

The Handle System Resolver [4] is DNS zone level, with no
provision for a software component which
extends Netscape or Microsoft Web browsers, per name administrative structure, 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 no facilities
for resolution. If the handle can
be resolved into one anyone other than network administrators to create or more URLs, one of the URLs manage names.
This 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. appropriate for domain name administration but less so for
general-purpose resource name administration.

The Handle
Resolution protocol uses registered port number 2641. By
default, a System differs from DNS in its distributed administration
and service model, as well as its secured service protocol (see section
4). Each handle resolution request will be answered with
all of the typed data associated with a handle, with within the
exception of Handle System may define its own
administrator(s), and the administrative data. It is also possible
to request data only of a certain type. Handle clients System defines a distributed
administration and access control model that do not know which allows an individual
handle service and its contents to
query for a given handle start with be managed securely over the Global public network.
The Handle
Registry, which is guaranteed System service model allows any of its service sites to know which
dynamically configure its service contains
a given handle. Within a given service, distribution among a client uses the hash
table specific cluster of
servers to the accommodate increased service requests. This also allows
less powerful computers to discover the individual
server, or set of replicated servers, which can resolve the
given handle.

A be used together to support any huge number
of handle resolution clients have been constructed,
all of which utilize the Handle Client Library [6], which handles.

5.2 Directory Services (X.500/LDAP)

X.500 [6] is currently implemented as a C library. The clients include
a Web proxy server, the Handle System Resolver [4], OSI Directory Standard defined by ISO and the
Grail Web browser [7].

7. Handle administration

Handle System administration ITU. It
is carried out using the
Handle System Administration Protocol [8]. This protocol
allows designed ôto provide a white pages service that would return either
the creation and administration telephone numbers or X.400 O/R addresses of handles peopleö, and their
associated data within is
ôconcerned mainly with providing 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 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
secure global name lookup and stable storage of handle data. Development search. The protocol, however, has proved
difficult to implement and
documentation there has been difficulty in getting ôclient
access integrated into existing productsö [17]. LDAP (Lightweight
Directory Access Protocol ) [8] has overcome many of secure practices these difficulties
by making the protocol simpler, and policies easier to implement. Some concern
remains, however, that as LDAP is underway.

A handle does not in itself pose emerging from a security threat. When
specified or used in URL context, local directory
access protocol (LDAP v2) into a distributed service protocol (LDAP
v3), it is subject to all
the security considerations 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 URL specification [3].

9. Handle System and URL/URN/URI

While 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 is designed to be usable can, in many
contexts comparison, be designed
solely around efficient resolution of known items without addressing
functions and is not a subset or extension data structures required for discovery of current UR* schemes,
it can unknown items
based on incomplete criteria.

Directory services such as LDAP or WHOIS++ [18,19] may be used in conjunction
tandem with those schemes. When used
within those schemes it is, of course, subject to their
constraints. The 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 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
current proposed URN implementations [11,12,13] discussed directory service
interface would provide an extended search capability. Handles could
also be used, for example, in the 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 in the following ways.

First of all, the Handle System defines Working Group [23] has defined a namespace independent
of URI, syntax, possible
resolution mechanisms, and is not subject to the current namespace constraints
of URI. The namespace registration procedure for a
resource identifier intended to cover a large array of handles is Unicode based, existing and imposes no
reserved or excluded characters on the handle string. This
allows handles
potential namespaces. Namespaces are to be specified in any national language natively
in a globally unique registered and unambiguous manner. The elimination of
any reserved characters also allows any legacy naming system,
such as SICI [14], 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 be used with no begin, or minimum change. discover,
the appropriate resolution mechanisms.

The Handle System is designed to support, instead objectives and some of exclude, the
use approaches of user friendly names the URN and Handle System
efforts have enough in any native language. There common that some observers might think that they
are
situations in which using descriptive names may hurt the persistence
of 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 once resolution and
administration. URNs and the identified object changes its association.
Objects of this nature Handle System may be better served using non-descriptive
names; for example, digits only. On interact in variety of
ways, the other hand, there are
objects for most obvious of which descriptive names are desirable.

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

URN services may say, they could 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 a type of URN.
It would also be possible to resolve use the handle Handle System as a URN. Handles specified as an type of RDS for
other URN
must follow namespaces. The success of either system however, is not
dependent upon the URN syntax [13].

10. success of the other.

6. History and Acknowledgment

The initial design and implementation 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. MDA-
972-92-J-1029. One aspect of this project 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 [15]. [20]. The first implementation was created at CNRI in the fall
of 1994.
Subsequent work on 1994 in an effort led by David Ely.

Early adopters of the Handle System has been supported in part
by have included the Advanced Research Projects Agency under Grant No.
MDA972-92-J-1029.

The following people 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 design System. Current status and available software, both client and implementation:
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, 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, Yu, Sean Reilly, Jane Euler, Larry Lannom, Catherine Rey, and Sam Sun. We also want Stephanie
Nguyen. Their contributions to acknowledge the contribution of the
other members of the Computer Science Technical Reports project.

11. Author's 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-5434
(703) 620-8990 20191
USA
Phone: 703-262-5316
Email: ssun@cnri.reston.va.us

12.

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. 1996, ISBN 0-201-48345-9
[2] Yergeau, Francois, "UTF-8, A Transform Format for Unicode
and ISO10646", RFC2044, October 1996.
http://ds.internic.net/rfc/rfc2044.txt 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://ds.internic.net/rfc/rfc1738.txt

[4] Handle System Resolver.
http://www.handle.net/resolver/ 1994,
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1738.txt
[5] Handle System Client Library download site.
http://www.handle.net/download.html 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] Handle Resolution Protocol.
http://www.handle.net/client_spec.html ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models, and
Services", 1993.
[7] The Grail Internet Browser.
http://grail.cnri.reston.va.us/grail/ D W Chadwick, ôUnderstanding X.500 û The Directoryö, Chapman & Hall
ISBN: 0-412-43020-7,
http://www.salford.ac.uk/its024/X500.htm
[8] Handle Administration Protocol.
http://www.handle.net/handle_admin.html 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. K., and L. Masinter, "Functional Requirements for Uniform
Resource Names", RFC 1737, December 1994.
http://ds.internic.net/rfc/rfc1737.txt 1994,
http://info.internet.isi.edu/in-notes/rfc/files/rfc1737.txt
[10] Berners-Lee, T., "Universal Resource Identifiers
in WWW" RFC 1630, June 1994.
http://ds.internic.net/rfc/rfc1630.txt

[11] Daniel, Ron and Michael Mealling, "Resolution Sollins, K. "Architectural Principles of Uniform Resource Identifiers using the Domain Name
System",
Resolution", RFC 2168, June 1997.
http://ds.internic.net/rfc/rfc2168.txt 2276, January 1998, ftp://ftp.isi.edu/in-
notes/rfc2276.txt
[11] ôHandle System Namespace and Service Definitionö, work in
progress.
[12] Daniel, Jr., Ron, "A Trivial Convention for using
HTTP ôHandle System Protocol Specificationö, work in URN Resolution", RFC-2169, June 1997.
http://ds.internic.net/rfc/rfc2169.txt progress.
[13] Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
http://ds.internic.net/rfc/rfc2141.txt ôHandle System Application Programming Interface (API)
Specificationö, work in progress.
[14] Serial Item and Contribution Identifier (SICI) Standard.
http://sunsite.berkeley.edu/SICI/ ô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. 1995,
http://www.cnri.reston.va.us/tmp_hp/k-w.html

[16] Digital Object Identifier System.
http://hdl.handle.net/10.1000/1

[17] National Digital Library Program.
http://hdl.handle.net/4263537/003

[18] The CNRI Registry.
http://hdl.handle.net/4263537/001

[19] Defense Virtual Library.
http://hdl.handle.net/4263537/002

[20] Sollins, K., "Architectural Principles of Uniform Resource
Name Resolution", September 26, 1997, Work in Progress.
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-req-frame-04.txt
[21] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997,
http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt The Networked Computer Science Technical Reports Library (NCSTRL),
http://www.ncstrl.org/
[22] T. Berners-Lee, L. Masinter, R. Fielding, "Uniform David Goodman, Colin Robbins. "Understanding LDAP & X.500", August
1997,
http://www.eema.org/understanding_ldap.html
[23] IETF Uniform Resource
Identifiers (URI): Generic Syntax", work in progress,
June Names (URN) Working Group, April, 1998, ftp://ftp.ietf.org/internet-drafts/draft-fielding-
uri-syntax-03.txt

[23] List of IANA registered charset names.
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets

INTERNET-DRAFT
draft-ietf-handle-system-01.txt
Expires Jul 16, 1999
http://www.ietf.org/html.charters/urn-charter.html

----