path: root/doc/rfc/rfc2276.txt

Network Working Group                                         K. Sollins
Request for Comments: 2276                                       MIT/LCS
Category: Informational                                     January 1998


      Architectural Principles of Uniform Resource Name Resolution

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document addresses the issues of the discovery of URN (Uniform
   Resource Name) resolver services that in turn will directly translate
   URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource
   Characteristics).  The document falls into three major parts, the
   assumptions underlying the work, the guidelines in order to be a
   viable Resolver Discovery Service or RDS, and a framework for
   designing RDSs.  The guidelines fall into three principle areas:
   evolvability, usability, and security and privacy.  An RDS that is
   compliant with the framework will not necessarily be compliant with
   the guidelines.  Compliance with the guidelines will need to be
   validated separately.

Table of Contents

   1.    Introduction..................................................2
   2.    Assumptions...................................................5
   3.    Guidelines....................................................7
   3.1   Evolution.....................................................7
   3.2   Usability....................................................10
   3.2.1 The Publisher................................................11
   3.2.2 The Client...................................................12
   3.2.3 The Management...............................................13
   3.3   Security and Privacy.........................................14
   4.    The Framework................................................18
   5.    Acknowledgements.............................................23
   6.    References...................................................23
   7.    Author's Address.............................................23
   8.    Full Copyright Statement.....................................24




Sollins                      Informational                      [Page 1]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


1. Introduction

   The purpose of this document is to lay out the engineering criteria
   for what we will call here a Resolver Discovery Service (RDS), a
   service to help in the learning about URN (Uniform Resource Name)
   resolvers.  The term "resolver" is used in this document to indicate
   a service that translates URNs to URLs (Uniform Resource Locators) or
   URCs (Uniform Resource Characteristics).  Some resolvers may provide
   direct access to resources as well.  An RDS helps in finding a
   resolver to contact for further resolution.  It is worth noting that
   some RDS designs may also incorporate resolver functionality.  This
   function of URN resolution is a component of the realization of an
   information infrastructure.  In the case of this work, that
   infrastructure is to be available, "in the Internet" or globally, and
   hence the solutions to the problems we are addressing must be
   globally scalable.  In this document, we are focussing specifically
   on the design of RDS schemes.

   The Uniform Resource Identifier Working Group defined a naming
   architecture, as demonstrated in a series of three RFCs 1736 [1],
   1737 [2], and 1738 [3].  Although several further documents are
   needed to complete the description of that architecture, it
   incorporates three core functions often associated with "naming":
   identification, location, and mnemonics or semantics.  By location,
   we mean fully-qualified Domain Names or IP addresses, possibly
   extended with TCP ports and/or local identifiers, such as pathnames.
   Names may provide the ability to distinguish one resource from
   another, by distinguishing their "names".  Names may help to provide
   access to a resource by including "location" information.  In
   addition, names may have other semantic or mnemonic information that
   either helps human users remember or figure out the names, or
   includes other semantic information about the resource being named.
   The URI working group concluded that there was need for persistent,
   globally unique identifiers, distinct from location or other semantic
   information; these were called URNs.  These "names" provide identity,
   in that if two of them are "the same" (under some simple rule of
   canonicalization), they identify the same resource.  Furthermore, the
   group decided that these "names" were generally to be for machine,
   rather than human, consumption.  Finally, with these guidelines for
   RDS's, this group has recognized the value of the separation of name
   assignment management from name resolution management.

   In contrast to URNs, one can imagine a variety human-friendly naming
   (HFN) schemes supporting different suites of applications and user
   communities.  These will need to provide mappings to URNs in tighter
   or looser couplings, depending on the namespace.  It is these HFNs
   that will be mnemonic, content-full, and perhaps mutable, to track
   changes in use and semantics.  They may provide nicknaming and other



Sollins                      Informational                      [Page 2]
^L
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                      [Page 3]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   We must assume that most resolutions of URNs will be provided by the
   use of locally stored hints, because maintaining a database of
   globally available, completely up-to-date location information is
   infeasible for performance reasons.  There are a number of
   circumstances in which one can imagine that hints become invalid,
   either because a resource has moved or because a different URN
   resolver service has taken over the responsibility for resolution of
   the URN.  Hints may be found in a variety of places.  It is generally
   assumed that a well engineered system will maintain or cache a set of
   hints for each URN at each location where that URN is found.  These
   may have been acquired from the owner of the resources, a
   recommendation of the resource, or one of many other sources.  In
   addition, for those situations in which those hints found locally
   fail, a well engineered system will provide a fall-back mechanism for
   discovering further hints.  It is this fall-back mechanism, an RDS,
   that is being addressed in this document.  As with all hints, there
   can never be a guarantee that access to a resource will be available
   to all clients, even if the resource is accessible to some.  However,
   an RDS is expected to work with reasonably high reliability, and,
   hence, may result in increased response time.

   The remainder of this document falls into three sections.  The first
   identifies several sets of assumptions underlying this work.  There
   are three general assumptions:

      * URNs are persistent;
      * URN assignment can be delegated;
      * Decisions can be made independently, enabling isolation from
        decisions of one's peers.

   The next section lays out three central principles Resolver Discovery
   Service design.  For each of these, we have identified a number of
   more specific guidelines that further define and refine the general
   principle.  This section is probably the most critical of the
   document, because one must hold any proposed RDS scheme up against
   these principles and corollary guidelines to learn whether or not it
   is adequate.  The three central principles can be summarized as:

      1) An RDS must allow for evolution and evolvability;
      2) Usability of an RDS with regard to each of the sets of
         constituents involved in the identification and location or
         resources is paramount;
      3) It is centrally important that the security and privacy needs
         of all constituents be feasibly supported, to the degree
         possible.

   Each of the three major subsections of the guidelines section begins
   with a summary list of the more detailed guidelines identified in



Sollins                      Informational                      [Page 4]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   that section.

   The final section of the document lays out a framework for such RDSs.
   The purpose of this last section is to bound the search space for RDS
   schemes.  The RDS designer should be aware that meeting the
   guidelines is of primary importance; it is possible to meet them
   without conforming to the framework.  As will be discussed further in
   this last section, designing within the framework does not guarantee
   compliance, so compliance evaluation must also be part of the process
   of evaluation of a scheme.

2. Assumptions

   Based on previous internet drafts and discussion in both the URN BOFs
   and on the URN WG mailing list, three major areas of assumptions are
   apparent: longevity, delegation, and independence.  Each will be
   discussed separately.

   The URN requirements [2] state that a URN is to be a "persistent
   identifier".  It is probably the case that nothing will last forever,
   but in the time frame of resources, users of those resources, and the
   systems to support the resources, the identifier should be considered
   to be persistent or have a longer lifetime than those other entities.
   There are two assumptions that are implied by longevity of URNs:
   mobility and evolution.  Mobility will occur because resources may
   move from one machine to another, owners of resources may move among
   organizations, or the organizations themselves may merge, partition,
   or otherwise transforms themselves.  The Internet is continually
   evolving; protocols are being revised, new ones created, while
   security policies and mechanisms evolve as well.  These are only
   examples.  In general, we must assume that almost any piece of the
   supporting infrastructure of URN resolution will evolve.  In order to
   deal with both the mobility and evolution assumptions that derive
   from the assumption of longevity, we must assume that users and their
   applications can remain independent of these mutating details of the
   supporting infrastructure.

   The second assumption is that naming and resolution authorities may
   delegate some of their authority or responsibility; in both cases,
   the delegation of such authority is the only known method of allowing
   for the kind of scaling expected.  It is important to note that a
   significant feature of this work is the potential to separate name
   assignment, the job of labelling a resource with a URN, from name
   resolution, the job of discovering the resource given the URN.  In
   both cases, we expect multi-tiered delegation.  There may be RDS
   schemes that merge these two sets of responsibilities and delegation
   relationships; by doing so, they bind together or overload two
   distinctly different activities, thus probably impeding growth.



Sollins                      Informational                      [Page 5]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   The third assumption is independence or isolation of one authority
   from another and, at least to some extent, from its parent.  When one
   authority delegates some of its rights and responsibilities to
   another authority, the delegatee can operate in that domain
   independently of its peers and within bounds specified by the
   delegation, independently of the delegator.  This isolation is
   critically important in order to allow for independence of policy and
   mechanism.

   This third assumption has several corollaries.  First, we assume that
   the publisher of a resource can choose resolver services,
   independently of choices made by others.  At any given time, the
   owner of a namespace may choose a particular URN resolver service for
   that delegated namespace.  Such a URN resolver service may be outside
   the RDS service model, and only identified or located by the RDS
   service.  Second, it must be possible to make a choice among RDS
   services.  The existence of multiple RDS services may arise from the
   evolution of an RDS service, or development of new ones.  Although at
   any given time there is likely to be only one or a small set of such
   services, the number is likely to increase during a transition period
   from one architecture to another.  Thus, it must be assumed that
   clients can make a choice among a probably very small set of RDSs.
   Third, there must be independence in the choice about levels and
   models of security and authenticity required.  This choice may be
   made by the owner of a naming subspace, in controlling who can modify
   hints in that subspace.  A naming authority may delegate this choice
   to the owners of the resources named by the names it has assigned.
   There may be limitations on this freedom of choice in order to allow
   other participants to have the level of security and authenticity
   they require, for example, in order to maintain the integrity of the
   RDS infrastructure as a whole.  Fourth, there is an assumption of
   independence of choice of the rule of canonicalization of URNs within
   a namespace, limited by any restrictions or constraints that may have
   been set by its parent namespace.  This is a choice held by naming
   authorities over their own subnamespaces.  Rules for canonicalization
   will be discussed further in the framework section below.  Thus,
   there are assumptions of independence and isolation to allow for
   delegated, independent authority in a variety of domains.













Sollins                      Informational                      [Page 6]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   The modularity assumptions of delegation and isolation imply
   independence of decision and implementation, leading to a
   decentralization that provides a certain degree of safety from denial
   of service.  Based on these these assumptions in conjunction with
   that of longevity and those for URLs and URNs as detailed in RFCs
   1736 and 1737, we can now turn to the guidelines for an RDS.

3. Guidelines

   The guidelines applying to an RDS center around three important
   design principles in the areas of evolvability, usability, and
   security and privacy.  At its core the function of an RDS is to
   provide hints for accessing a resource given a URN for it.  These
   hints may range in applicability from local to global, and from
   short-lived to long-lived.  They also may vary in their degree of
   verifiable authenticity.  While it may be neither feasible nor
   necessary that initial implementations support every guideline, every
   implementation must support evolution to systems that do support the
   guidelines more fully.

   It is important to note that there are requirements, not applicable
   specifically to an RDS that must also be met.  A whole URN system
   will consist of names in namespaces, the resolution information for
   them, and the mapping from names in the namespaces to resolution
   information (or hints).  URNs themselves must meet the requirements
   of RFC 1737.  In addition, namespaces themselves must meet certain
   requirements as described by the URN Working Group [4].  Although all
   these requirements and guidelines are not described here, they must
   be supported to provide an acceptable system.

   Each section below begins with a summary of the points made in that
   section.  There is some degree of overlap among the areas, such as in
   allowing for the evolution of security mechanisms, etc., and hence
   issues may be addressed in more than one section.  It is also
   important to recognize that conformance with the guidelines will
   often be subjective.  As with many IETF guidelines and requirements,
   many of these are not quantifiable and hence conformance is a
   judgment call and a matter of degree.  Lastly, the reader may find
   that some of them are those of general applicability to distributed
   systems and some are specific to URN resolution.  Those of general
   applicability are included for completeness and are not distinguished
   as such.

3.1 Evolution

   The issues in the area of the first principle, that of evolvability,
   are:




Sollins                      Informational                      [Page 7]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


       1.1) An RDS must be able to support scaling in at least three
            dimensions: the number of resources for which URNs will be
            required, the number of publishers and users of those
            resources, and the complexity of the delegation, as
            authority for resolution grows and possibly reflects
            delegation in naming authority;
       1.2) A hint resolution environment must support evolution of
            mechanisms, specifically for:
            * a growing set of URN schemes;
            * new kinds local URN resolver services;
            * new authentication schemes;
            * alternative RDS schemes active simultaneously;
       1.3) An RDS must allow the development and deployment of
            administrative control mechanisms to manage human behavior
            with respect to limited resources.

   One of the lessons of the Internet that we must incorporate into the
   development of mechanisms for resolving URNs is that we must be
   prepared for change.  Such changes may happen slowly enough to be
   considered evolutionary modifications of existing services, or
   dramatically enough to be considered revolutionary.  They may
   permeate the Internet universe bit by bit, living side by side with
   earlier services or they may take the Internet by storm, causing an
   apparent complete transformation over a short period of time.  There
   are several directions in which we can predict the need for
   evolution.  At the very least, the community and the mechanisms
   proposed should be prepared for these.

   First, scaling is a primary issue in conjunction with evolution.  The
   number of users, both human and electronic, as well as the number of
   resources will continue to grow exponentially for the near term, at
   least.  Hence the number of URNs will also increase similarly.  In
   addition, with growth in sheer numbers is likely to come growth in
   the delegation of both naming authority and resolution authority.
   These facts mean that an RDS design must be prepared to handle
   increasing numbers of requests for inclusion, update and resolution,
   in a set of RDS servers perhaps inter-related in more complex ways.
   This is not to say that there will necessarily be more updates or
   resolutions per URN; we cannot predict that at this time.  But, even
   so, the infrastructure may become more complex due to delegation,
   which may (as can be seen in Section 4 on the framework) lead to more
   complex rules for rewriting or extracting terms for staged
   resolution.  Any design is likely to perform less well above some set
   of limits, so it is worth considering the growth limitations of each
   design alternative.






Sollins                      Informational                      [Page 8]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   Second, we expect there to be additions and changes to the
   mechanisms.  The community already understands that there must be a
   capacity for new URN schemes, as described in [4].  A URN scheme will
   define a set of URNs that meet the URN requirements [2], but may have
   further constraints on the internal structure of the URN. The
   intention is that URN schemes can be free to specify parts of the URN
   that are left opaque in the larger picture.  In fact, a URN scheme
   may choose to make public or keep private the algorithms for any such
   "opaque" part of the URN.  In any case, we must be prepared for a
   growing number of URN schemes.

   Often in conjunction with a new URN scheme, but possibly
   independently of any particular URN scheme, new kinds of resolver
   services may evolve.  For example, one can imagine a specialized
   resolver service based on the particular structure of ISBNs that
   improves the efficiency of finding documents given their ISBNs.
   Alternatively, one can also imagine a general purpose resolver
   service that trades performance for generality; although it exhibits
   only average performance resolving ISBNs, it makes up for this
   weakness by understanding all existing URN schemes, so that its
   clients can use the same service to resolve URNs regardless of naming
   scheme.  In this context, there will always be room for improvement
   of services, through improved performance, better adaptability to new
   URN schemes, or lower cost, for example.  New models for URN
   resolution will evolve and we must be prepared to allow for their
   participation in the overall resolution of URNs.

   If we begin with one overall plan for URN resolution, into which the
   enhancements described above may fit, we must also be prepared for an
   evolution in the authentication schemes that will be considered
   either useful or necessary in the future.  There is no single
   globally accepted authentication scheme, and there may never be one.
   Even if one does exist at some point in time, we must always be
   prepared to move on to newer and better schemes, as the old ones
   become too easily spoofed or guessed.

   In terms of mechanism, although we may develop and deploy a single
   RDS scheme initially, we must be prepared for that top level model to
   evolve.  Thus, if the RDS model supports an apparently centralized
   (from a policy standpoint) scheme for inserting and modifying
   authoritative information, over time we must be prepared to evolve to
   a different model, perhaps one that has a more distributed model of
   authority and authenticity.  If the model has no core but rather a
   cascaded partial discovery of information, we may find that this
   becomes unmanageable with an increase in scaling.  Whatever the
   model, we must be prepared for it to evolve with changes in scaling,
   performance, and policy constraints such as security and cost.




Sollins                      Informational                      [Page 9]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   The third evolutionary issue is even more mechanical than the others.
   At any point in time, the community is likely to be supporting a
   compromise position with respect to resolution.  We will probably be
   operating in a situation balanced between feasibility and the ideal,
   perhaps with policy controls used to help stabilize use of the
   service.  Ideally, the service would be providing exactly what the
   customers wanted and they in turn would not request more support than
   they need, but it seems extremely unlikely.  Since we will almost
   always be in a situation in which some service provision resources
   will be in short supply, some form of policy controls will generally
   be necessary.  Some policy controls may be realized as mechanisms
   within the servers or in the details of protocols, while others may
   only be realized externally to the system.  For example, suppose hint
   entries are being submitted in such volume that the hint servers are
   using up their excess capacity and need more disk space.  Two
   suggestions for policy control are pricing and administrative.  As
   technology changes and the balance of which resources are in short
   supply changes, the mechanisms and policies for controlling their use
   must evolve as well.

3.2 Usability

   To summarize, the usability guidelines fall into three areas based on
   participation in hint management and discovery:

       2.1) The publisher
          2.1.1) URN to hint resolution must be correct and efficient
                 with very high probability;
          2.1.2) Publishers must be able to select and move among URN
                 resolver services to locate their resources;
          2.1.3) Publishers must be able to arrange for multiple access
                 points for their location information;
          2.1.4) Publishers should be able to provide hints with
                 varying lifetimes;
          2.1.5) It must be relatively easy for publishers to specify
                 to the management and observe their hint information as
                 well as any security constraints they need for their
                 hints.
       2.2) The client
          2.2.1) The interface to the RDS must be simple, effective,
                 and efficient;
          2.2.2) The client and client applications must be able to
                 understand the information stored in and provided by
                 the RDS easily, in order to be able to make informed
                 choices.
       2.3) The management
          2.3.1) The management of hints must be as unobtrusive as
                 possible, avoiding using too many network resources;



Sollins                      Informational                     [Page 10]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


          2.3.2) The management of hints must allow for administrative
                 controls that encourage certain sorts of behavior
                 deemed necessary to meet other requirements;
          2.3.3) The configuration and verification of configuration of
                 individual RDS servers must be simple enough not to
                 discourage configuration and verification.

   Usability can be evaluated from three distinct perspectives: those of
   a publisher wishing to make a piece of information public, those of a
   client requesting URN resolution, and those of the provider or
   manager of resolution information.  We will separately address the
   usability issues from each of these three perspectives.  It is
   important to recognize that these may be sitautions in which
   interests of some of the participants (for exampel a use and a
   publisher) may be in conflict; some resolution will be needed.

   It is worth noting that there are two additional sorts of
   participants in the whole naming process, as discussed in the URN WG.
   They are the naming authorities which choose and assign names, and
   the authors who include URNs in their resources.  These two are not
   relevant to the design of an RDS and hence are not discussed further
   here.

3.2.1 The Publisher

   The publisher must be able to make URNs known to potential customers.
   From the perspective of a publisher, it is of primary importance that
   URNs be correctly and efficiently resolvable by potential clients
   with very high probability.  Publishers stand to gain from long-lived
   URNs, since they increase the chance that references continue to
   point to their published resources.

   The publisher must also be able to choose easily among a variety of
   potential services that might translate URNs to location information.
   In order to allow for this mobility among resolvers, the RDS
   architecture must support such transitions, within policy control
   bounds.  It is worth noting that although multiple listing services
   are available in telephone books, they are generally accompanied by a
   fee.  There is nothing preventing there being fees collected for
   similar sorts of services with respect to URNs.

   The publisher must be able to arrange for multiple access points to a
   published resource.  For this to be useful, resolver services should
   be prepared to provide different resolution or hint information to
   different clients, based on a variety of information including
   location and the various access privileges the client might have.  It
   is important to note that this may have serious implications for
   caching this information.  For example, companies might arrange for



Sollins                      Informational                     [Page 11]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   locally replicated copies of popular resources, and would like to
   provide access to the local copies only for their own employees.
   This is distinct from access control on the resource as a whole, and
   may be applied differently to different copies.

   The publisher should be able to provide both long and short term
   location information about accessing the resource.  Long term
   information is likely to be such information as the long term address
   of a resource itself or the location or identity of a resolver
   service with which the publisher has a long term relationship.  One
   can imagine that the arrangement with such a long term
   "authoritative" resolver service might be a guarantee of reliability,
   resiliency to failure, and atomic updates.  Shorter term information
   is useful for short term changes in services or to avoid short lived
   congestion or failure problems.  For example, if the actual
   repository of the resource is temporarily inaccessible, the resource
   might be made available from another repository.  This short term
   information can be viewed as temporary refinements of the longer term
   information, and as such should be more easily and quickly made
   available, but may be less reliable.  Some RDS designs may not
   distinguish between these two extremes.

   Lastly, the publishers will be the source of much hint information
   that will be stored and served by the manager of the infrastructure.
   Despite the fact that many publishers will not understand the details
   of the RDS mechanism, it must be easy and straightforward for them to
   install hint information.  This means that in general any one who
   wishes to publish and to whom the privilege of resolution has been
   extended through delegation, can do so.  The publisher must be able
   not only to express hints, but also to verify that what is being
   served by the manager is correct.  Furthermore, to the extent that
   there are security constraints on hint information, the publisher
   must be able to both express them and verify compliance with them
   easily.

3.2.2 The Client

   From the perspective of the client, simplicity and usability are
   paramount.  Of critical importance to serving clients effectively is
   that there be an efficient protocol through which the client can
   acquire hint information.  Since resolving the name is only the first
   step on the way to getting access to a resource, the amount of time
   spent on it must be minimized.

   Furthermore, it will be important to be able to build simple,
   standard interfaces to the RDS so that both the client and
   applications on the client's behalf can interpret hints and
   subsequently make informed choices.  The client, perhaps with the



Sollins                      Informational                     [Page 12]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   assistance of the application, must be able to specify preferences
   and priorities and then apply them.  If the ordering of hints is only
   partial, the client may become directly

   involved in the choice and interpretation of them and hence they must
   be understandable to that client.  On the other hand, in general it
   should be possible to configure default preferences, with individual
   preferences viewed as overriding any defaults.

   From the client's perspective, although URNs will provide important
   functionality, the client is most likely to interact directly only
   with human friendly names (HFNs).  As in direct human interaction
   (not computer mediated), the sharing of names will be on a small,
   private, or domain specific scale.  HFNs will be the sorts of
   references and names that are easy to remember, type, choose among,
   assign, etc.  There will also need to be a number of mechanisms for
   mapping HFNs to URNs.  Such services as "yellow pages" or "search
   tools" fall into this category.  Although we are mentioning HFNs
   here, it is important to recognize that HFNs and the mappings from
   HFNs to URNs is and must remain a separate functionality from an RDS.
   Hence, although HFNs will be critical to clients, they do not fall
   into the domain of this document.

3.2.3 The Management

   Finally, we must address the usability concerns with respect to the
   management of the hint infrastructure itself.  What we are terming
   "management" is a service that is distinct from publishing; it is the
   core of an RDS.  It involves the storage and provision of hints to
   the clients, so that they can find published resources.  It also
   provides security with respect to name resolution to the extent that
   there is a commitment for provision of such security; this is
   addressed in Section 3.3 below.

   The management of hints must be as unobtrusive as possible. First,
   its infrastructure (hint storage servers and distribution protocols)
   must have as little impact as possible on other network activities.
   It must be remembered that this is an auxiliary activity and must
   remain in the background.

   Second, in order to make hint management feasible, there may need to
   be a system for administrative incentives and disincentives such as
   pricing or legal restrictions.  Recovering the cost of running the
   system is only one reason for levying charges.  The introduction of
   payments often has an impact on social behavior.  It may be necessary
   to discourage certain forms of behavior that when out of control have
   serious negative impact on the whole community.  At the same time,
   any administrative policies should encourage behavior that benefits



Sollins                      Informational                     [Page 13]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   the community as a whole.  Thus, for example, a small one-time charge
   for authoritatively storing a hint might encourage conservative use
   of hints.  If we assume that there is a fixed cost for managing a
   hint, then the broader its applicability across the URN space, the
   more cost effective it is.  That is, when one hint can serve for a
   whole collection of URNs, there will be an incentive to submit one
   general hint over a large number of more specific hints.  Similar
   policies can be instituted to discourage the frequent changing of
   hints.  In these ways and others, behavior benefitting the community
   as a whole can be encouraged.

   Lastly, symmetric to issues of usability for publishers, it must also
   be simple for the management to configure the mapping of URNs to
   hints.  It must be easy both to understand the configuration and to
   verify that configuration is correct.  With respect to management,
   this issue may have an impact not only on the information itself but
   also on how it is partitioned among network servers that
   collaboratively provide the management service or RDS.  For example,
   it should be straightforward to bring up a server and verify that the
   data it is managing is correct.  Although this is not a guideline, it
   is worth nothing that since we are discussing a global and probably
   growing service, encouraging volunteer participants suggests that, as
   with the DNS, such volunteers can feel confident about the service
   they are providing and its benefit to both themselves and the rest of
   the community.

3.3 Security and Privacy

   In summary, security and privacy guidelines can be identified as some
   degree of protection from threats.  The guidelines that fall under
   this third principle, that of security, are all stated in terms of
   possibilities or options for users of the service to require and
   utilize.  Hence they address the availability of functionality, but
   not for the use of it.  We recognize that all security is a matter of
   degree and compromise.  These may not satisfy all potential
   customers, and there is no intention here to prevent the building of
   more secure servers with more secure protocols to suit their needs.
   These are intended to satisfy the needs of the general public.

       3.1) It must be possible to create authoritative versions of a
            hint with access-to-modification privileges controlled;
       3.2) It must be possible to determine the identity of servers or
            avoid contact with unauthenticated servers;
       3.3) It must be possible to reduce the threat of denial of
            service by broad distribution of information across servers;
       3.4) It must be possible within the bounds of organizational
            policy criteria to provide at least some degree of privacy
            for traffic;



Sollins                      Informational                     [Page 14]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


       3.5) It must be possible for publishers to keep private certain
            information such as an overall picture of the resources they
            are publishing and the identity of their clients;
       3.6) It must be possible for publishers to be able to restrict
            access to the resolution of the URNs for the resources they
            publish, if they wish.

   When one discusses security, one of the primary issues is an
   enumeration of the threats being considered for mitigation.  The
   tradeoffs often include cost in money and computational and
   communications resources, ease of use, likelihood of use, and
   effectiveness of the mechanisms proposed.  With this in mind, let us
   consider a set of threats.

   Voydock and Kent [5] provide a useful catalog of potential threats.
   Of these the passive threats to privacy or confidentiality and the
   active threats to authenticity and integrity are probably the most
   important to consider here.  To the extent that spurious association
   causes threats to the privacy, authenticity, or integrity with
   respect to information within servers managing data, it is also
   important.  Denial of service is probably the most difficult of these
   areas of threats both to detect and to prevent, and we will therefore
   set it aside for the present as well, although it will be seen that
   solutions to other problems will also mitigate some of the problems
   of denial of service.  Furthermore, because this is intended to be
   provide a global service to meet the needs of a variety of
   communities, the engineering tradeoffs will be different for
   different clients.  Hence the guidelines are stated in terms of, "It
   must be possible..."  It is important to note that the information of
   concern here is hint information, which by nature is not guaranteed
   to be correct or up-to-date; therefore, it is unlikely to be worth
   putting too much expense into the correctness of hints, because there
   is no guarantee that they are still correct anyway.  The exact choice
   of degree of privacy, authenticity, and integrity must be determined
   by the needs of the client and the availability of services from the
   server.

   To avoid confusion it is valuable to highlight the meanings of terms
   that have different meanings in other contexts.  In this case, the
   term "authoritative" as it is used here connotes the taking of an
   action or stamp of approval by a principal (again in the security
   sense) that has the right to perform such an act of approval.  It has
   no implication of correctness of information, but only perhaps an
   implication of who claimed it to be correct.  In contrast, the term
   is often also used simply to refer to a primary copy of a piece of
   information for which there may also be secondary or cached copies
   available.  In this discussion of security we use the former meaning,
   although it may also be important to be able to learn about whether a



Sollins                      Informational                     [Page 15]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   piece of information is from a primary source or not and request that
   it be primary.  This second meaning arises elsewhere in the document
   and is so noted there.

   It is also important to distinguish various possible meanings for
   "access control".  There are two areas in which distinctions can be
   made.  First, there is the question of the kind of access control
   that is being addressed, for example, in terms of hints whether it is
   read access, read and modify access, or read with verification for
   authenticity.  Second, there is the question of to what access is
   being controlled.  In the context of naming it might be the names
   themselves (not the case for URNs), the mapping of URNs to hints (the
   business of an RDS), the mapping of URNs to addresses (not the
   business of an RDS as will be discussed below in terms of privacy),
   or the resource itself (unrelated to naming or name resolution at
   all).  We attempt to be clear about what is meant when using "access
   control".

   There is one further issue to address at this point, the distinction
   between mechanism and policy.  In general, a policy is realized by
   means of a set of mechanisms.  In the case of an RDS there may be
   policies internal to the RDS that it needs to have supported in order
   to do its business as it sees fit.  Since, in general it is in the
   business of storing and distributing information, most of its
   security policies may have to do with maintaining its own integrity,
   and are rather limited.  Beyond that, to the degree possible, it
   should impose no policy on its customers, the publishers and users.
   It is they that may have policies that they would like supported by
   the RDS.  To that end, an RDS should provide a spectrum of "tools" or
   mechanisms that the customers can cause to be deployed on their
   behalf to realize policies.  An RDS may not provide all that is
   needed by a customer.  A customer may have different requirements
   within his or her administrative bounds than outside.  Thus, "it must
   be possible..."  captures the idea that the RDS must generally
   provide the tools to implement policies as needed by the customers.

   The first approach to URN resolution is to discover local hints.  In
   order for hints to be discovered locally, they will need to be as
   widely distributed as possible to what is considered to be local for
   every locale.  The drawback of such wide distribution is the wide
   distribution of updates, causing network traffic problems or delays
   in delivering updates.  An alternative model would concentrate hint
   information in servers, thus requiring that update information only
   be distributed to these servers.  In such a model the vulnerable
   points are the sources of the information and the distribution
   network among them.  Attackers on the integrity of the information
   stored in a server may come in the form of masquerading as the owner
   or the server of the information.  Wide replication of information



Sollins                      Informational                     [Page 16]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   among servers increases the difficult of masquerading at all the
   locations of the information as well as reducing the threat of denial
   service.  These lead us to three identifiable guidelines for our
   security model:

   * ACCESS CONTROL ON HINTS: It must be possible to create an
     authoritative version of each hint with change control limited only
     to those principals with the right to modify it.  The choice of who
     those principals are or whether they are unlimited must be made by
     the publisher of a hint.

   * SERVER AUTHENTICITY: Servers and clients must be able to learn the
     identity of the servers with which they communicate.  This will be
     a matter of degree and it is possible that there will be more
     trustworthy, but less accessible servers, supported by a larger
     cluster of less authenticatable servers that are more widely
     available.  In the worst case, if the client receives what appears
     to be unvalidated information, the client should assume that the
     hint may be inaccurate and confirmation of the data might be sought
     from more reliable but less accessible sources.

   * SERVER DISTRIBUTION: Broad availability will provide resistance to
     denial of service.  It is only to the extent that the services are
     available that they provide any degree of trustworthiness.  In
     addition, the distribution of services will reduce vulnerability of
     the whole community, by reducing the trust put in any single
     server.  This must be mitigated by the fact that to the extent
     trust is based on a linked set of servers, if any one fails, the
     whole chain of trust fails; the more elements there are in such a
     chain, the more vulnerable it may become.

   Privacy can be a double-edged sword.  For example, on one hand, an
   organization may consider it critically important that its
   competitors not be able to read its traffic.  On the other hand, it
   may also consider it important to be able to monitor exactly what its
   employees are transmitting to and from whom, for a variety of reasons
   such as reducing the probability that its employees are giving or
   selling the company's secrets to verifying that employees are not
   using company resources for private endeavor.  Thus, although there
   are likely to be needs for privacy and confidentiality, what they
   are, who controls them and how, and by what mechanisms vary widely
   enough that it is difficult to say anything concrete about them here.

   The privacy of publishers is much easier to address.  Since they are
   trying to publish something, in general privacy is probably not
   desired.  However, publishers do have information that they might
   like to keep private: information about who their clients are, and
   information about what names exist in their namespace.  The



Sollins                      Informational                     [Page 17]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   information about who their clients are may be difficult to collect
   depending on the implementation of the resolution system.  For
   example, if the resolution information relating to a given publisher
   is widely replicated, the hits to _each_ replicated copy would need
   to be recorded.  Of course, determining if a specific client is
   requesting a given name can be approached from the other direction,
   by watching the client as we saw above.

   There are likely to be some publishers publishing for a restricted
   audience.  To the extent they want to restrict access to a resource,
   that is the responsibility of the repository providing and
   restricting access to the resource.  If they wish to keep the name
   and hints for a resource private, a public RDS may be inadequate for
   their needs.  In general, it is intended for those who want customers
   to find their resources in an unconstrained fashion.

   The final privacy issue for publishers has to do with access control
   over URN resolution.  This issue is dependent on the implementation
   of the publisher's authoritative (in the sense of "primary) URN
   resolver server.  URN resolver servers can be designed to require
   proof of identity in order to be issued resolution information; if
   the client does not have permission to access the URN requested, the
   service denies that such a URN exists.  An encrypted protocol can
   also be used so that both the request and the response are obscured.
   Encryption is possible in this case because the identity of the final
   recipient is known (i.e.  the URN server).  Thus, access control over
   URN resolution can and should be provided by resolver servers rather
   than an RDS.

4. The Framework

   With these assumptions and guidelines in mind, we conclude with a
   general framework within which RDS designs may fall.  As stated
   earlier, although this framework is put forth as a suggested guide
   for RDS designers, compliance with it will in no way guarantee
   compliance with the guidelines.  Such an evaluation must be performed
   separately.  All such lack of compliance should be clearly
   documented.

   The design of the framework is based on the syntax of a URN as
   documented in RFC-2141 [6].  This is:

                              URN:<NID>:<NSS>

   where URN: is a prefix on all URNs, NID is the namespace identifier,
   and NSS is the namespace specific string.  The prefix identifies each
   URN as such.  The NID determines the general syntax for all URNs
   within its namespace.  The NSS is probably partitioned into a set of



Sollins                      Informational                     [Page 18]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   delegated and subdelegated namespaces, and this is possibly reflected
   in further syntax specifications.  In more complex environments, each
   delegated namespace will be permitted to choose the syntax of the
   variable part of the namespace that has been delegated to it.  In
   simpler namespaces, the syntax will be restricted completely by the
   parent namespace.  For example, although the DNS does not meet all
   the requirements for URNs, it has a completely restricted syntax,
   such that any further structuring must be done only by adding further
   refinements to the left, maintaining the high order to low order,
   right to left structure.  A delegated syntax might be one in which a
   host is named by the DNS, but to the right of that and separated by
   an "@" is a string whose internal ordering is defined by the file
   system on the host, which may be defined high order to low order,
   left to right.  Of course, much more complex and nested syntaxes
   should be possible, especially given the need to grandfather
   namespaces.  In order to resolve URNs, rules will be needed for two
   reasons.  One is simply to canonicalize those namespaces that do not
   fall into a straightforward (probably right to left or left to right)
   ordering of the components of a URN, as determined by the delegated
   naming authorities involved.  It is also possible that rules will be
   needed in order to derive from URNs the names of RDS servers to be
   used in stages.





























Sollins                      Informational                     [Page 19]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


                            URN:<NID><NSS>
                                 |
                                 |
                                 |
                                 |
                                 v
                       +-------------------+
                       |Global NID registry|
                       +-------------------+
                                 |
                                 |
                                 |
              (return rule or URN resolver service reference)
                                 |
                                 +----------------------------------+
                                 |                                  |
                       +->(apply rule to determine RDS server)      |
                       |         |                                  |
                       |         |                                  |
                       |         |                                  |
                       |    +----------+                            |
                       |    |RDS server|          +-----------------+
                       |    +----------+          |
                       |      |   |               v
                       |      |   |   (set of choices)
                       |      |   +----+----------(...)--------+
                       |   (rule)      |                       |
                       |      |        |                       |
                       |      |        |                       |
                       +------+        |                       |
                                       v                       v
                                  +----------+            +----------+
                                  |URN       |            |URN       |
                                  |resolver  |            |resolver  |
                                  |service   |            |service   |
                                  +----------+            +----------+

                       Figure 1: An RDS framework

   The NID defines a top level syntax.  This syntax will determine
   whether the NID alone or in conjunction with some extraction from the
   NSS (for the top level naming authority name) is to be used to
   identify the first level server to be contacted.  At each stage of
   the lookup either a new rule for generating the strings used in yet
   another lookup (the strings being the identity of another RDS server
   and possibly a string to be resolved if it is different than the
   original URN) or a reference outside the RDS to a URN resolver
   service, sidestepping any further use of the RDS scheme.  Figure 1



Sollins                      Informational                     [Page 20]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


   depicts this process.

   There are several points worth noting about the RDS framework.
   First, it leaves open the determination of the protocols, data
   organization, distribution and replication needed to support a
   particular RDS scheme.  Second, it leaves open the location of the
   computations engendered by the rules.  Third, it leaves open the
   possibility that partitioning (distribution) of the RDS database need
   not be on the same boundaries as the name delegation.  This may seem
   radical to some, but if the information is stored in balanced B-trees
   for example, the partitioning may not be along those naming authority
   delegation boundaries (see [7]).  Lastly, it leaves open access to
   the Global NID Registry.  Is this distributed to every client, or
   managed in widely distributed servers?  It is important to note that
   it is the intention here that a single RDS scheme is likely to
   support names from many or all naming schemes, as embodied in their
   NIDs.

   One concept that has not been addressed in Figure 1 is that there may
   be more than one RDS available at any given time, in order to allow
   for evolution to new schemes.  Thus, the picture should probably look
   more like Figure 2.





























Sollins                      Informational                     [Page 21]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


                         URN:<NID>:<NSS>
                               |
                               |
                   +-----------+-------(...)-------+
                   |                               |
                   |                               |
                   |                               |
                   v                               v
         +---------------------+        +---------------------+
         |Global NID registry 1|        |Global NID registry N|
         +---------------------+        +---------------------+
                   .                               .
                   .                               .
                   .                               .


             Figure 2: More than one co-existing RDS scheme

   If we are to support more than one co-existing RDS scheme, there will
   need to be coordination among them with respect to storage and
   propagation of information and modifications.  The issue is that
   generally it should be assumed that all information should be
   available through any operational RDS scheme.  One cannot expect
   potential publishers to submit updates to more than one RDS scheme.
   Hence there will need to be a straightforward mapping of information
   from one to the other of these schemes.  It is possible that that
   transformation will only go in one direction, because a newer RDS
   service is replacing an older one, which is not kept up to date, in
   order to encourage transfer to the newer one.  Thus, at some point,
   updates may be made only to the newer one and not be made available
   to the older one, as is often done with library catalogs.

   This framework is presented in order to suggest to RDS scheme
   designers a direction in which to start designing.  It should be
   obvious to the reader that adherence to this framework will in no way
   guarantee compliance with the guidelines or even the assumptions
   described in Sections 2 and 3.  These must be reviewed independently
   as part of the design process.  There is no single correct design
   that will conform to these guidelines.  Furthermore, it is assumed
   that preliminary proposals may not meet all the guidelines, but
   should be expected to itemized and justify any lack of compliance.










Sollins                      Informational                     [Page 22]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


5. Acknowledgments

   Foremost acknowledgment for this document goes to Lewis Girod, as my
   co-author on a preliminary URN requirements document and for his
   insightful comments on this version of the document.  Thanks also go
   to Ron Daniel especially for his many comments on my writing.  In
   addition, I recognize the contributors to a previous URN framework
   document, the "Knoxville" group.  There are too many of you to
   acknowledge here individually, but thank you.  Finally, I must thank
   the contributors to the URN working group and mailing list (urn-
   ietf@bunyip.com), for your animated discussions on these and related
   topics.

6. References

   [1] Kunze, J., "Functional Recommendations for Internet Resource
   Locators", RFC 1736, February 1995.

   [2] Sollins, K., and L. Masinter, "Functional Requirements for
   Uniform Resource Names", RFC 1738, December 1994.

   [3] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
   Locators (URL)", RFC 1738, December 1994.

   [4] URN Working Group, "Namespace Identifier Requirements for URN
   Services," Work in Progress.

   [5] Voydock, V. L., and Kent, S. T., "Security Mechanisms in High-
   Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1983,
   pp. 135-171.

   [6] Moats, R., "URN Syntax", RFC 2141, May 1997.

   [7] Slottow, E.G., "Engineering a Global Resolution Service," MIT-
   LCS-TR712, June, 1997.  Currently available as
   <http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or
   <http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.

7. Author's Address

   Karen Sollins
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA 02139

   Phone: +1 617 253 6006
   EMail: sollins@lcs.mit.edu




Sollins                      Informational                     [Page 23]
^L
RFC 2276            Uniform Resource Name Resolution        January 1998


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Sollins                      Informational                     [Page 24]
^L