rfc1737.txt

RFC 的详细文档！

Network Working Group                                         K. Sollins
Request for Comments: 1737                                       MIT/LCS
Category: Informational                                      L. Masinter
                                                       Xerox Corporation
                                                           December 1994


           Functional Requirements for Uniform Resource Names

Status of this Memo

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

1.  Introduction

   This document specifies a minimum set of requirements for a kind of
   Internet resource identifier known as Uniform Resource Names (URNs).
   URNs fit within a larger Internet information architecture, which in
   turn is composed of, additionally, Uniform Resource Characteristics
   (URCs), and Uniform Resource Locators (URLs).  URNs are used for
   identification, URCs for including meta-information, and URLs for
   locating or finding resources.  It is provided as a basis for
   evaluating standards for URNs.  The discussions of this work have
   occurred on the mailing list [e-mail] and at the URI Working
   Group sessions of the IETF.

   The requirements described here are not necessarily exhaustive; for
   example, there are several issues dealing with support for
   replication of resources and with security that have been discussed;
   however, the problems are not well enough understood at this time to
   include specific requirements in those areas here.

   Within the general area of distributed object systems design, there
   are many concepts and designs that are discussed under the general
   topic of "naming". The URN requirements here are for a facility that
   addresses a different (and, in general, more stringent) set of needs
   than are frequently the domain of general object naming.

   The requirements for Uniform Resource Names fit within the overall
   architecture of Uniform Resource Identification.  In order to build
   applications in the most general case, the user must be able to
   discover and identify the information, objects, or what we will call
   in this architecture resources, on which the application is to
   operate.  Beyond this statement, the URI architecture does not define
   "resource."  As the network and interconnectivity grow, the ability
   to make use of remote, perhaps independently managed, resources will



Sollins & Masinter                                              [Page 1]

RFC 1737        Requirements for Uniform Resource Names    December 1994


   become more and more important.  This activity of discovering and
   utilizing resources can be broken down into those activities where
   one of the primary constraints is human utility and facility and
   those in which human involvement is small or nonexistent.  Human
   naming must have such characteristics as being both mnemonic and
   short.  Humans, in contrast with computers, are good at heuristic
   disambiguation and wide variability in structure.  In order for
   computer and network based systems to support global naming and
   access to resources that have perhaps an indeterminate lifetime, the
   flexibility and attendant unreliability of human-friendly names
   should be translated into a naming infrastructure more appropriate
   for the underlying support system.  It is this underlying support
   system that the Internet Information Infrastructure Architecture
   (IIIA) is addressing.

   Within the IIIA, several sorts of information about resources are
   specified and divided among different sorts of structures, along
   functional lines.  In order to access information, one must be able
   to discover or identify the particular information desired,
   determined both how and where it might be used or accessed.  The
   partitioning of the functionality in this architecture is into
   uniform resource names (URN), uniform resource characteristics (URC),
   and uniform resource locators (URL).  A URN identifies a resource or
   unit of information.  It may identify, for example, intellectual
   content, a particular presentation of intellectual content, or
   whatever a name assignment authority determines is a distinctly
   namable entity.  A URL identifies the location or a container for an
   instance of a resource identified by a URN.  The resource identified
   by a URN may reside in one or more locations at any given time, may
   move, or may not be available at all.  Of course, not all resources
   will move during their lifetimes, and not all resources, although
   identifiable and identified by a URN will be instantiated at any
   given time.  As such a URL is identifying a place where a resource
   may reside, or a container, as distinct from the resource itself
   identified by the URN.  A URC is a set of meta-level information
   about a resource.  Some examples of such meta-information are: owner,
   encoding, access restrictions (perhaps for particular instances),
   cost.

   With this in mind, we can make the following statement:

   o  The purpose or function of a URN is to provide a globally unique,
      persistent identifier used for recognition, for access to
      characteristics of the resource or for access to the resource
      itself.






Sollins & Masinter                                              [Page 2]

RFC 1737        Requirements for Uniform Resource Names    December 1994


   More specifically, there are two kinds of requirements on URNs:
   requirements on the functional capabilities of URNs, and requirements
   on the way URNs are encoded in data streams and written
   communications.

2. Requirements for functional capabilities

   These are the requirements for URNs' functional capabilities:

   o Global scope: A URN is a name with global scope which does not
     imply a location.  It has the same meaning everywhere.

   o Global uniqueness: The same URN will never be assigned to two
     different resources.

   o Persistence: It is intended that the lifetime of a URN be
     permanent.  That is, the URN will be globally unique forever, and
     may well be used as a reference to a resource well beyond the
     lifetime of the resource it identifies or of any naming authority
     involved in the assignment of its name.

   o Scalability: URNs can be assigned to any resource that might
     conceivably be available on the network, for hundreds of years.

   o Legacy support: The scheme must permit the support of existing
     legacy naming systems, insofar as they satisfy the other
     requirements described here. For example, ISBN numbers, ISO
     public identifiers, and UPC product codes seem to satisfy the
     functional requirements, and allow an embedding that satisfies
     the syntactic requirements described here.

   o Extensibility: Any scheme for URNs must permit future extensions to
     the scheme.

   o Independence: It is solely the responsibility of a name issuing
     authority to determine the conditions under which it will issue a
     name.

   o Resolution: A URN will not impede resolution (translation into a
     URL, q.v.). To be more specific, for URNs that have corresponding
     URLs, there must be some feasible mechanism to translate a URN to a
     URL.

3. Requirements for URN encoding

   In addition to requirements on the functional elements of the URNs,
   there are requirements for how they are encoded in a string:




Sollins & Masinter                                              [Page 3]

RFC 1737        Requirements for Uniform Resource Names    December 1994


   o Single encoding: The encoding for presentation for people in clear
     text, electronic mail and the like is the same as the encoding in
     other transmissions.

   o Simple comparison: A comparison algorithm for URNs is simple,
     local, and deterministic. That is, there is a single algorithm for
     comparing two URNs that does not require contacting any external
     server, is well specified and simple.

   o Human transcribability: For URNs to be easily transcribable by
     humans without error, they should be short, use a minimum of
     special characters, and be case insensitive. (There is no strong
     requirement that it be easy for a human to generate or interpret a
     URN; explicit human-accessible semantics of the names is not a
     requirement.)  For this reason, URN comparison is insensitive to
     case, and probably white space and some punctuation marks.

   o Transport friendliness: A URN can be transported unmodified in the
     common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as
     well as printed paper.

   o Machine consumption: A URN can be parsed by a computer.

   o Text recognition: The encoding of a URN should enhance the