Multiple URN RDS Implementations Infrastructure for Dealing with Multiple RDS Implementations Simlutaneously Last Updated: 8 Feb, 1999

Abstract

Introduction

URNs define a way of resolving a given name to a resource without specifying the location of it. The idea of this is to give a resource the ability to move around without effecting the calling application. Efforts to date have been focused on both defining the syntax of a URN and getting one implementation together that allows for resolving a URN to a real resource. This implementation has been based around DNS and uses the experimental NAPTR [2] and SVR [3] records.

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.

URNs and DNS

URNs and DNS contain many very similar traits. They are both designed to turn an abstract concept - some characters, into a specific location. At the same time they also perform many other services on top of the basic system. At thier heart they are both abstract naming systems that work in a networked environment.

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.

Potential Resolver Types

Unlike the the domain name system, which has only 3 basic options, URNs can have many different types. Because the definition of resource is very broad, a URN can name anything from your toaster to a book to an image. The configuration for resolving a URN must be much more flexible than domain names allowing many different ways of implement a URN resolver.

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.

Resolving The Resolver

The URN resolver scheme has many things that can be pilfered directly from the domain name resolution schemes. The same basic assumptions apply in both principles. When first with a URN, the system must find a resolver to use. The difference is now that there are potentially many different types of resolvers. Unlike the 3 fixed types for host names, we now have arbitary types. This implies that any deployable, largescale URN resolver implementation will require a modular, pluggable architecture.

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.

Resolver Features

The definition of each resolver should follow the same interface regardless of the underlying implementation. This is an essential feature that a pluggable architecture requires. The resolver should be able load each of them, then during runtime just iterate through all of the resolvers without knowing which is which, just making a call to the appropriate function to resolve. So what does our generic resolver need to provide?

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.

Client Interface

The client interface represents how a URI may be described to an application. There are various approaches that may be adopted from existing similar systems. For example, there are the 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.

References

[1]Sollins, K. "Architectural Principles of Uniform Resource Name Resolution", RFC2276, Jan 1998

[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

http://www.vlc.com.au/~justin/java/urn/multiple_rds.html"
Comments: couch@ccis.adisys.com.au