GENWiki

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 uri@bunyip.com 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
   ability to find and parse URNs in free text.

4. Implications

 For a URN specification to be acceptible, it must meet the previous
 requirements.  We draw a set of conclusions, listed below, from those
 requirements; a specification that satisfies the requirments without
 meetings these conclusions is deemed acceptable, although unlikely to
 occur.

 o To satisfy the requirements of uniqueness and scalability, name
   assignment is delegated to naming authorities, who may then assign
   names directly or delegate that authority to sub-authorities.
   Uniqueness is guaranteed by requiring each naming authority to
   guarantee uniqueness.  The names of the naming authorities
   themselves are persistent and globally unique and top level
   authorities will be centrally registered.

 o Naming authorities that support scalable naming are encouraged, but
   not required.  Scalability implies that a scheme for devising names
   may be scalable both at its terminators as well as within the
   structure; e.g., in a hierarchical naming scheme, a naming
   authority might have an extensible mechanism for adding new
   sub-registries.

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

 o It is strongly recommended that there be a mapping between the
   names generated by each naming authority and URLs.  At any specific
   time there will be zero or more URLs into which a particular URN
   can be mapped.  The naming authority itself need not provide the
   mapping from URN to URL.

 o For URNs to be transcribable and transported in mail, it is
   necessary to limit the character set usable in URNs, although there
   is not yet consensus on what the limit might be.

 In assigning names, a name assignment authority must abide by the
 preceding constraints, as well as defining its own criteria for
 determining the necessity or indication of a new name assignment.

5. Other considerations

 There are three issues about which this document has intentionally
 not taken a position, because it is believed that these are issues to
 be decided by local determination or other services within an
 information infrastructure.  These issues are equality of resources,
 reflection of visible semantics in a URN, and name resolution.

 One of the ways in which naming authorities, the assigners of names,
 may choose to make themselves distinctive is by the algorithms by
 which they distinguish or do not distinguish resources from each
 other.  For example, a publisher may choose to distinguish among
 multiple printings of a book, in which minor spelling and
 typographical mistakes have been made, but a library may prefer not
 to make that distinction.  Furthermore, no one algorithm for testing
 for equality is likely to applicable to all sorts of information.
 For example, an algorithm based on testing the equality of two books
 is unlikely to be useful when testing the equality of two
 spreadsheets.  Thus, although this document requires that any
 particular naming authority use one algorithm for determining whether
 two resources it is comparing are the same or different, each naming
 authority can use a different such algorithm and a naming authority
 may restrict the set of resources it chooses to identify in any way
 at all.

 A naming authority will also have some algorithm for actually
 choosing a name within its namespace.  It may have an algorithm that
 actually embeds in some way some knowledge about the resource.  In
 turn, that embedding may or may not be made public, and may or may
 not be visible to potential clients.  For example, an unreflective
 URN, simply provides monotonically increasing serial numbers for
 resources.  This conveys nothing other than the identity determined
 by the equality testing algorithm and an ordering of name assignment
 by this server.  It carries no information about the resource itself.

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

 An MD5 of the resource at some point, in and of itself may be
 reflective of its contents, and, in fact, the naming authority may be
 perfectly willing to publish the fact that it is using MD5, but if
 the resource is mutable, it still will be the case that any potential
 client cannot do much with the URN other than check for equality.
 If, in contrast, a URN scheme has much in common with the assignment
 ISBN numbers, the algorithm for assigning them is public and by
 knowing it, given a particular ISBN number, one can learn something
 more about the resource in question.  This full range of
 possibilities is allowed according to this requirements document,
 although it is intended that naming authorities be discouraged from
 making accessible to clients semantic information about the resource,
 on the assumption that that may change with time and therefore it is
 unwise to encourage people in any way to depend on that semantics
 being valid.

 Last, this document intentionally does not address the problem of
 name resolution, other than to recommend that for each naming
 authority a name translation mechanism exist.  Naming authorities
 assign names, while resolvers or location services of some sort
 assist or provide URN to URL mapping.  There may be one or many such
 services for the resources named by a particular naming authority.
 It may also be the case that there are generic ones providing service
 for many resources of differing naming authorities.  Some may be
 authoritative and others not.  Some may be highly reliable or highly
 available or highly responsive to updates or highly focussed by other
 criteria such as subject matter.  Of course, it is also possible that
 some naming authorities will also act as resolvers for the resources
 they have named.  This document supports and encourages third party
 and distributed services in this area, and therefore intentionally
 makes no statements about requirements of URNs or naming authorities
 on resolvers.

Security Considerations

 Applications that require translation from names to locations, and
 the resources themselves may require the resources to be
 authenticated. It seems generally that the information about the
 authentication of either the name or the resource to which it refers
 should be carried by separate information passed along with the URN
 rather than in the URN itself.

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

Authors' Addresses

 Larry Masinter
 Xerox Palo Alto Research Center
 3333 Coyote Hill Road
 Palo Alto, CA 94304

 Phone: (415) 812-4365
 Fax:   (415) 812-4333
 EMail: masinter@parc.xerox.com

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

 Voice: (617) 253-6006
 Phone: (617) 253-2673
 EMail: sollins@lcs.mit.edu

Sollins & Masinter [Page 7]