Date: Mon, 10 Jul 95 17:20:02 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9507102220.AA15428@void.ncsa.uiuc.edu>
To: uri@bunyip.com
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 (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/
----------------------------
The Path URN Specification
draft-ietf-uri-urn-path-01.txt
Daniel LaLiberte <liberte@ncsa.uiuc.edu>
Michael Shapiro <mshapiro@ncsa.uiuc.edu>
...
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.