idnits 2.17.1 draft-ietf-urn-nid-req-05.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-26) 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 569 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 190 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 287 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 480, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-iesg-iana-considerations-04 ** 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 == Outdated reference: A later version (-11) exists of draft-ietf-urn-net-procedures-00 ** 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: 17 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Leslie L. Daigle 3 August 4, 1998 Bunyip Information Systems 4 draft-ietf-urn-nid-req-05.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 1.0 Introduction 45 Uniform Resource Names (URNs) are resource identifiers with the 46 specific requirements for enabling location independent 47 identification of a resource, as well as longevity of reference. 48 There are 2 assumptions that are key to this document: 50 Assumption #1: 52 Assignment of a URN is a managed process. 54 I.e., not all strings that conform to URN syntax are necessarily 55 valid URNs. A URN is assigned according to the rules of a 56 particular namespace (in terms of syntax, semantics, and process). 58 Assumption #2: 60 The space of URN namespaces is managed. 62 I.e., not all syntactically correct URN namespaces (per the URN 63 syntax definition) are valid URN namespaces. A URN namespace 64 must have a recognized definition in order to be valid. 66 The purpose of this document is to outline a mechanism and provide a 67 template for explicit namespace definition, along with the mechanism 68 for associating an identifier (called a "Namespace ID", or NID) which 69 is registered with the Internet Assigned Number Authority, IANA. 71 Note that this document restricts itself to the description of 72 processes for the creation of URN namespaces. If "resolution" of any 73 so-created URN identifiers is desired, a separate process of 74 registration in a global NID directory, such as that provided by the 75 NAPTR system [RFC2168], is necessary. See [NAPTR-REG] for information 76 on obtaining registration in the NAPTR global NID directory. 78 2.0 What is a URN Namespace? 80 For the purposes of URNs, a "namespace" is a collection of 81 uniquely-assigned identifiers. A URN namespace itself has an 82 identifier in order to 84 . ensure global uniqueness of URNs 85 . (where desired) provide a cue for the structure of the 86 identifier 88 For example, ISBNs and ISSNs are both collections of identifiers used 89 in the traditional publishing world; while there may some number (or 90 numbers) that is both a valid ISBN identifier and ISSN identifier, 91 using different designators for the two collections ensures that no 92 two URNs will be the same for different resources. 94 The development of an identifier structure, and thereby a collection 95 of identifiers, is a process that is inherently dependent on the needs 96 of the identifiers, how they will be assigned, and the uses to which 97 they will be put. All of these issues are specific to the individual 98 community seeking to define a namespace (e.g., publishing community, 99 association of booksellers, protocol developers, etc); they are beyond 100 the scope of the IETF URN work. 102 This document outlines the processes by which a collection of 103 identifiers satisfying certain constraints (uniqueness of assignment, 104 etc) can become a bona fide URN namespace by obtaining a NID. In a 105 nutshell, a template for the definition of the namespace is completed 106 for deposit with IANA, and a NID is assigned. The details of the 107 process and possibilities for NID strings are outlined below; first, a 108 template for the definition is provided. 110 3.0 URN Namespace Definition Template 112 Definition of a URN namespace is accomplished by completing the 113 following information template. Apart from providing a mechanism 114 for disclosing structure of the URN namespace, this information 115 is designed to be useful for 117 . entities seeking to have a URN assigned in a namespace 118 (if applicable) 119 . entities seeking to provide URN resolvers for a namespace 120 (if applicable) 122 This is particularly important for communities evaluating the 123 possibility of using a portion of an existing URN namespace rather 124 than creating their own. 126 Information in the template is as follows: 128 Namespace ID: 130 Assigned by IANA. In some contexts, a particular one 131 may be requested (see below). 133 Declared registrant of the namespace: 135 Name and e-mail address. 137 Declaration of structure: 139 This section should outline any structural features of 140 identifiers in this namespace. At the very least, this 141 description may be used to introduce terminology used in 142 other sections. This structure may also be used for 143 determining realistic caching/shortcuts approaches; suitable 144 caveats should be provided. 146 Answers might include, but are not limited to: 148 . the structure is opaque (no exposition) 149 . a regular expression for parsing the identifier into 150 components, including naming authorities 152 Relevant ancillary documentation: 154 This section should list any RFCs, standards, or other published 155 documentation that defines or explains all or part of the 156 namespace structure. 158 Answers might include, but are not limited to: 160 . RFCs outlining syntax of the namespace 161 . Other community's (e.g., ISO) documents outlining syntax 162 of the identifiers in the namespace 163 . Explanatory material introducing the namespace 165 Identifier uniqueness considerations: 167 This section should address the requirement that 168 URN identifiers be assigned uniquely -- they are assigned 169 to at most one resource, and are not reassigned. 171 Possible answers include, but are not limited to: 173 . exposition of the structure of the identifiers, and 174 partitioning of the space of identifiers amongst 175 assignment authorities 176 . identifiers are assigned sequentially 177 . information is withheld; the namespace is opaque 179 Identifier persistence considerations: 181 Although non-reassignment of URN identifiers ensures 182 that a URN will persist in identifying a particular 183 resource even after the "lifetime of the resource", 184 some consideration should be given to the persistence 185 of the usability of the URN. This is particularly 186 important in the case of URN namespaces providing 187 global resolution. 189 Possible answers include, but are not limited to: 191 . quality of service considerations 193 Process of identifier assignment: 195 This section should detail the mechanisms and/or authorities 196 for assigning URNs to resources. It should make clear whether 197 assignment is completely open, or if limited, how 198 to become an assigner of identifiers, and/or get one 199 assigned by existing assignment authorities. Answers 200 could include, but are not limited to: 202 . assignment is completely open, following a particular 203 algorithm 204 . assignment is delegated to authorities recognized by 205 a particular organization (e.g., the Digital Object 206 Identifier Foundation controls the DOI assignment space and 207 its delegation) 208 . assignment is completely closed (e.g., for a private 209 organization) 211 Process for identifier resolution: 213 If a namespace is intended to be accessible for global 214 resolution, it must be registerd in an RDS (Resolution 215 Discovery System, see [RFC2276]) such as NAPTR. Resolution 216 then proceeds according to standard URI resolution processes, 217 and the mechanisms of the RDS. What this section should 218 outline is the requirements for becoming a recognized resolver 219 of URNs in this namespace (and being so-listed in the RDS 220 registry). 222 Answers may include, but are not limited to: 224 . the namespace is not listed with an RDS; this is not 225 relevant 226 . resolution mirroring is completely open, with a mechanism 227 for updating an appropriate RDS 228 . resolution is controlled by entities to which assignment 229 has been delegated 231 Rules for Lexical Equivalence: 233 If there are particular algorithms for determining 234 equivalence between two URN strings in this namespace, 235 rules can be provided here. 237 Some examples include: 239 . mappings between different character set encodings 240 . equivalence between hyphenated and non-hyphenated 241 groupings in the identifier string 243 Conformance with URN Syntax: 245 This section should outline any special considerations 246 required for conforming with the URN syntax. This is 247 particularly applicable in the case of legacy naming 248 systems that are used in the context of URNs. 250 For example, if a namespace is used in contexts other 251 than URNs, it may have a more generous character set than is 252 immediately available with URNs. This section should flag this 253 issue and outline necessary mappings to conform to 254 URN syntax. (E.g., see the section on SICIs in [RFC2288]). 256 Validation mechanism: 258 Apart from attempting resolution of a URN, a URN namespace 259 may provide mechanism for "validating" a URN -- i.e., 260 determining whether a given string is currently a 261 validly-assigned URN. For example, even if an ISBN 262 URN namespace is created, it is not clear that 263 all ISBNs will translate directly into "assigned URNs". 265 A validation mechanims might be: 267 . a syntax grammar 268 . an on-line service 269 . an off-line service 271 Scope: 273 This section should outline the scope of the use of the 274 identifiers in this namespace. Apart from considerations 275 of private vs. public namespaces, this section is critical 276 in evaluating the applicability of a requested NID. For 277 example, a namespace claiming to deal in "social security 278 numbers" should have a global scope and address all 279 social security number structures (unlikely). On the 280 other hand, at a national level, it is reasonable to 281 posit a URN namespace for "this nation's social security 282 numbers". 284 4.0 URN Namespace Registration and NID Assignment Process 286 Different levels of disclosure are expected/defined for namespaces. 287 According to the level of open-forum discussion surrounding 288 the disclosure, a URN namespace may be assigned or may request a 289 particular identifier. 291 There are 3 categories of URN namespaces defined here, distinguished 292 by expected level of service and required procedures for registration. 294 I. Experimental: These are not explicitly registered with IANA. They 295 take the form 297 x- 299 No provision is made for avoiding collision of experimental 300 NIDs; they are intended for use within internal or limited 301 experimental contexts. 303 II. Informal: These are registered with IANA and are assigned a 304 number sequence as an identifier, in the format: 306 "iana-" 308 where is chosen by the IANA on a First Come First 309 Served basis (see [IANA-CONSIDERATIONS]). 311 Registrants should send a copy of the registration 312 template (see section 3.0), duly completed, to the 314 urn-nid@apps.ietf.org 316 mailing and allow for a 2 week discussion period for 317 clarifying the expression of the registration information 318 and suggestions for improvements to the namespace proposal. 320 After suggestions for clarification of the registration 321 information have been incorporated, the template may be 322 submitted to: 324 iana@iana.org 326 for assignment of a NID. 328 The only restrictions on are that it consist 329 strictly of digits and that it not cause the NID to exceed 330 length limitations outlined in the URN syntax ([RFC2168]). 332 III. Formal: These are processed through an RFC review 333 process. The RFC need not be standards-track. The template 334 defined in section 3.0 may be 335 included as part of the RFC, or a separate message 336 referencing the RFC. The proposed template should 337 be sent to the 339 urn-nid@apps.ietf.org 341 mailing list to allow for a 2 week discussion period. 343 The registration template should then be sent to 345 iana@iana.org 347 A particular NID string is requested, and is assigned by IETF 348 consensus (as defined in [IANA-CONSIDERATIONS]), with 349 the additional constraints that the NID string must 350 not start with "x-" (see Type I above) or "iana-" (see Type II 351 above), and is not already a registered NID. 353 The two-letter country codes are reserved 354 for availability for national registrations. 356 URN namespace registrations will be posted in the anonymous FTP directory 357 "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/". 359 5.0 Example 361 The following example is provided for the purposes of illustration of 362 the URN NID template described in section 3.0. Although it is based on 363 a posited "generic Internet namespace" that has been discussed informally 364 within the URN WG, there are still technical and infrastructural issues 365 that would have to be resolved before such a namespace could be properly 366 and completely described. 368 Namespace ID: 370 To be assigned 372 Declared registrant of the namespace: 374 T. Cat 375 leslie@thinkingcat.com 377 Declaration of structure: 379 The identifier structure is as follows: 381 URN::: 383 where FQDN is a fully-qualified domain name, and the 384 assigned string is conformant to URN syntax requirements. 386 Relevant ancillary documentation: 388 Definition of domain names, found in: 390 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 391 RFC1035, November 1987. 393 Identifier uniqueness considerations: 395 Uniqueness is guaranteed as long as the assigned 396 string is never reassigned for a given FQDN, and that the FQDN 397 is never reassigned. 399 N.B.: operationally, there is nothing that prevents a domain 400 name from being reassigned; indeed, it is not an uncommon 401 occurrence. This is one of the reasons that this example 402 makes a poor URN namespace in practice, and is therefore not 403 seriously being proposed as it stands. 405 Identifier persistence considerations: 407 Persistence of identifiers is dependent upon suitable 408 delegation of resolution at the level of "FQDN"s, and persistence 409 of FQDN assignment. 411 Same note as above. 413 Process of identifier assignment: 415 Assignment of these URNs delegated to individual domain 416 name holders (for FQDNs). The holder of the FQDN registration 417 is required to maintain an entry (or delegate it) in the 418 NAPTR RDS. Within each of these delegated name partitions, 419 the string may be assigned per local requirements. 421 e.g. urn::thinkingcat.com:001203 423 Process for identifier resolution: 425 Domain name holders are responsible for operating or 426 delegating resolution servers for the FQDN in which they 427 have assigned URNs. 429 Rules for Lexical Equivalence: 431 FQDNs are case-insensitive. Thus, the portion of the URN 433 urn::: 435 is case-insenstive for matches. The remainder of the identifier 436 must be considered case-sensitve. 438 Conformance with URN Syntax: 440 No special considerations. 442 Validation mechanism: 444 None specified. 446 Scope: 448 Global. 450 6.0 Security Considerations 452 This document largely focuses on providing mechanisms for the 453 declaration of public information. Nominally, these declarations 454 should be of relatively low security profile, however there is 455 always the danger of "spoofing" and providing mis-information. 456 Information in these declarations should be taken as advisory. 458 7.0 References 460 [IANA-CONSIDERATIONS] H. Alvestrand and T. Narten, "Guidelines for 461 Writing an IANA Considerations Section in RFCs", 462 draft-iesg-iana-considerations-04.txt. 464 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 465 Resource Identifiers using the Domain Name System", RFC 2168, 466 June 1997. 468 [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN 469 Resolution", RFC 2169, June 1997. 471 [RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 472 Bibliographic Identifiers as Uniform Resource Names", RFC 2288, 473 February 1998. 475 [NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution 476 using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt. 478 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 480 [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements 481 for Uniform Resource Names", RFC1737, December 1994 483 [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 484 Name Resolution", RFC 2276, January 1998. 486 8.0 Authors' Addresses 488 Leslie L. Daigle 489 Bunyip Information Systems Inc 490 310 Ste. Catherine St. W 491 Suite 300 492 Montreal, Quebec, CANADA 493 H2X 2A1 494 voice: +1 514 875-8611 495 fax: +1 514 875-8134 496 email: leslie@bunyip.com 498 Dirk-Willem van Gulik 499 ISIS/STA/CEO - TP 270 500 Joint Research Centre Ispra 501 21020 Ispra (Va) 502 Italy. 503 voice: +39 332 78 9549 or 5044 504 fax: +39 332 78 9185 505 email: Dirk.vanGulik@jrc.it 507 Renato Iannella 508 DSTC Pty Ltd 509 Gehrmann Labs, The Uni of Queensland 510 AUSTRALIA, 4072 511 voice: +61 7 3365 4310 512 fax: +61 7 3365 4311 513 email: renato@dstc.edu.au 515 Patrik Faltstrom 516 Tele2/Swipnet 517 Borgarfjordsgatan 16 518 P.O. Box 62 519 S-164 94 Kista 520 SWEDEN 521 voice: +46-5626 4000 522 fax: +46-5626 4200 523 email: paf@swip.net