Abstract -- Supporting a URI Infrastructure by Message Broadcasting

[Help] Last update at http://inet.nttam.com : Mon Aug 7 21:39:59 1995

Abstract -- Supporting a URI Infrastructure by Message Broadcasting Application Technology Track
A6: Engineering the Web

Supporting a URI Infrastructure by Message Broadcasting

Freitas, Vasco ( vf@uminho.pt)
Rio, Miguel ( rio@uminho.pt)
Costa, Antonio ( costa@uminho.pt)
Macedo, Joaquim ( macedo@uminho.pt)

Abstract

In order to achieve universal interoperability and integration of network services, a universal naming convention is needed. A first step towards this goal is the URL (Uniform Resource Locator), in wide use nowadays, which is a compact representation of location and access method of Internet resources. The expectation, however, is that URN (Uniform Resource Name) and URC (Uniform Resource Characteristic) are to be used instead, so that location independancy is achieved.

A requirement for the migration from URLs to URNs and URCs is the existance of reliable URN2URL or URN2URC mapping services.

Whatever approach is taken for this migration and because information replication in the Internet is so widespread (e.g. mirroring), it is unreasonable to expect, at least for a transition period, to have all URLs of a given URN correctly registered.

A solution to the transition is proposed, based upon standard message broadcasting mechanisms, such as those provided by Usenet News and Open Distribution Lists services, to announce URIs (Uniform Resource Identifiers): URCs of originals and URLs of copies.

These Internet services, in fact, post articles to exchange URLs, which are pointers to document resources of interest. Should the articles use a standard format, it would be possible and simple to process them automatically. This format would have to include a filled-in URC template comprising a URN, a URL and other meta-information.

Hence, URLs may still be collected in the usual way, ie, they appear explicitly, but a new set of tools can be developed to automatically retrieve the announcements, publish them to the organization and, if desirable, replicate the resource locally.

On the other hand one may wish to maintain secondary servers for for the URN2URC mapping service (like DNS) to improve on efficiency and to achieve fault tolerance. The secondary server would maintain links to the resources by answering to URN2URL queries even if it is not the original maintainer.

An important question is whether secondary servers are defined by organizational criteria or by thematic ones. Thematic criteria would be the most interesting since searches very often take a yellow-page approach. For example, there would be servers for Artificial Intelligence, Telecommunications, Operating Systems and so on.

Since many links would be found in Usenet News, the newsgroup hierarchy could be used for the classification of thematic servers. An Operating Systems server would look for announcements made in comp.os.X newsgroups.

As for the updating of secondary servers, a reasonable approach can be found in the combined use of DNS-like mechanisms such as incremental zone transfers, on one hand and, on the other hand, of the message broadcasting mechanisms in Distribution Lists applied to selected lists.

Some resources may have thousands of URLs. Should a URN2URC server maintain all of them? It may neither be advisable nor needed because a small number of references will be enough to answer the most frequent queries. Servers may be configured to a maximum number of URLs per resource they are allowed to handle.

Another question is whether all URN2URC servers should maintain the same set of links (URLs) to a given resource. A set of parameters can influence this decision. One of the most obvious is location. A server will try to keep references that are either nearer to it or within a given zone.

A given URL may be important to some servers but not to others. It should be left to each server to decide. Again, a broadcasting mechanism is needed for the announcement of the new link. Therefore when a resource is replicated, the event should be announced either in Usenet News or in a specific distribution list using standard article format. An additional type of announcement is needed when the resource is no longer replicated so that all URLs pointing to that resource are discarded.

An article format for broadcasting URIs and an architecture to include thematic secondary servers and the necessary updating strategies are proposed. The parameters that influence URN2URC server behaviour regarding meta-information it must know about are discussed.