idnits 2.17.1 draft-ietf-uri-resource-names-02.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-03-29) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** 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 3 longer pages, the longest (page 3) being 64 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 Introduction section. ** The document seems to lack a Security Considerations 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 53 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 58 instances of lines with control characters in the document. 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? 'Berners-Lee 1993' on line 47 looks like a reference -- Missing reference section? 'Weider 1994' on line 217 looks like a reference -- Missing reference section? 'Spero 1992' on line 214 looks like a reference -- Missing reference section? 'Kunze 1993' on line 206 looks like a reference -- Missing reference section? 'Sollins 1994' on line 209 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET--DRAFT Chris Weider 2 IETF URI Working Group Bunyip Information 3 Systems, Inc. 4 Peter Deutsch 5 Bunyip Information 6 Systems, Inc. 7 July, 1994 9 Uniform Resource Names 10 12 Status of this Memo 14 In this paper, the authors propose an identifier, called the Uniform Resource 15 Name (URN), which is designed to provide persistent naming for resources 16 and objects on the Internet. 18 This document is an Internet Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its Areas, 20 and its Working Groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted 25 by other documents at any time. It is not appropriate to use 26 Internet Drafts as reference material or to cite them other than 27 as a "working draft" or "work in progress." 29 Please check the I-D abstract listing contained in each Internet 30 Draft directory to learn the current status of this or any 31 other Internet Draft. 33 This Internet Draft expires January 28, 1995. 35 1: Introduction 37 A Uniform Resource Name (URN) is an identifier which can be used to uniquely 38 identify a resource, and is designed to provide persistent naming for 39 networked objects. This name would stay the same no matter what the 40 current location(s) of the object was. 42 2: Motivation 44 This work comes out of the discussions held at the Uniform Resource Identifier 45 meetings at the IETF, and from further discussions among interested parties. 46 Currently, the only standard identification scheme for resources on the Net is 47 the Uniform Resource Locator (URL) [Berners-Lee 1993]. This "Locator" 48 is designed to provide a uniform way of specifying location and retrieval 49 information for networked objects. The URL, however, will not provide a stable, 50 long-lived reference to a resource as the resources have a bad habit of moving 51 out from under the locator. Also, a given resource may have multiple URLs if 52 it resides at a number of different locations on the net, or is available 53 under a number of different access methods. Thus it is difficult to tell, 54 given two different URLs, whether the resources they point to are the same 55 or different without retrieving both of them. The Uniform Resource Name, or 56 URN, has been designed to alleviate these problems. 58 INTERNET--DRAFT Uniform Resource Names Weider, Deutsch 60 3: The Uniform Resource Name (URN) 62 3.1 Functionality 64 The URN is designed to provide persistent naming for objects on the net. It 65 is intended to be used in conjunction with a directory service, which can 66 provide a URN -> URL mapping [Weider 1994]. This URN-URL architecture allows 67 permanent references to be made to resources without worrying about their 68 current locations. It is also intended to provide some detection of duplicates 69 in responses to queries of various resource location services. 71 3.2 What URNs are *not* 73 URNs are not required to be human-readable in the sense that a human could 74 look at the URN and determine anything about the contents of the resource. 75 While the Naming Authority (q.v.) has the final determination of the contents 76 (subject to the syntax constraints), the Naming Authority is STRONGLY 77 discouraged from placing metainformation about the resource into the resource's 78 URN, as the URNs are not expected to be read, and because this paper will 79 specify only five consistent components of the URN. Although there have been a 80 number of proposals placing extensive semantics on the contents of the URN 81 [Spero 1992, Kunze 1993], it was decided by the authors of all the proposals 82 that all metainformation should be conveyed using another mechanism, and that 83 the Naming Authority should assume that humans will never look at the contents 84 of the URN to determine qualities of the resource they are retrieving, and 85 would not be required to guess from a given URN the URN of a document which 86 might be related. 88 3.3 Components of the URN 90 There are four components to the URN, separated by colons; the keyword 91 'URN', a naming authority scheme identifier, a naming authority identifier, and an 92 opaque string. Each part is described below. 94 3.3.1 URN examples 96 98 100 101 INTERNET--DRAFT Uniform Resource Names Weider, Deutsch 103 3.3.2 The naming authority scheme identifier 105 The naming authority scheme identifier is a string which is the name of a 106 protocol or organization which guarantees the uniqueness of the naming 107 authority identifier which follows. Naming authority scheme identifiers defined 108 at this time are 110 IANA 111 ISBN 112 ISSN 114 3.3.4 The naming authority identifier 116 This string, along with the naming authority scheme identifier, identifies a 117 naming authority that may assign URNs to resources. This string may have 118 internal syntax depending on the naming authority scheme identifier associated 119 with it; for example, the naming authority identifier space associated with IANA 120 may be hierarchical and multi-leveled. 122 3.3.5 The Opaque String 124 The opaque string component of the URN is any string the Naming Authority 125 wishes to assign to a given resource, subject only to the constraints of the 126 allowed character set. 128 As mentioned above, the Naming Authority should not assume that a 129 human will ever read the URN. Also, the Naming Authority, in assigning an 130 opaque string to a given resource, should keep the following guidelines in 131 mind: 133 1: A given opaque string must be case-insensitive. 135 2: A given opaque string, once assigned, must never be reused. These 136 are expected to be persistent names for resources (think in terms 137 of decades). 139 3: In assigning an opaque string, and thus creating a URN, the Naming 140 Authority should make provisions for a URN -> URL mapping 141 function. This need be nothing more than finding an organization 142 which is already providing this service for other URNs and making 143 arrangements to have them translate for the new URN, or could 144 be as involved as creating a new software agent to provide this 145 service. Remember that a name is no good without some way of 146 getting a location. 148 4: URNs will be returned as pointers from a resource location service. 149 (See [Weider 1994]). Consequently, a Naming Authority should give 150 some thought to the assignation of new URNs for resources which 151 are derived in some fashion from other resources to which that 152 Authority has already assigned URNs. For example, should the 153 Postscript version and the ASCII version of a paper have the 154 same URN? While there are no universally applicable answers to 155 questions like these (for example, should the Russian and English 156 versions of a scientific paper have the same URN?) an Authority 157 should keep in mind that users will want to weed out duplicate 158 resources in the lists of URNs returned by a resource location 159 service, and consequently will be doing a lot of equality testing 160 on the URNs. 162 Several of these requirements are specified by the URN Requirements Document 163 [Sollins 1994] and must be adhered to. 165 INTERNET--DRAFT Uniform Resource Names Weider, Deutsch 167 4: Setting up as a Naming Authority 169 There are 2 scheme identifiers listed here; others will no doubt be suggested 170 and added as this draft circulates. They are: 172 IANA 173 ISBN 174 ISSN 176 To set one's organization up as a Naming Authority, one can use the ISBN 177 publisher ID one has been assigned, or one can apply for an Enterprise 178 Number from the IANA (Internet Assigned Number Authority) if the organization 179 does not already have one. The general syntax is listed in section 5. 181 5: Syntax 183 Below is a BNF like description of the syntax of the URN. Spaces have 184 been used here to separate components for readability, spaces are NOT ALLOWED 185 in a syntactically correct URN unless they are escaped with the '\' character. 186 Square brackets '[' and ']' are used to indicate optional parts; 187 a vertical line "|" indicates alternatives. Single letters and digits stand 188 for themselves. All words of more than one letter are either expanded further 189 in the syntax or represent themselves. 191 urn 193 Authority_Id Scheme_ID : [Individual ] 194 Scheme_ID IANA | ISBN | ISSN 195 Individual xalphas 196 xalphas xalpha [ xalphas ] 197 xalpha a | b | c | d | e | f | g | h | i | j | k | l | 198 m | n | o | p | q | r | s | t | u | v | w | x | 199 y | z | A | B | C | D | E | F | G | H | I | J | 200 K | L | M | N | O | P | Q | R | S | T | U | V | 201 W | X | Y | Z | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 202 9 | 0 | - | _ | . | @ 204 6: References 206 [Kunze 1993] Kunze, John, Resource Citations for Electronic Discovery and 207 Retrieval, March, 1993. Circulated to ietf-uri mailing list. 209 [Sollins 1994] Sollins, K, and Masinter, L. Requirements for Uniform Resource 210 Names, Internet Draft, June, 1994. Available as 212 ftp://nic.merit.edu/documents/internet-drafts/draft-sollins-urn-01.txt 214 [Spero 1992] Spero, Simon, Uniform Resource Numbers, November 1992. 215 Circulated to ietf-uri mailing list. 217 [Weider 1994] Weider, Chris and Deutsch, Peter. A Vision of an Integrated 218 Internet Information Service, July, 1994. Available as 220 ftp://nic.merit.edu/documents/internet-drafts/draft-ietf-iiir-vision-01.txt 221 INTERNET--DRAFT Uniform Resource Names Weider, Deutsch 223 7: Author's addresses 225 Chris Weider 226 clw@bunyip.com 227 Bunyip Information Systems, Inc. 228 2001 S. Huron Parkway #12 229 Ann Arbor, MI 48104 230 Phone: +1 (313) 971-2223 231 Fax: +1 (313) 971-2223 233 Peter Deutsch 234 peterd@bunyip.com 235 Bunyip Information Systems, Inc. 236 310 St-Catherine St West 237 suite 202, 238 Montreal, Quebec H2X 2A1 239 CANADA