RFC 2276 (rfc2276) - Page 3 of 24
Architectural Principles of Uniform Resource Name Resolution
Alternative Format: Original Text Document
RFC 2276 Uniform Resource Name Resolution January 1998 aliasing, relative or short names, context sensitive names, descriptive names, etc. Their definition is not part of this effort, but will clearly play an important role in the long run. URNs as described in RFC 1737 are defined globally; they are ubiquitous in that a URN anywhere in any context identifies the same resource. Given this requirement on URNs, one must ask about its implication for an RDS. Does ubiquity imply a guarantee of RDS resolution everywhere? Does ubiquity imply resolution to the same information about resolution everywhere? In both cases the answer is probably not. One cannot make global, systemic guarantees, except at an expense beyond reason. In addition there may be policy as well as technical reasons for not resolving in the same way everywhere. It is quite possible that the resolution of a URN to an instance of a resource may reach different instances or copies under different conditions. Thus, although a URN anywhere refers to the same resource, in some environments under some conditions, and at different times, due to either the vagaries of network conditions or policy controls a URN may sometimes be resolvable and other times or places not. Ubiquitous resolution cannot be assumed simply because naming is ubiquitous. On the other hand wide deployment and usage will be an important feature of any RDS design. Within the URI community there has been a concept used frequently that for lack of a better term we will call a _hint_. A hint is something that helps in the resolution of a URN; in theory we map URNs to hints as an interim stage in accessing a resource. In practice, an RDS may map a URN directly into the resource itself if it chooses to. It is very likely that there will be hints that are applicable to large sets of URNs, for example, a hint that indicates that all URNs with a certain prefix or suffix can be resolved by a particular resolver. A hint may also have meta-information associated with it, such as an expiration time or certification of authenticity. We expect that these will stay with a hint rather than being managed elsewhere. We will assume in all further discussion of hints that they include any necessary meta-information as well as the hint information itself. Examples of hints are: 1) the URN of a resolver service that may further resolve the URN, 2) the address of such a service, 3) a location at which the resource was previously found. The defining feature of hints is that they are only hints; they may be out of date, temporarily invalid, or only applicable within a specific locality. They do not provide a guarantee of access, but they probably will help in the resolution process. By whatever means available, a set of hints may be discovered. Some combination of software and human choice will determine which hints will be tried and in what order. Sollins Informational
