Internet Engineering Task Force Leslie L. Daigle draft-daigle-urnframework-00.txt Bunyip Information Systems Inc INTERNET-DRAFT Patrik Faltstrom Tele2/Swipnet Renato Iannella DSTC Pty Ltd June 13, 1996. A Framework for the Assignment and Resolution of Uniform Resource Names ---------------------------------------- Abstract ---------------------------------------- The main purpose of URNs is to serve as persistent resource identifiers, where each URN may potentially need to be usable for several decades. A primary goal of the URN framework is to provide a mechanism whereby a URN can be resolvable for many decades, while still allowing the resolution services for that URN to be provided by the parties responsible for maintenance of the information about that URN. The Uniform Resource Name framework abstract description is proposed as a means of handling URN identifiers in modular layers of information management. From the standpoint of the bearer of a URN, this means that much of the underlying support for a given URN or collection may change without disrupting the identification capacities of the URN. ---------------------------------------- Status of this draft ---------------------------------------- This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet- Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. This draft expires November 13, 1996. Updated versions and related information can be found at: http://www.bunyip.com/research/ietf/urn-bof ---------------------------------------- Introduction ---------------------------------------- The main purpose of URNs is to serve as persistent resource identifiers, where each URN may potentially need to be usable for several decades. A primary goal of the URN framework is to provide a mechanism whereby a URN can be resolvable for many decades, while still allowing the resolution services for that URN to be provided by the parties responsible for maintenance of the information about that URN. Since the resources named by a URN may change ownership over time, the resolution services for a URN must be able to change without changes to the URN itself. The Uniform Resource Naming framework defines the structures and services required in order to support uniform resource naming across a number of different namespaces. The underlying characteristics of these namespaces may vary considerably, but the URN framework lays out the basic requirements a namespace must (claim to) live up to in order to be supported as a partition of the URN namespace. When this work is complete, these requirements will exist in the form of an objectively verifiable checklist against which new namespaces can be compared/supporting structures built. The URN framework aims to provide flexible methods to support various 'resolution services' for URNs. The resolution service will provide a client with access to the named resource. The URN framework will provide the client with the ability to instantiate these resolution services, in a manner that will not bind any client or service to protocol dependant technologies. The URN framework abstract description is proposed as a means of handling the URN identifiers in modular layers of information management. From the standpoint of the bearer of a URN, this means that much of the underlying support for a given URN or collection may change without disrupting the identification capacities of the URN. For example, the resolution service(s) used by a collection may move or change format entirely, without affecting the validity of the URN. Beyond accommodating differences in individual namespaces, this framework is also designed to modularize authority in such a way as to keep information maintenance close to the responsible entity. For example, if a resource location changes, only the final level of resolution needs to be made aware of the change. ---------------------------------------- Syntax ---------------------------------------- For the purposes of this document, the following informal syntax is used: URN:: NID is the Namespace Identifier and NSS is the Namespace Specific String. Each namespace defines the structure of its NSS, and the Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String to the extent of extracting the Naming Authority information. This may be done by providing rules for extracting specific Naming Authority ID information from the NSS, or by having a specified set of Naming Authorities for an entire namespace. The NID[+NA] serves as a key to finding the location of resolution services. The protocol used to resolve the name is independent of the name itself. This construct allows the incorporation of different name structures. Examples: URN:duns:002372413:annual-report-1997 In this example, "duns" is the NID, and "002372413:annual-report-1997" is the NSS. URN:inet:gatech.edu:olympic-schedule-1997 Here, "inet" is the NID, and "gatech.edu:olympic-schedule-1997" is the NSS. Each of the "duns" and "inet" namespaces define rules for the syntactic interpretation of the NSS to the extent of extracting an NA string. ---------------------------------------- URN Resolution through Registries ---------------------------------------- The URN framework provides URN resolution infrastructure in the shape of an abstract description of registries of namespaces and naming authorities. Resolution of a URN, when possible, can be accomplished by consulting these registries, although client software may implement strategies for optimization of the process. This default method of resolution-with-registries proceeds as follows: . A NID registry consulted get a description of the NSS. (See draft-daniel-naptr-01.txt for a description of the implementation of such an NID registry). . If there is a NA string in the NSS, the next step of the resolution is to look up the NID+NA; otherwise the NID is used again in this step of resolution. The lookup occurs in a resolution authority registry (see draft-daniel-naptr-01.txt for a description of the implementation of such a registry) to identify one or more resolution services for the result. . The URN is passed to one of the resolution services. Note that this document refers to "a global NID registry". There is still discussion underway as to the best means of handling public and private namespaces and different ways of implementing registries. Pictorially, this can be represented as: URN:: | v +---------------------+ | Global NID Registry | +---------------------+ | | (one of) +---------+-----------+ | | v v NID (No NA NA (extracted from NSS) extracted) + NID | | | | | +------------+ | | | | v v +----------------+ | Resolution | | Authority | | Registry | +----------------+ | | (ranked in order of preference) +------------------------------------+-----(...)------+ | | | v v v Resolution Resolution Resolution Service1 ID Service2 ID ServiceN ID | | | | v +----------------+ | BrandX | | URN | | Resolution | | Service | +----------------+ | v N.B.: is defined abstractly -- it might be the desired resource, a description of the resource, the location of the resource, etc. NID registry: While there needs to be some form of global NID registry (which is not an uncommon requirement for Internet infrastructure, e.g., the DNS service), it is possible that a given client will refer first (or exclusively) to a local NID registry. This will certainly be useful for closed software information systems. It is expected that the NID registry will be fairly small, and pretty involatile. It is expected that caching will be quite successful in handling the majority of requests. Some namespaces will not want to publish rules for parsing names -- i.e., the (partial) decoding of the NSS might be considered violation of the proprietary nature of the name assignment scheme, giving the world at large more information about the information in the namespace than the namespace's owner is happy about. Such namespaces can either opt to pre-pend other indications of naming authorities in translating their names into NSS's, or these will fall into the category of URN's from which the NA cannot be extracted. Resolution Authority Registry: Once the NA (if any) has been extracted from the URN, the client consults the Resolution Authority Registry to determine who can resolve names issued in that namespace by that naming authority. Depending on the client software, there may be more than one resolution authority registry that can be consulted. Examples: URN:duns:002372413:annual-report-1997 If the duns namespace does not provide rules for extracting the NA information from the NSS, NA's for the whole namespace must be provided. URN:inet:gatech.edu:olympic-schedule-1997 The inet namespace may provide rules for extracting "gatech.edu" as the key for composing an NA that should be looked up in the Naming Authority Registry. Similarly, URN:message-id:199606071447.KAA20718@cs.utk.edu The message-id namespace may provide rules for extracting "cs.utk.edu" as the key for compsoin an NA that should be looked up in the Naming Authority Registry. ---------------------------------------- Clients can do what they want... ---------------------------------------- In providing the above as the default URN resolution procedure, it is expected that there will be at least one "system" (infrastructure) deployed to support it -- some global name registry, and a set of NA identification servers. Registration in these services is required as a step in becoming an official URN-supported namespace. This is required in order to be able to ensure global fall-back mechanisms for resolution of orphaned or migrated resources. Nevertheless, the resolution strategy used by any client is chosen by the developers of that client. For example, a given application may choose to provide and support a directory of often-used URNs, and its client software may first consult that directory. Defining the reliability and optimality of such strategies is beyond the scope of the URN framework; may the best strategy win. The global infrastructure that _is_ provided by the URN framework is designed to ensure the overall goals of URNs -- global scope, persistence, etc. ---------------------------------------- The URN Framework -- what is in, what is not ---------------------------------------- This proposed URN framework addresses the URN requirements as laid out in RFC 1737. Some of these are provided by the infrastructure of the framework itself, some are defined as characteristics a given namespace must support in order to be considered eligible to participate in the URN framework, and a few are considered to lie within the realm of individual namespaces (e.g., characteristics that are important to one community, but that impede the implementation of characteristics necessary to another). In particular, the URN framework provides global scope, allows persistence, independence, and legacy support. Participating Namespaces must claim to provide global uniqueness in the URNs generated in order to be part of the URN framework, although they may vary in how they provide persistence and scalability. ---------------------------------------- Namespace Identifier Requirements and Administration ---------------------------------------- Some set of criteria must be established to govern what can and cannot be used as a (top-level) namespace (NID assignment). This can include: . demonstration of an established namespace management system (including an overview of mechanisms for preventing the duplication/reassignation of name identifiers. These mechanisms are particular to the individual namespaces). . multi-organization participation in the naming system . rules on how names are assigned, name assignment authority delegation . provision of escape clause ---------------------------------------- Related issues ---------------------------------------- The URN framework, described here in its abstract form, is meant to provide the infrastructure for a system that _can_ fulfill the desiderata of URN systems. This section describes certain stated issues that are handled indirectly by the URN framework -- that is, the hooks are available in the abstract framework, but the implementation will be dependent on elements that are outside the scope of the URN infrastructure per se. Lexical Equivalence This definition of the abstract URN framework does not immediately provide mechanisms to determine equivalence of two URNs. That is, in order to accommodate the variety of existing and proposed namespaces, it is not possible to define a single scheme that would incorporate this ability. Nevertheless, there is every likelihood that single resources may be assigned more than one URN (under different naming schemes, or as the resources are included in different perspectives of a collection, for instance). It is expected that, where needed, individual services for determining "equivalence" will evolve. Authority Over Name Strings The modular nature of the framework distributes authority across different levels in the resolution process. Therefore, while the Global NID Registry will provide the official response about what Resolution Authority Registries are registered to handle a given URN, it has nothing to say about the NSS. Similarly, individual Resolution Services maintain authority for resolving the URN to a particular result, but they have make no authoritative statements about a namespace. Rules for individual namespaces are determined by the owners of the namespace before they are registered in the NID registry. Authority of assignment of individual names within the namespace is also dependent on the individual namespace, and is not part of the URN resolution framework. Scope of Grandfathering Grandfathering of existing namespaces under the URN framework will be handled in the same way as the creation of new partitions -- a proposal must be put forward to demonstrate that the namespace can fulfill the requirements of URN namespace partitions (e.g., generating globally unique URN identifiers) and what rules will be registered in the Global NID Registry. ---------------------------------------- Acknowledgements ---------------------------------------- The URN work was initiated as part of the IETF URI Working Group. When that group was closed at the Stockholm IETF in July, 1995, interested parties continued to meet to move the work forward. In addition to the URN BOF held at the Dallas IETF in December, 1995, three voluntary meetings have been organized (in Knoxville, Montreal, and Los Alamos). This document is a direct product of those discussions, and the following attendees must be thanked for their hard work in helping move this effort forward: Ron Daniel David Ely Dirk van Gulik Dan Laliberte Michael Mealling Keith Moore Keith Shafer Michael Shapiro Reed Wade Stuart Weibel Chris Weider Ted Wolf ---------------------------------------- Authors' Addresses ---------------------------------------- Leslie L. Daigle Bunyip Information Systems Inc. 310 Ste. Catherine St. West Suite 300 Montreal, Quebec, Canada H2X 2A1 voice: (514) 875-8611 fax: (514) 875-8134 e-mail: leslie@bunyip.com Patrik Faltstrom Tele2/Swipnet Box 62 Borgarfjordsgatan 16 S-164 94 Kista Sweden Phone: +46-8-56264000 Fax: +46-8-56264200 Email: paf@swip.net Renato Iannella Research Data Network CRC DSTC Pty Ltd Gehrmann Laboratories University of Queensland Australia Phone: +61-7--3365-4310 Fax: +61-7--3365-4311 Email: renato@dstc.edu.au