rfc2276.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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]

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]

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]

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]

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]

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;