rfc2276.txt

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

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