PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc1737.txt =

page 3 of 4



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.




 
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.




 
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
=3=

1|2| < PREV = PAGE 3 = NEXT > |4

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0112269 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)