Request for Comments: 3651 S. Reilly
Category: Informational L. Lannom
CNRI
November 2003
Handle System Namespace and Service Definition
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 it 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
The Handle System is a general-purpose global name service that
allows secured name resolution and administration over the public
Internet. This document provides a detailed description of the
Handle System namespace, and its data, service, and operation models.
The namespace definition specifies the handle syntax and its semantic
structure. The data model defines the data structures used by the
Handle System protocol and any pre-defined data types for carrying
out the handle service. The service model provides definitions of
various Handle System components and explains how they work together
over the network. Finally, the Handle System operation model
describes its service operation in terms of messages transmitted
between client and server, and the client authentication process
based on the Handle System authentication protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Handle System Namespace. . . . . . . . . . . . . . . . . . . . 3
3. Handle System Data Model . . . . . . . . . . . . . . . . . . . 4
3.1. Handle Value Set . . . . . . . . . . . . . . . . . . . . 4
3.2. Pre-defined Handle Data Types. . . . . . . . . . . . . . 9
3.2.1. Handle Administrator: HS_ADMIN . . . . . . . . . 10
3.2.2. Service Site Information: HS_SITE. . . . . . . . 14
3.2.3. Naming Authority Delegation Service:
HS_NA_DELEGATE . . . . . . . . . . . . . . . . . 19
3.2.4. Service Handle: HS_SERV. . . . . . . . . . . . . 20
3.2.5. Alias Handle: HS_ALIAS . . . . . . . . . . . . . 21
3.2.6. Primary Site: HS_PRIMARY . . . . . . . . . . . . 21
3.2.7. Handle Value List: HS_VLIST. . . . . . . . . . . 22
4. Handle System Service Model. . . . . . . . . . . . . . . . . . 22
4.1. Handle System Service Components . . . . . . . . . . . . 23
4.1.1. Global Handle Registry (GHR) . . . . . . . . . . 23
4.1.2. Local Handle Service (LHS) . . . . . . . . . . . 26
4.2. Handle System Middle-Ware Components . . . . . . . . . . 27
4.2.1. Handle System Caching Service. . . . . . . . . . 27
4.2.2. Handle System Proxy Server . . . . . . . . . . . 28
4.3. Handle System Client Components. . . . . . . . . . . . . 28
5. Handle System Operation Model. . . . . . . . . . . . . . . . . 29
5.1. Handle System Service Request and Response . . . . . . . 30
5.2. Handle System Authentication Protocol. . . . . . . . . . 32
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. References and Bibliography. . . . . . . . . . . . . . . . . . 38
9. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 40
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 41
1. Introduction
The Handle System manages handles as globally unique names for
Internet resources. It was originally conceived and described in a
paper by Robert Kahn and Robert Wilensky [22] in 1995. The Handle
System provides a general-purpose global name service that allows
handles to be resolved and administrated securely over the public
Internet. The Handle System categorizes its service into two
categories: the handle resolution service and the handle
administration service. Clients use handle resolution service to
resolve handles into their values. The handle administration service
deals with client requests to manage these handles, including adding
and deleting handles, and updating handle values.
The document "Handle System Overview" [1] provides an architectural
overview of the Handle System, and its relationship to other Internet
services such as DNS [2,3] and LDAP[4]. This document provides a
detailed description of the Handle System namespace, its data and
service model, and its operation model. It assumes that readers are
familiar with the basic concepts of the Handle System as described in
the overview document.
The namespace definition specifies the handle syntax and its semantic
structure. The data model defines the data structures used by the
Handle System protocol and any pre-defined data types for carrying
out the handle service. The service model provides definitions of
various Handle System components and explains how they work together
over the network. Finally, the Handle System operation model
describes its service operation in terms of messages transmitted
between client and server, and the client authentication process
based on the Handle System authentication protocol.
2. Handle System Namespace
Handles are character strings that may consist of a wide range of
characters. Every handle in the Handle System consists of two parts:
its naming authority, followed by a unique local name under the
naming authority. The naming authority and the local name are
separated by the ASCII character "/" (octet 0x2F). The following
table provides the handle syntax definition in ABNF [5] notation:
<Handle> = <NamingAuthority> "/" <LocalName>
<NamingAuthority> = *(<NamingAuthority> ".") <NAsegment>
<NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF )
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters except
; octets ’0x2E’ and ’0x2F’ (which
; correspond to the ASCII characters ’.’,
; and ’/’).
<LocalName> = *(%x00-FF)
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters
Table 2.1: Handle syntax
As shown in Table 2.1, both <NamingAuthority> and <LocalName> are
UTF-8 [6] encoded character strings. The Handle System protocol
mandates UTF-8 encoding for handles transferred over the wire. The
<LocalName> may consist of any characters from the Unicode 2.0
standard [7]. The <NamingAuthority> may use any characters from the
Unicode 2.0 standard except the ASCII character ’/’ (0x2F), which is
reserved to separate the <NamingAuthority> from the <LocalName>. A
<NamingAuthority> may consist of multiple non-empty <NAsegment>s,
each of which separated by the ASCII character ’.’ (octet 0x2E).
Naming authorities 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 (<NAsegment>). The parent
node represents the parent naming authority. 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 (or its <NAsegment>) is separated by the character ’.’ (octet
0x2E). For example, the naming authority for the Digital Object
Identifier (DOI) project is "10". It is a root-level naming
authority as it has no parent naming authority for itself. It can,
however, have many child naming authorities. For example, "10.1045"
is a child naming authority of "10" for the D-Lib Magazine.
By default, handles are case sensitive. However, a handle service,
global or local, may implement its namespace so that ASCII characters
under the namespace are treated as case insensitive. For example,
the global handle service, formally known as the Global Handle
Registry (GHR), is implemented such that ASCII characters are treated
as case insensitive. Since the GHR manages all handles for naming
authorities, ASCII characters in naming authorities are treated as
case insensitive.
3. Handle System Data Model
The Handle System provides a name-to-value binding service over the
public Internet. Each handle may have a set of values assigned to
it. The Handle System maintains the value set of each handle and
will return it in response to any handle resolution request. The
Handle System data model defines the conceptual data structure for
these values. The data model used by the protocol may not be the
exact physical data model used for storage in any specific
implementation. Rather, it is the data model followed by the Handle
System protocol as specified in the "Handle System Protocol
Specification" [8].
3.1. Handle Value Set
Each handle may have a set of values assigned to it. These handle
values use a common data structure for its data. For example, each
handle value has a unique index number that distinguishes it from
other values in the value set. It also has a specific data type that
defines the syntax and semantics of the data in its data field.
Besides these, each handle value contains a set of administrative
information such as TTL and permissions. Figure 3.1 shows the handle
"10.1045/may99-payette" with a set of three handle values. One of
these values (with index number set to 1) is shown in detail. (Note
that the encoding of the length for each field is not shown in Figure
3.1. Also, the empty <reference> field consists of a 4-byte integer
whose value is zero.)
Handle "10.1045/may99-payette"
|
|
V
-------------------------------------------------------------
| <index>: 3 |
------------------------------------------------------------- |
| <index>: 2 | |
------------------------------------------------------------- | |
| | | |
| <index>: 1 | | |
| <type>: URL | | |
| <data>: http://www.dlib.org/dlib... | | |
| <TTL>: {Relative: 24 hours} | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <timestamp>: 927314334000 | | |
| <reference>: {empty} | |-
| |-
-------------------------------------------------------------
Figure 3.1: Handle "10.1045/may99-payette" and its set of values
In Figure 3.1, it shows a handle value whose its index is set to 1.
The data type for the handle value is URL. The URL data as stated in
the <data> field is "http://www.dlib.org/dlib...". The TTL (time to
live) entry suggests that the value record should be cached no more
than 24 hours before the source of the information to be consulted
again. The <permission> field grants anyone permission to read, but
only the administrator to update the value. The <reference> field is
empty. It may contain a list of references to other handle values as
credentials for this handle value.
Thus a handle value may be thought of as a record that consists of a
group of data fields. Each of these data fields is defined as
follows:
<index>
An unsigned 32-bit integer that uniquely identifies a handle value
from other handle values.
<type>
A UTF8-string that identifies the data type for the value record.
Note that throughout this document, a UTF8-string is defined as a
data structure that consists of a 4-byte unsigned integer followed
by an UTF-8 encoded character string. The integer specifies the
number of octets in the character string.
The <type> field identifies the data type that defines the syntax
and semantics of data in the next <data> field. The data type may
be registered with the Handle System to avoid potential conflicts.
The Handle System has a reserved naming authority "0.TYPE" for
registered data types. For example, "URL" (as shown in Figure
3.1) is a registered data type. It is registered as the handle
"0.TYPE/URL". The handle may have a value that explains the
syntax and semantics of the data type.
Data types under the Handle System may be hierarchical. Each
level of the hierarchy may be named in terms of a UTF8-String with
no ’.’ (0x2E) characters. The ’.’ character is used to mark the
boundary between hierarchy levels. For example, the Handle System
data type "a.b" may be considered as a sub-type "b" under the type
"a". Similarly, handle values of <type> "a.b.x", "a.b.y" and
"a.b.z" may be considered as handle values under the common type
hierarchy "a.b".
For any handle values, the UTF8-string in the <type> field may not
end with the ’.’ character. In other words, no Handle System data
type should end with the ’.’ character. However, the ’.’
character may appear in the end of the <type> parameter in a
handle query. This is used to query for all handle values under a
common type hierarchy. For example, one may query for all handle
values under the type hierarchy "a.b" (e.g., handle values of
<type> "a.b.x", "a.b.y" and "a.b.z") by setting the <type>
parameter to "a.b.". Note here that the <type> parameter ends
with the ’.’ character. Details of the handle query operation can
be found in the Handle System protocol specification [8].
<data>
A sequence of octets (preceded by its length in a 4-byte unsigned
integer) that describes the resource identified by the handle. The
syntax and semantics of these octets are identified by the <type>
field.
<permission>
An eight-bit bit-mask for access control of the handle value.
Access control is defined in terms of read, write, and execute
permissions, applicable to either general public or handle
administrator(s). Each handle value can have its permission field
specified as any combination of the following bits:
PUBLIC_WRITE (0x01) permission that allows anyone to
modify or delete the handle value.
PUBLIC_READ (0x02) permission that allows anyone to read
the handle value.
ADMIN_WRITE (0x04) permission that allows any handle
administrator to update or delete the
handle value.
ADMIN_READ (0x08)_ permission that allows the handle
value to be read by any handle
administrator with AUTHORITIVE_READ
privilege.
PUBLIC_EXECUTE (0x10) permission that allows anyone to
execute the program identified by the
handle value on the handle host as
anonymous user. Because of the
security risks this may have brought
up, implementations may choose not to
support such permission, or provide
options so that it can be disabled at
deployment.
ADMIN_EXECUTE (0x20) permission that allows handle
administrator(s) to run the program
identified by the handle value on the
handle server. The handle server must
authenticate the handle administrator
before executing the program. The
handle administrator must have an
established account on the handle
server. The execution of the handle
value should assume the same privilege
as the one given to the account for
the handle administrator. Because of
the security risks this may have
brought up, implementations may choose
not to support such permission, or
provide options so that it can be
disabled at deployment.
Note that a handle value with no PUBLIC_READ nor ADMIN_READ
permission can not leave the handle server. It may be used, for
example, to store secret keys for authentication purposes. A
handle value with neither PUBLIC_WRITE nor ADMIN_WRITE permission
makes the handle value immutable and cannot be deleted by any
handle administrator (via the Handle System protocol).
The administrator for a given handle must specify the permission
for each handle value. Implementations may choose PUBLIC_READ and
ADMIN_WRITE as the default permission for each handle value.
Handle servers must check permissions before fulfilling any client
request.
<TTL>
An octet followed by a 4-byte integer that specifies the Time-To-
Live of the value record. It is used to describe how long the
value record can be cached before the source of the information
should again be consulted. A zero value for a TTL indicates that
the value record should only be used for the transaction in
progress and should not be cached. Any non-zero TTL is defined in
terms of a TTL type (specified in the first octet), followed by
the TTL value (the 32-bit unsigned integer that follows the TTL
type). The TTL type indicates whether the TTL value is absolute
or relative. The absolute TTL value defines the time to live in
terms of seconds since 00:00:00 UTC, January 1st 1970. A relative
TTL specifies the time to live in terms of the number of seconds