Resources available from the virtual repository will be named by URNs and/or LIFNs, rather than by URLs. Thus, WWW clients will need a means of resolving a URN or LIFN to one or more locations, expressed in the form of a URL, to be able to access the resource. Access to files is provided by conventional file servers, using protocols such as HTTP, Gopher, and FTP. Name resolution - that is, accessing a resource given its name - requires the following two steps:
For a non-file resource, such as a database service, a list of locations may be associated directly with the URN for that resource. For a file resource, such as a file containing a piece of software, we recommend that the list of locations be associated directly with the LIFN for the file, rather than with any URN assigned to the resource. If the publisher wishes to also assign a URN to the resource, then a LIFN should be associated with that URN.
The LIFN-to-location mapping service is to be provided by a network of LIFN servers, collectively called the LIFN database. These servers process queries for locations of LIFNs. They also accept updates from file servers containing new locations for LIFNs, as well as requests to delete old LIFN-to-location mappings. A naming authority may run its own LIFN servers, or it may find another organization willing to provide the service on its behalf.
The URN service is similar to the LIFN service, except that it maps a name either to a list of locations or to a LIFN. For fault tolerance and availability, the URN service is also provided by a network of servers.
Mappings from naming authority identifiers to URN and LIFN servers are stored in the the Domain Name System (DNS) name space, so that a client program can determine which LIFN (URN) server to query for a particular LIFN (URN). Our current client uses an ordinary DNS lookup for IP address records. The publisher identifier is prepended to the string .LIFN.NETLIB.ORG (for a LIFN) or .URN.NETLIB.ORG (for a URN). The resulting string is treated as if it were the name of an Internet host, and DNS is queried to find the IP addresses of that host. For example, to find a LIFN server for the naming authority foo, the client would look up the IP addresses for foo.LIFN.NETLIB.ORG. Several IP addresses may be listed for any one naming authority. Our client attempts to query each IP address until it finds one that can satisfy the LIFN or URN lookup request.
A file server can mirror a file by acquiring a copy of it and posting an update to a LIFN server for the file's naming authority. If a file server moves or deletes a file, then it would post that information as well. It is not necessary to keep all LIFN servers for a particular naming authority perfectly synchronized. Such synchronization would entail too much overhead. Instead, location updates will be posted to a single LIFN server and propagated to other peer servers using a batch update protocol.
Under normal conditions, all LIFN servers will be reasonably up-to-date, but if the list of locations provided by one server is unsufficient, the client is free to consult other LIFN servers for additional locations. If a listed location turns out to be incorrect - i.e., it points to a location that does not actually contain the file (how such an error condition may be detected by the client is discussed in Section 4) - the client may look for a file at the file's other listed locations.
Similar techniques are to be used for propagating updates between
peer URN servers. In the case of URNs, however, the consistency
issues are more vague, because of the less precise definition
of URN compared to LIFN. Consistency guarantees to be provided
for URNs are the subject of future work.