Date: Mon, 10 Jul 95 17:20:02 CDT From: email@example.com (Daniel LaLiberte) Message-Id: <9507102220.AA15428@void.ncsa.uiuc.edu> To: firstname.lastname@example.org Subject: Path URN Specification The latest version of the path scheme specification is now available at http://union.ncsa.uiuc.edu/~liberte/www/path.html. This version will be submitted to the IETF as draft-ietf-uri-urn-path-01.txt. Below is the Abstract and Introduction. Daniel LaLiberte (email@example.com) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ ---------------------------- The Path URN Specification draft-ietf-uri-urn-path-01.txt Daniel LaLiberte <firstname.lastname@example.org> Michael Shapiro <email@example.com> ... Abstract A new "path" URN scheme is proposed that defines a uniformly hierarchical name space. This URN scheme supports dynamic relocation and replication of resources. Existing DNS technology is used to resolve a path into sets of equivalent URLs, and then one URL is resolved into the named resource. Introduction The path scheme defines a uniformly hierarchical name space where a path URN is a sequence of components and an optional opaque string. An example path URN is: path:/A/B/C/doc.html The path is /A/B/C and the opaque string is doc.html. The significant features of the path URN scheme include the following: Highly Scalable The resolution process is highly scalable due to several factors. Resolution is distributed as much as the named resources themselves are. (This also permits the resolution of names to be handled by servers that are motivated to maintain the service because they also serve the named resources.) The public hierarchy enables clients to make use of caches of resolver locations. Dynamically Reconfigurable The resolution process is reconfigurable to support additional scalability and persistence of names in the event of relocations. The responsibility for resolution of a part of a name space may be delegated to another resolver or several parts of the name space may be recombined and resolved by a single server. Built-in Fallback Mechanism The resolution process has a built-in fallback mechanism in case the original resolver is uncooperative in forwarding references to resources that have moved. Easily Deployed The resolution and name assignment mechanisms are easily deployable since they use existing DNS technology and URL resolution schemes such as HTTP and FTP. Only a small amount of path-specific code is added to clients or proxy servers. Existing URLs may be automatically mapped to path URNs. Resolves to Resource A path resolves first into a list of sets of equivalent URLs, and then second, that list is resolved into the named resource using one of the URLs. The type of the resource is identified by the protocol of the particular URL that is used; if metadata for the resource is desired instead, the particular URL scheme may provide it. The path URN scheme does not depend on URCs. In this document, we first describe the name assignment and resolution process conceptually. This is followed by a more detailed description of the protocol, the encoding rules, and the compliance to URN requirements.