idnits 2.17.1 draft-ietf-urn-nid-req-03.txt: ** The Abstract section seems to be numbered 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-19) 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 490 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 140 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2288], [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...' == Line 289 has weird spacing: '...n-forum discu...' -- 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 400, 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 ** Downref: Normative reference to an Informational RFC: RFC 2288 ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 1737 ** Downref: Normative reference to an Informational RFC: RFC 2276 Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Leslie L. Daigle 3 March 11, 1998 Bunyip Information Systems 4 draft-ietf-urn-nid-req-03.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 Definition 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 0.0 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 ([RFC2288]), 40 and this document lays out general definitions of and 41 mechanisms for establishing URN ''namespaces''. 43 0.1 Foreword to this Edition 45 For the purposes of this document, an "IANA-like" entity is assumed to 46 exist. Anywhere the term "IANA" appears, consider it a pointer to 47 whatever organization or entity exists to handle Internet 48 registration/assignment tasks. 50 Still notably absent: 52 . where to _send_ and/or _discuss_ the declarations 53 defined here 54 . process mechanisms for assigning/obtaining specific NIDs. 56 These details must wait until there is general resolution re. 57 Internet assigned numbers. 59 1.0 Introduction 61 Uniform Resource Names (URNs) are resource identifiers with the 62 specific requirements for enabling location independent 63 identification of a resource, as well as longevity of reference. 64 There are 2 assumptions that are key to this document: 66 Assumption #1: 68 Assignment of a URN is a managed process. 70 I.e., not all strings that conform to URN syntax are necessarily 71 valid URNs. A URN is assigned according to the rules of a 72 particular namespace (in terms of syntax, semantics, and process). 74 Assumption #2: 76 The space of URN namespaces is managed. 78 I.e., not all syntactically correct URN namespaces (per the URN 79 syntax definition) are valid URN namespaces. A URN namespace 80 must have a recognized definition in order to be valid. 82 The purpose of this document is to outline a mechanism and provide a 83 template for explicit namespace definition, along with the mechanism 84 for associating an identifier (called a "Namespace ID", or NID) which 85 is registered with the IANA. 87 Note that this document restricts itself to the description of 88 processes for the creation of URN namespaces. If "resolution" of any 89 so-created URN identifiers is desired, a separate process of 90 registration in a global NID directory, such as that provided by the 91 NAPTR system [RFC2168], is necessary. 93 2.0 What is a URN Namespace? 95 For the purposes of URNs, a "namespace" is a collection of 96 uniquely-assigned identifiers. A URN namespace itself has an 97 identifier in order to 99 . ensure global uniqueness of URNs 100 . (where desired) provide a cue for the structure of the 101 identifier 103 For example, ISBNs and ISSNs are both collections of identifiers used 104 in the traditional publishing world; while there may some number (or 105 numbers) that is both a valid ISBN identifier and ISSN identifier, 106 using different designators for the two collections ensures that no 107 two URNs will be the same for different resources. 109 The development of an identifier structure, and thereby a collection 110 of identifiers, is a process that is inherently dependent on the needs 111 of the identifiers, how they will be assigned, and the uses to which 112 they will be put. All of these issues are specific to the individual 113 community seeking to define a namespace (e.g., publishing community, 114 association of booksellers, protocol developers, etc); they are beyond 115 the scope of the IETF URN work. 117 This document outlines the processes by which a collection of 118 identifiers satisfying certain constraints (uniqueness of assignment, 119 etc) can become a bona fide URN namespace by obtaining a NID. In a 120 nutshell, a template for the definition of the namespace is completed 121 for deposit with IANA, and a NID is assigned. The details of the 122 process and possibilities for NID strings are outlined below; first, a 123 template for the definition is provided. 125 3.0 URN Namespace Definition Template 127 Definition of a URN namespace is accomplished by completing the 128 following information template. Apart from providing a mechanism 129 for disclosing structure of the URN namespace, this information 130 is designed to be useful for 132 . entities seeking to have a URN assigned in a namespace 133 (if applicable) 134 . entities seeking to provide URN resolvers for a namespace 135 (if applicable) 137 This is particularly important for communities evaluating the 138 possibility of using a portion of an existing URN namespace rather 139 than creating their own. 141 Information in the template is as follows: 143 Namespace ID: 145 Assigned by IANA. In some contexts, a particular one 146 may be requested (see below). 148 Declared registrant of the namespace: 150 Name and e-mail address. 152 Declaration of structure: 154 This section should outline any structural features of 155 identifiers in this namespace. At the very least, this 156 description may be used to introduce terminology used in 157 other sections. This structure may also be used for 158 determining realistic caching/shortcuts approaches; suitable 159 caveats should be provided. 161 Answers might include, but are not limited to: 163 . the structure is opaque (no exposition) 164 . a regular expression for parsing the identifier into 165 components, including naming authorities 167 Identifier uniqueness considerations: 169 This section should address the requirement that 170 URN identifiers be assigned uniquely -- they are assigned 171 to at most one resource, and are not reassigned. 173 Possible answers include, but are not limited to: 175 . exposition of the structure of the identifiers, and 176 partitioning of the space of identifiers amongst 177 assignment authorities 178 . identifiers are assigned sequentially 179 . information is withheld; the namespace is opaque 181 Identifier persistence considerations: 183 Although non-reassignment of URN identifiers ensures 184 that a URN will persist in identifying a particular 185 resource even after the "lifetime of the resource", 186 some consideration should be given to the persistence 187 of the usability of the URN. This is particularly 188 important in the case of URN namespaces providing 189 global resolution. 191 Possible answers include, but are not limited to: 193 . quality of service considerations 195 Process of identifier assignment: 197 This section should detail the mechanisms and or authorities 198 for assigning URNs to resources. It should make clear whether 199 assignment is completely open, or if limited, how 200 to become an assigner of identifiers, and/or get one 201 assigned by existing assignment authorities. Answers 202 could include, but are not limited to: 204 . assignment is completely open, following a particular 205 algorithm 206 . assignment is delegated to authorities recognized by 207 a particular organization (e.g., the Digital Object 208 Identifier Foundation controls the DOI assignment space and 209 its delegation) 210 . assignment is completely closed (e.g., for a private 211 organization) 213 Process for identifier resolution: 215 If a namespace is intended to be accessible for global 216 resolution, it must be registerd in an RDS (Resolution 217 Discovery System, see [RFC2276]) such as NAPTR. Resolution 218 then proceeds according to standard URI resolution processes, 219 and the mechanisms of the RDS. What this section should 220 outline is the requirements for becoming a recognized resolver 221 of URNs in this namespace (and being so-listed in the RDS 222 registry). 224 Answers may include, but are not limited to: 226 . the namespace is not listed with an RDS; this is not 227 relevant 228 . resolution mirroring is completely open, with a mechanism 229 for updating an appropriate RDS 230 . resolution is controlled by entities to which assignment 231 has been delegated 233 Rules for Lexical Equivalence: 235 If there are particular algorithms for determining 236 equivalence between two URN strings in this namespace, 237 rules can be provided here. 239 Some examples include: 241 . mappings between different character set encodings 242 . equivalence between hyphenated and non-hyphenated 243 groupings in the identifier string 245 Conformance with URN Syntax: 247 This section should outline any special considerations 248 required for conforming with the URN syntax. This is 249 particularly applicable in the case of legacy naming 250 systems that are used in the context of URNs. 252 For example, if a namespace is used in contexts other 253 than URNs, it may have a more generous character set than is 254 immediately available with URNs. This section should flag this 255 issue and outline necessary mappings to conform to 256 URN syntax. (E.g., see the section on SICIs in [RFC2288]). 258 Validation mechanism: 260 Apart from attempting resolution of a URN, a URN namespace 261 may provide mechanism for "validating" a URN -- i.e., 262 determining whether a given string is currently a 263 validly-assigned URN. For example, even if an ISBN 264 URN namespace is created, it is not clear that 265 all ISBNs will translate directly into "assigned URNs". 267 A validation mechanims might be: 269 . a syntax grammar 270 . an on-line service 271 . an off-line service 273 Scope: 275 This section should outline the scope of the use of the 276 identifiers in this namespace. Apart from considerations 277 of private vs. public namespaces, this section is critical 278 in evaluating the applicability of a requested NID. For 279 example, a namespace claiming to deal in "social security 280 numbers" should have a global scope and address all 281 social security number structures (unlikely). On the 282 other hand, at a national level, it is reasonable to 283 posit a URN namespace for "this nation's social security 284 numbers". 286 4.0 URN Namespace Registration and NID Assignment 288 Different levels of disclosure are expected/defined for namespaces. 289 According to the level of open-forum discussion surrounding 290 the disclosure, a URN namespace may be assigned or may request a 291 particular identifier. 293 There are 3 categories of URN namespaces defined here, distinguished 294 by expected level of service and required procedures for registration. 296 I.. Experimental: These are not registered with IANA. They 297 take the form 299 x- 301 II. Informal: These are registered with IANA (see Section ??), and 302 are assigned a number sequence as an identifier. 304 III. Formal: These are processed through a full RFC review 305 process. The NID may be any valid NID string 306 that does not start with "x-" (see Type I above), and 307 doesn't clash with an existing, registered NID. 309 The two-letter country codes are reserved 310 for availability for national registrations. 312 5.0 Example 314 A generic "Internet" namespace has been posited throughout recent 315 discussions of URNs. This namespace might be defined as follows: 317 Namespace ID: 319 "INET" requested. 321 Declared registrant of the namespace: 323 T. Cat 324 leslie@thinkingcat.com 326 Declaration of structure: 328 The identifier structure is as follows: 330 FQDN: 332 where FQDN is a fully-qualified domain name, and the 333 assigned string is conformant to URN syntax requirements. 335 Identifier uniqueness considerations: 337 Uniqueness is guaranteed as long as the assigned 338 string is never reassigned for a given FQDN. 340 Identifier persistence considerations: 342 Persistence of identifiers is dependent upon suitable 343 delegation of resolution at the level of "FQDN"s. 345 Process of identifier assignment: 347 Assignment of these URNs delegated to individual domain 348 name holders (for FQDNs). The holder of the FQDN registration 349 is required to maintain an entry (or delegate it) in the 350 NAPTR RDS. Within each of these delegated name partitions, 351 the string may be assigned per local requirements. 353 e.g. urn:inet:thinkincat.com:001203 355 Process for identifier resolution: 357 Domain name holders are responsible for operating or 358 delegating resolution servers for the FQDN in which they 359 have assigned URNs. 361 Rules for Lexical Equivalence: 363 Nothing in particular. 365 Conformance with URN Syntax: 367 No special considerations. 369 Validation mechanism: 371 None specified. 373 Scope: 375 Global. 377 6.0 Security Considerations 379 This document largely focuses on providing mechanisms for the 380 declaration of public information. Nominally, these declarations 381 should be of relatively low security profile, however there is 382 always the danger of "spoofing" and providing mis-information. 383 Information in these declarations should be taken as advisory. 385 7.0 References 387 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 388 Resource Identifiers using the Domain Name System", RFC 2168, 389 June 1997. 391 [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN 392 Resolution", RFC 2169, June 1997. 394 [RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 395 Bibliographic Identifiers as Uniform Resource Names", RFC 2288, 396 February 1998. 398 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 400 [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements 401 for Uniform Resource Names", RFC1737, December 1994 403 [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 404 Name Resolution", RFC 2276, January 1998. 406 8.0 Authors' Addresses 408 Leslie L. Daigle 409 Bunyip Information Systems Inc 410 310 Ste. Catherine St. W 411 Suite 300 412 Montreal, Quebec, CANADA 413 H2X 2A1 414 voice: +1 514 875-8611 415 fax: +1 514 875-8134 416 email: leslie@bunyip.com 418 Dirk-Willem van Gulik 419 ISIS/STA/CEO - TP 270 420 Joint Research Centre Ispra 421 21020 Ispra (Va) 422 Italy. 423 voice: +39 332 78 9549 or 5044 424 fax: +39 332 78 9185 425 email: Dirk.vanGulik@jrc.it 427 Renato Iannella 428 DSTC Pty Ltd 429 Gehrmann Labs, The Uni of Queensland 430 AUSTRALIA, 4072 431 voice: +61 7 3365 4310 432 fax: +61 7 3365 4311 433 email: renato@dstc.edu.au 435 Patrik Faltstrom 436 Tele2/Swipnet 437 Borgarfjordsgatan 16 438 P.O. Box 62 439 S-164 94 Kista 440 SWEDEN 441 voice: +46-5626 4000 442 fax: +46-5626 4200 443 email: paf@swip.net