idnits 2.17.1 draft-ietf-urn-nid-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 216 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '4' on line 163 looks like a reference -- Missing reference section? '1' on line 153 looks like a reference -- Missing reference section? '2' on line 157 looks like a reference -- Missing reference section? '3' on line 160 looks like a reference -- Missing reference section? '5' on line 165 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Renato Iannella 2 draft-ietf-urn-nid-req-01.txt DSTC Pty Ltd 3 25 March, 1997 Patrik Faltstrom 4 Tele2/Swipnet 6 Namespace Identifier Requirements for URN Services 8 Status of this Memo 9 =================== 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 `work in progress.' 22 To learn the current status of any Internet-Draft, please check 23 the `1id-abstracts.txt' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 This draft expires 25 September, 1997. 30 Abstract: 31 ========= 33 Services that offer to resolve Uniform Resource Names implicitly 34 require that they support a persistent and reliable service for an 35 indeterminate length of time. This draft outlines the requirements for 36 any such service that wishes to participate as a Namespace Identifier. 38 Introduction: 39 ============= 41 The Uniform Resource Name (URN) Working Group has defined mechanisms 42 for both the syntax [4] and resolution of URNs [1,2]. An framework 43 for URN discovery systems has also been outlined [3]. This draft 44 discusses and recommends the requirements for entities that wish 45 to act as Namespace Identifiers (NIDs) within the URN system. 47 The URN syntax includes the NID which acts as the scoping 48 indicator for the URN. The NID indicates which Namespace 49 the URN belongs to and gives hints to the underlying resolution 50 service. 52 Consider the following example URNs: 54 urn:znet:metadata.net:dc 55 urn:buns:555555:annual-report 56 urn:hoptus:priv:555-ABCD 58 The NIDs in these cases, "znet", "buns", and "hoptus" all 59 act as top-level namespaces, and hence, must meet certain 60 guidelines to ensure meeting all the URN requirements [5]. 61 In particular: 62 - Global Scope and Uniqueness 63 - Persistence 64 - Independence 65 - Resolution 67 Requirements: 68 ============= 70 Given the four categories above, the requirements for each our 71 now outlined. 73 Global Scope and Uniqueness. 75 - The NID must be registered with IANA to ensure uniqueness and 76 demonstrating that it meets the requirements listed in this 77 document. 78 - A simple and limited character set should be imposed to 79 support global access (as described in [4]). 80 - Rules on how the Namespace Specific String are allocated 81 must be documented. 82 - Definitions of terms like "equal" and "different" for resources 83 must be published. 85 Persistence 87 - The NID service providers must show that they intend to 88 support the service for an indefinite period of time. 89 - Support facilities must be described and how the service 90 intends to operate, including "disaster recovery"-like 91 operations. 92 - Demonstrated experience in managing an established namespace 93 system is essential. 94 - One URN should never be reused for a different resource (where 95 "different" is defined as in previous paragraph by the namespace). 96 The URN should be persistent for all times, even though the 97 resource goes away. 99 Independence 101 - The NID service providers must also show any relationship 102 (both technical and administrative) that may impede on the 103 provision of the URN service. 104 - However, multi-party participation in the NID service is 105 an advantage. 107 Resolution 109 - The NID service providers must produce an RFC 110 describing the technical characteristics of the URN 111 resolution service, including security considerations. 112 - The NID service providers may elect not to have the 113 resolution service publically available. 115 Example: 116 ======= 118 (1) urn:buns:555555:annual-report 120 This URN, in the namespace called "buns" is referring to the 121 document named annual-report, in postscript format. 123 At a later stage, that resource is replaced by a text version, which 124 lacks the pictures, but that is ok, because the namespace has decided 125 that postscript format documents and text documents are considered the 126 same even though the figures doesn't exist in the textual version. 128 In the third stage, the report is removed, and replaced with a report 129 for a different year. This new report gets a new URN because it is 130 considered being a different document. 132 The old URN is never reused. 134 (2) urn:foo:bar:current-weather 135 urn:foo:bar:weather/19970325 137 These are two URNs referring at one stage to the same resource, i.e. 138 on the 25th of March 1997. On the 26th of March 1997, 139 urn:foo:bar:current-weather is referring to the same resource as 140 urn:foo:bar:weather/19970326. 142 Conclusion: 143 =========== 145 This draft has outlined the requirements for providers of 146 NID services for URN systems. The objective is to maintain 147 a high persistence rate for URN services, and these requirements 148 are aimed at ensuring a high level of service stability. 150 References: 151 =========== 153 [1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource 154 Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, 155 February, 1997. 157 [2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution", 158 draft-ietf-urn-http-conv-01.txt, February 1997 160 [3] Karen R Sollins, "Requirements and a Framework for URN Resolution 161 Systems", draft-ietf-urn-req-frame-00.txt, November 1996 163 [4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997. 165 [5] Karen R Sollins & Larry Masinter, "Functional Requirements for 166 Uniform Resource Names", RFC1737, December 1994 168 Security Considerations 169 ======================= 171 It is a requirement that it in the definitions of a namespace are 172 included sections on security covering for example: 174 + Spoofing of servers 175 + Verification of responses 177 Because a namespace can decide that a resolution service is not 178 publically available, it is possible to use firewall installations and 179 other traffic limiting constructions to diconnect the namespace from 180 the global Internet. 182 Author Contact Information: 183 =========================== 185 Renato Iannella 186 DSTC Pty Ltd 187 Gehrmann Labs, The Uni of Queensland 188 AUSTRALIA, 4072 189 voice: +61 7 3365 4310 190 fax: +61 7 3365 4311 191 email: renato@dstc.edu.au 193 Patrik Faltstrom 194 Tele2/Swipnet 195 Borgarfjordsgatan 16 196 P.O. Box 62 197 S-164 94 Kista 198 SWEDEN 199 voice: +46-5626 4000 200 fax: +46-5626 4200 201 email: paf@swip.net