rfc1737.txt

RFC 的详细文档！

     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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Voice: [phone]
   Phone: [phone]
   EMail: [e-mail]































Sollins & Masinter                                              [Page 7]