URNs and LIFNs

URNs (Uniform Resource Names) are used to provide stable names for resources whose characteristics may vary over time. For instance, a URN may be used as a stable reference to a web page. The web page can then move, be replicated, or change its contents and still remain accessible through the same URN. In contrast to URLs which have wired-in location information, the location information and other characteristics of a URN are provided by external resolution servers.

A LIFN (Location-Independent File Name) is similar to a URN in that it is a stable name and that it can be resolved to find locations of a resource that it names. However, unlike a URN, a LIFN is constrained to name a specific fixed instance of a resource. All copies of a file named by a LIFN are byte-for-byte identical. The meaning of a LIFN also does not change over time. Once a LIFN is used to refer to a particular file, it must always refer to that same sequence of octets. A URN is associated with a description of the resource it names, while a LIFN is associated with with one or more locations of identical copies of that resource.

The description associated with a URN normally contains one or more LIFNs, which name particular instances of that resource, and describes the characteristics of each instance. For example, if the resource named by a particular URN exists in several different data formats (e.g. plain text, PostScript, PDF, HTML), the description for that URN will list each of these, along with a LIFN for each specific instance. Similarly, if the resource associated with a URN has changed over time, and multiple versions of the resource are accessible, the description of that resource would contain a list of the current and previous versions along with the LIFNs for each. Because the LIFN can then be used to find the current locations of a resource, it serves as a ``link'' or ``file handle'' from the description of a resource instance to the list of its current locations.

LIFNs have several purposes in RCDS:

1. A LIFN serves as a link between a catalog record that describes a resource and the locations of a particular instance of that resource.
2. LIFNs are used by replication daemons (mirroring tools) which create new replicas by copying files across a network. The replication daemons use LIFNs to refer to the files being replicated, so that there is no ambiguity about which version of a file is being copied. This also allows the locations of all replicas created by such daemons to be associated with the same identifier.
3. LIFNs are intended to be used as cache validators. If a client determines that a user request can be satisfied by the file named by a particular LIFN, and the client finds a cached copy of the file named by that LIFN, (and the client trusts the integrity of the cache), the client can use the cached copy. In this use LIFNs are similar to the ``strong entity tags'' of the HTTP/1.1 protocol, and can be used in HTTP's ETag: entity-header field.

The distinction between URNs and LIFNs was crafted for several reasons:

• Location data and descriptions are maintained by different parties. The description of a resource will normally be maintained by its author, publisher, editor, or reviewers, while the location data will be maintained by the managers of specific file servers.
• If a resource suddenly becomes of interest to a large population, the set of replicated copies of that resource may need to change quickly according to demand. Under such conditions, the location data for that resource may need to change much more quickly than the description of the resource itself.
• The location directory (accessed by LIFN) and the description server (accessed by URN) have different needs for consistency across replicas. There is little need to maintain a consistent list of locations across the set of replicated location servers. On the other hand, it can be very important to have an up-to-date description of a resource and for the replicated copies of that description to be consistent with one another.
• The portions of RCDS responsible for replicating files and keeping track of their locations need an unambiguous name for a particular instance of a resource, to avoid confusing it with other instances of the same resource.
• If all instances of a file associated with a LIFN are identical, the client's choice of which instance of a resource to access (data type, version, etc) may be cleanly separated from its choice of which location to use when accessing the resource. The former choice can then be made on the basis of browser capabilities, user requirements, etc., while the latter choice can be based on (say) proximity estimates.