idnits 2.17.1 draft-ietf-urn-nid-req-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-04-25) 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 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 255 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 51 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2168,RFC2169], [RFC2141]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 38 has weird spacing: '...rt from proof...' -- 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) == Unused Reference: 'RFC1737' is defined on line 188, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2168 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Downref: Normative reference to an Historic RFC: RFC 2169 ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 1737 Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Leslie L. Daigle 3 November 19, 1997 Bunyip Information Systems 4 draft-ietf-urn-nid-req-02.txt Dirk-Willem van Gulik 5 ISIS/CEO, JRC Ispra 6 Renato Iannella 7 DSTC Pty Ltd 8 Patrik Faltstrom 9 Tele2/Swipnet 11 URN Namespace Registration and Standardization Process Mechanisms 13 Status of this Document 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 30 Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 The URN WG has defined a syntax for Uniform Resource Names 35 (URNs) [RFC2141], as well as some proposed mechanisms for their 36 resolution and use in Internet applications ([RFC2168, RFC2169]). 37 The whole rests on the concept of individual ''namespaces'' within the 38 URN structure. Apart from proof-of-concept namespaces, the use 39 of existing identifiers in URNs has been discussed (??? biblio id 40 document). This document lays out general definitions of and mechanisms 41 for establishing URN ''namespaces''. 43 Foreword to this Edition 45 This document is a very drafty draft. The intention of this version 46 is to lay out the groundwork for some proposed processes. Detail will 47 be needed. No one has formally approached IANA to set up the registry 48 this is defining. The model here is not unlike media type registrations. 50 Introduction 52 For the purposes of URNs, a "namespace" is a collection of uniquely-assigned 53 identifiers. A URN namespace itself has an identifier in order to 55 . ensure global uniqueness of URNs 56 . (where desired) provide a cue for the structure of the identifier 58 For example, ISBNs and ISSNs are both collections of identifiers used 59 in the traditional publishing world; while there may some number (or numbers) 60 that is both a valid ISBN identifier and ISSN identifier, using different 61 designators for the two collections ensures that no two URNs will be the same 62 for different resources. 64 The development of an identifier structure, and thereby a collection 65 of identifiers, is a process that is inherently dependent on the needs 66 of the identifiers, how they will be assigned, and the uses to which they 67 will be put. All of these issues are beyond the scope of the URN 68 work. 70 This document concerns itself with the mechanical processes of associating 71 an identifier string with a predefined namespace and publication of 72 identifier structures. Of particular concern are: 74 . selection of strings to associate with a namespace 75 . publication of structural elements of the identifiers 76 . identification of support infrastructure for assignment 77 and resolution of URNs for a given namespace 78 . determination of failure of support for a namespace 80 Different levels of disclosure are expected/defined for namespaces. 81 According to the level of discussion and standardization surrounding the 82 disclosure, a URN namespace may be assigned or may request a particular 83 identifier. 85 Note that this document restricts itself to the description of processes 86 for the creation of URN namespaces. If "resolution" of any so-created 87 URN identifiers is desired, a separate process of registration in a global 88 NID directory, such as that provided by the NAPTR [Ref ??] system, is 89 necessary. 91 URN Namespace Categories 93 There are 4 categories of URN namespaces defined here, distinguished by 94 expected level of service and required procedures for registration. 96 The first three are simple namespace types: 98 I. Experimental: These are not registered with IANA. They take the 99 form 100 x- 102 II. Informal: These are registered with IANA (see Section ??), and 103 are assigned a number based on a private OID ("POID" 104 namespaces). 106 III. Standardized: These are processed through a full standards-track 107 RFC review process. The NID may be any valid NID string 108 that does not clash with an existing, registered NID. 110 The fourth is a composite namespace type (i.e., one constructed for 111 the express purpose of later subdivision): 113 IV. Top-level: These are processed through a full standards-track 114 RFC review process. The result is not a NID so much 115 as a top-level NID structure, which will be subdivided by the 116 rules laid out in the top-level NID RFC. These NID 117 strings must not clash with existing, registered NIDs; 118 additionally, the RFC1766 country code strings are 119 reserved for use by countries that desire to so-obtain 120 a top-level NID. 122 Registration Procedures 124 To register a namespace (for type II namespaces, informal), the following 125 information must be provided to the IANA: 127 Declared owner of the namespace 128 Description of: 130 . uniqueness of identifiers assigned by the namespace's naming 131 authority 132 . process of assignment of identfiers in the namespace 133 . rules for determining lexical equivalence between identifiers in the 134 namespace 135 . identification of validation mechanism (to ascertain whether or 136 not a string is in fact a valid URN in the namespace). This 137 can include: 138 . a syntax grammar 139 . an on-line service 140 . an off-line service 141 . conformance with RFC1737 requirements (??? these should be 142 listed out) 144 The namespace is then identified by the declared owner's private OID (POID) 145 and a suffix to distinguish among different namespaces assigned to the 146 same POID: POID.## 148 Standardization Process 150 To establish a standardized URN namespace, the following information 151 must be described and vetted in an IETF standards-track RFC: 153 Declared owner of the namespace 154 Desired NID 155 Description of: 157 . uniqueness of identifiers assigned by the namespace's naming 158 authority 159 . process of assignment of identfiers in the namespace 160 . rules for determining lexical equivalence between identifiers in the 161 namespace 162 . conformance with RFC1737 requirements (??? these should be 163 listed out) 164 . identification of validation mechanism (to ascertain whether or 165 not a string is in fact a valid URN in the namespace) (??? in 166 this case, it is required to be one of whois, finger, mail 167 service) 168 . match of scope, ownership, and/or global applicability. (?? E.g., 169 you can't ask for "social security numbers", but the US 170 may ask for US social security numbers). 172 Examples 174 Security Considerations 176 (??? THere will most assuredly be some!). 178 References 180 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource 181 Identifiers using the Domain Name System", RFC 2168 June 1997. 183 [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution", 184 RFC 2169, June 1997. 186 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 188 [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements for 189 Uniform Resource Names", RFC1737, December 1994 191 Authors' Addresses 193 Leslie L. Daigle 194 Bunyip Information Systems Inc 195 310 Ste. Catherine St. W 196 Suite 300 197 Montreal, Quebec, CANADA 198 H2X 2A1 199 voice: +1 514 875-8611 200 fax: +1 514 875-8134 201 email: leslie@bunyip.com 203 Dirk-Willem van Gulik 204 ISIS/STA/CEO - TP 270 205 Joint Research Centre Ispra 206 21020 Ispra (Va) 207 Italy. 208 voice: +39 332 78 9549 or 5044 209 fax: +39 332 78 9185 210 email: Dirk.vanGulik@jrc.it 212 Renato Iannella 213 DSTC Pty Ltd 214 Gehrmann Labs, The Uni of Queensland 215 AUSTRALIA, 4072 216 voice: +61 7 3365 4310 217 fax: +61 7 3365 4311 218 email: renato@dstc.edu.au 220 Patrik Faltstrom 221 Tele2/Swipnet 222 Borgarfjordsgatan 16 223 P.O. Box 62 224 S-164 94 Kista 225 SWEDEN 226 voice: +46-5626 4000 227 fax: +46-5626 4200 228 email: paf@swip.net