home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_u_z / draft-ietf-urn-nid-req-00.txt < prev    next >
Text File  |  1997-03-27  |  7KB  |  218 lines
  1.  
  2. INTERNET DRAFT                                             Renato Iannella
  3. draft-ietf-urn-nid-req-01.txt                                 DSTC Pty Ltd
  4. 25 March, 1997                                            Patrik Faltstrom
  5.                                                              Tele2/Swipnet
  6.  
  7.             Namespace Identifier Requirements for URN Services
  8.  
  9.  
  10.  
  11. Status of this Memo
  12. ===================
  13.  
  14.     This document is an Internet-Draft.  Internet-Drafts are working
  15.     documents of the Internet Engineering Task Force (IETF), its
  16.     areas, and its working groups.  Note that other groups may also
  17.     distribute working documents as Internet-Drafts.
  18.   
  19.     Internet-Drafts are draft documents valid for a maximum of six
  20.     months and may be updated, replaced, or obsoleted by other
  21.     documents at any time.  It is inappropriate to use Internet-
  22.     Drafts as reference material or to cite them other than as
  23.     `work in progress.'
  24.  
  25.     To learn the current status of any Internet-Draft, please check
  26.     the `1id-abstracts.txt' listing contained in the Internet-
  27.     Drafts Shadow Directories on ftp.is.co.za (Africa),
  28.     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  29.     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  30.  
  31.     This draft expires 25 September, 1997.
  32.  
  33.  
  34. Abstract:
  35. =========
  36.  
  37. Services that offer to resolve Uniform Resource Names implicitly
  38. require that they support a persistent and reliable service for an
  39. indeterminate length of time. This draft outlines the requirements for
  40. any such service that wishes to participate as a Namespace Identifier.
  41.  
  42.  
  43. Introduction:
  44. =============
  45.  
  46. The Uniform Resource Name (URN) Working Group has defined mechanisms
  47. for both the syntax [4] and resolution of URNs [1,2]. An framework
  48. for URN discovery systems has also been outlined [3]. This draft
  49. discusses and recommends the requirements for entities that wish
  50. to act as Namespace Identifiers (NIDs) within the URN system.
  51.  
  52. The URN syntax includes the NID which acts as the scoping
  53. indicator for the URN. The NID indicates which Namespace
  54. the URN belongs to and gives hints to the underlying resolution
  55. service.
  56.  
  57. Consider the following example URNs:
  58.  
  59.    urn:znet:metadata.net:dc
  60.    urn:buns:555555:annual-report
  61.    urn:hoptus:priv:555-ABCD
  62.  
  63.  
  64. The NIDs in these cases, "znet", "buns", and "hoptus" all
  65. act as top-level namespaces, and hence, must meet certain
  66. guidelines to ensure meeting all the URN requirements [5].
  67. In particular:
  68.    - Global Scope and Uniqueness
  69.    - Persistence
  70.    - Independence
  71.    - Resolution
  72.  
  73.  
  74. Requirements:
  75. =============
  76.  
  77. Given the four categories above, the requirements for each our
  78. now outlined.
  79.  
  80.  
  81.  Global Scope and Uniqueness.
  82.  
  83.   - The NID must be registered with IANA to ensure uniqueness and
  84.     demonstrating that it meets the requirements listed in this
  85.     document.
  86.   - A simple and limited character set should be imposed to 
  87.     support global access (as described in [4]).
  88.   - Rules on how the Namespace Specific String are allocated
  89.     must be documented.
  90.   - Definitions of terms like "equal" and "different" for resources
  91.     must be published.
  92.  
  93.  Persistence
  94.  
  95.   - The NID service providers must show that they intend to
  96.     support the service for an indefinite period of time.
  97.   - Support facilities must be described and how the service
  98.     intends to operate, including "disaster recovery"-like
  99.     operations.
  100.   - Demonstrated experience in managing an established namespace
  101.     system is essential.    
  102.   - One URN should never be reused for a different resource (where
  103.     "different" is defined as in previous paragraph by the namespace).
  104.     The URN should be persistent for all times, even though the
  105.     resource goes away.
  106.  
  107.  Independence
  108.  
  109.   - The NID service providers must also show any relationship
  110.     (both technical and administrative) that may impede on the
  111.     provision of the URN service.
  112.   - However, multi-party participation in the NID service is
  113.     an advantage.
  114.  
  115.  Resolution
  116.  
  117.   - The NID service providers must produce an RFC
  118.     describing the technical characteristics of the URN
  119.     resolution service, including security considerations.
  120.   - The NID service providers may elect not to have the
  121.     resolution service publically available.
  122.  
  123.  
  124. Example:
  125. =======
  126.  
  127. (1) urn:buns:555555:annual-report
  128.  
  129. This URN, in the namespace called "buns" is referring to the
  130. document named annual-report, in postscript format. 
  131.  
  132. At a later stage, that resource is replaced by a text version, which
  133. lacks the pictures, but that is ok, because the namespace has decided
  134. that postscript format documents and text documents are considered the
  135. same even though the figures doesn't exist in the textual version.
  136.  
  137. In the third stage, the report is removed, and replaced with a report
  138. for a different year. This new report gets a new URN because it is
  139. considered being a different document.
  140.  
  141. The old URN is never reused.
  142.  
  143. (2) urn:foo:bar:current-weather
  144.     urn:foo:bar:weather/19970325
  145.  
  146. These are two URNs referring at one stage to the same resource, i.e.
  147. on the 25th of March 1997. On the 26th of March 1997,
  148. urn:foo:bar:current-weather is referring to the same resource as
  149. urn:foo:bar:weather/19970326.
  150.  
  151. Conclusion:
  152. ===========
  153.  
  154. This draft has outlined the requirements for providers of
  155. NID services for URN systems. The objective is to maintain 
  156. a high persistence rate for URN services, and these requirements
  157. are aimed at ensuring a high level of service stability.
  158.  
  159.  
  160.  
  161. References:
  162. ===========
  163.  
  164. [1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
  165.     Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
  166.     February, 1997.
  167.  
  168. [2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
  169.     draft-ietf-urn-http-conv-01.txt, February 1997
  170.  
  171. [3] Karen R Sollins, "Requirements and a Framework for URN Resolution
  172.     Systems", draft-ietf-urn-req-frame-00.txt, November 1996
  173.  
  174. [4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.
  175.  
  176. [5] Karen R Sollins & Larry Masinter, "Functional Requirements for
  177.     Uniform Resource Names", RFC1737, December 1994
  178.  
  179.  
  180. Security Considerations
  181. =======================
  182.  
  183. It is a requirement that it in the definitions of a namespace are
  184. included sections on security covering for example:
  185.  
  186.   + Spoofing of servers
  187.   + Verification of responses
  188.  
  189. Because a namespace can decide that a resolution service is not
  190. publically available, it is possible to use firewall installations and
  191. other traffic limiting constructions to diconnect the namespace from
  192. the global Internet.
  193.  
  194. Author Contact Information:
  195. ===========================
  196.  
  197. Renato Iannella
  198. DSTC Pty Ltd
  199. Gehrmann Labs, The Uni of Queensland
  200. AUSTRALIA, 4072
  201. voice:  +61 7 3365 4310
  202. fax:    +61 7 3365 4311
  203. email:  renato@dstc.edu.au
  204.  
  205.  
  206. Patrik Faltstrom
  207. Tele2/Swipnet
  208. Borgarfjordsgatan 16
  209. P.O. Box 62
  210. S-164 94 Kista
  211. SWEDEN
  212. voice:  +46-5626 4000
  213. fax:    +46-5626 4200
  214. email:  paf@swip.net
  215.  
  216.  
  217.  
  218.