rfc2276.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,313 行 · 第 1/5 页

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