Path URN Specification

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Mon, 10 Jul 95 17:20:02 CDT


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.