The rise of mobile computing, and a long history in dealing with other distributed resources on the Internet has built up tradition of building resilient systems with multiple levels of failover. These can be seen in the likes of domain name resolution. URNs currently lack this capability and the aim of this paper is to discuss these issues and look at implementing a system to deal with it.
DNS performs the task of turning a name string into an IP address that locates a particular machine. The problem that early Internet users faced was that going out to a network for the real information may not always be possible. Also, other alternate schemes were available to do that same mapping. Indeed one system pre-dated DNS by a considerable amount of time.
To overcome these potential problems, a system of meta resolvers was established that allowed the competing resolver schemes to co-exist peacefully. It consistent of a high level resolution that stated the order of the resolvers to use. Each resolver then used its own configuration files to determine the next steps. As hinted in RFC2276 [1], a very similar approach should be taken with URN resolution.
Under the unix operating systems, the top level file for defining the resolver
scheme order is /etc/host.conf. This simply lists the names of
resolver scheme in order in the file. The Unix name service implementation uses
this as the hint for priority order. It is simple, effective and allows per
machine configuration differences thus providing maximum flexibility. These
names are used by the system to generate query orders.
A URN is just a naming scheme for an arbitary resource. It is a name without a library. On the other hand, there are a myriad of standards and wannabe standards that allow you to locate a something called directory services. For example, there is LDAP (lightweight X.500), NDS, CORBA and JINI to name just a few. In the mix of today's hetrogenous networks it is highly probable that more than one of these will be available on a machine. What they miss is a consistent naming scheme to allow us to access them transparently, not caring about the source. This is where the resolver discovery service fits in. It provides the glue between the name and the resource.
Following our example from domain naming we create a file called
urn.conf. In this, there contains a list of resolver classifications
that need to be loaded. Keeping with the modular architecture, there will need
to be a set of rules laid down that specify how to resolve a name in this
configuration file to something that can be loaded into the application. By
necessity, these will be implementation/language dependent. The order of the
items specified in this file define the search order of the resolvers.
If we follow on this train of thought, that implies that we need a meta
resolver application that takes care of the loading and handling of queries.
This meta-resolver would provide a consistent interface across all applications
in a similar way that the C getHostByName() provides for name
resolution. It takes care of the management issues required to define, load and
call each of the individual resolvers but is not responsible for doing any of
the resolution itself.
Statement of Capabilities: Not all resolvers are created equally. They cannot be expected to resolve every URN equally. It is helpful to know before the time what capabilities the individual resolver may be capable of. The basic capabilities required for resolving URIs are defined by RFC2168 [4] and IETF working drafts [5]. This should be a list of all the services that the resolver may be able to provide. This is necessary so that a resolver that may only be able resolve a URN to a resource, but can't provide equivalent URLs may be skipped if a query is made to return URLs.
URIs not resolvable: In some cases, resolvers are limited to a specific set of domains that may be resolvable. Like the statement of capabilities, there is possible room for efficiency gains by the meta-resolver by not calling a resolver if it is known that it cannot handle a scheme. It is not required that a resolver should know every scheme it cannot resolve because for cases like DNS based resolution, this can only be determined by the act of attempting to resolve the URI. Therefore, a resolver should only return a positive response if it is known that it definitely cannot handle the particular URI asked. A don't know answer should be answered in the negative.
Decode URI: Resolve the URI using the requested service. For example
a decode command may ask to resolve a URL to a list of URCs using the I2Ls
service request. If the server cannot resolve this for some reason, an error
condition should be generated. If it can resolve it, but there turns out to
be no answer then an empty value would be returned (typically the
NULL equivalent in a language). As the service types defined
in [5] indicate, there may be options that return either
single or list equivalents.
getHostByName() style functions
provided by the standard C/POSIX interface. On the other end there is the
object oriented approach used by Java that represents a URL as an object that
you make requests of. There is no definitive approach to the best way of
doing this and we make no recommendations for the style. Like the resolver,
there are a bunch of standard services that should be available to the client.
[2]Mealing, M. & Daniel, R. "The Naming Authority (NAPTR) DNS Resource Record", IETF Internet Draft 0 (draft-ietf-urn-naptr-rr-00.txt), Nov 1998
[3]Gulbrandsen, A. & Vixie, P. "A DNS Resource Record for Specifying the Location of Services", RFC2052, Oct 1996
[4]Daniel, R. & Mealing, M. "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC2168, June 1997
[5]Mealing, M. & Daniel, R. "URI Resolutions Services Necessary for URN Resolution", IETF Internet Draft 7 (draft-ietf-urn-resolution-services-07.txt), Nov 1998