RFC 2276 (rfc2276) - Page 3 of 24

Architectural Principles of Uniform Resource Name Resolution

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