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.







 
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:





 
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.