INTERNET DRAFT Renato Iannella draft-ietf-urn-nid-req-01.txt DSTC Pty Ltd 25 March, 1997 Patrik Faltstrom Tele2/Swipnet Namespace Identifier Requirements for URN Services Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as `work in progress.' To learn the current status of any Internet-Draft, please check the `1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 25 September, 1997. Abstract: ========= Services that offer to resolve Uniform Resource Names implicitly require that they support a persistent and reliable service for an indeterminate length of time. This draft outlines the requirements for any such service that wishes to participate as a Namespace Identifier. Introduction: ============= The Uniform Resource Name (URN) Working Group has defined mechanisms for both the syntax [4] and resolution of URNs [1,2]. An framework for URN discovery systems has also been outlined [3]. This draft discusses and recommends the requirements for entities that wish to act as Namespace Identifiers (NIDs) within the URN system. The URN syntax includes the NID which acts as the scoping indicator for the URN. The NID indicates which Namespace the URN belongs to and gives hints to the underlying resolution service. Consider the following example URNs: urn:znet:metadata.net:dc urn:buns:555555:annual-report urn:hoptus:priv:555-ABCD The NIDs in these cases, "znet", "buns", and "hoptus" all act as top-level namespaces, and hence, must meet certain guidelines to ensure meeting all the URN requirements [5]. In particular: - Global Scope and Uniqueness - Persistence - Independence - Resolution Requirements: ============= Given the four categories above, the requirements for each our now outlined. Global Scope and Uniqueness. - The NID must be registered with IANA to ensure uniqueness and demonstrating that it meets the requirements listed in this document. - A simple and limited character set should be imposed to support global access (as described in [4]). - Rules on how the Namespace Specific String are allocated must be documented. - Definitions of terms like "equal" and "different" for resources must be published. Persistence - The NID service providers must show that they intend to support the service for an indefinite period of time. - Support facilities must be described and how the service intends to operate, including "disaster recovery"-like operations. - Demonstrated experience in managing an established namespace system is essential. - One URN should never be reused for a different resource (where "different" is defined as in previous paragraph by the namespace). The URN should be persistent for all times, even though the resource goes away. Independence - The NID service providers must also show any relationship (both technical and administrative) that may impede on the provision of the URN service. - However, multi-party participation in the NID service is an advantage. Resolution - The NID service providers must produce an RFC describing the technical characteristics of the URN resolution service, including security considerations. - The NID service providers may elect not to have the resolution service publically available. Example: ======= (1) urn:buns:555555:annual-report This URN, in the namespace called "buns" is referring to the document named annual-report, in postscript format. At a later stage, that resource is replaced by a text version, which lacks the pictures, but that is ok, because the namespace has decided that postscript format documents and text documents are considered the same even though the figures doesn't exist in the textual version. In the third stage, the report is removed, and replaced with a report for a different year. This new report gets a new URN because it is considered being a different document. The old URN is never reused. (2) urn:foo:bar:current-weather urn:foo:bar:weather/19970325 These are two URNs referring at one stage to the same resource, i.e. on the 25th of March 1997. On the 26th of March 1997, urn:foo:bar:current-weather is referring to the same resource as urn:foo:bar:weather/19970326. Conclusion: =========== This draft has outlined the requirements for providers of NID services for URN systems. The objective is to maintain a high persistence rate for URN services, and these requirements are aimed at ensuring a high level of service stability. References: =========== [1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, February, 1997. [2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution", draft-ietf-urn-http-conv-01.txt, February 1997 [3] Karen R Sollins, "Requirements and a Framework for URN Resolution Systems", draft-ietf-urn-req-frame-00.txt, November 1996 [4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997. [5] Karen R Sollins & Larry Masinter, "Functional Requirements for Uniform Resource Names", RFC1737, December 1994 Security Considerations ======================= It is a requirement that it in the definitions of a namespace are included sections on security covering for example: + Spoofing of servers + Verification of responses Because a namespace can decide that a resolution service is not publically available, it is possible to use firewall installations and other traffic limiting constructions to diconnect the namespace from the global Internet. Author Contact Information: =========================== Renato Iannella DSTC Pty Ltd Gehrmann Labs, The Uni of Queensland AUSTRALIA, 4072 voice: +61 7 3365 4310 fax: +61 7 3365 4311 email: renato@dstc.edu.au Patrik Faltstrom Tele2/Swipnet Borgarfjordsgatan 16 P.O. Box 62 S-164 94 Kista SWEDEN voice: +46-5626 4000 fax: +46-5626 4200 email: paf@swip.net