Internet Draft 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::= "/" 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