idnits 2.17.1 draft-ietf-urn-nid-req-06.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-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 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 655 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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 228 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 37 has weird spacing: '...rt from proof...' == Line 321 has weird spacing: '...n-forum discu...' == Line 395 has weird spacing: '... period for...' -- 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 557, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** 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) -- Unexpected draft version: The latest known version of draft-iesg-iana-considerations is -05, but you're referring to -06. ** 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Leslie L. Daigle 2 October 8, 1998 Bunyip Information Systems 3 draft-ietf-urn-nid-req-06.txt Dirk-Willem van Gulik 4 ISIS/CEO, JRC Ispra 5 Renato Iannella 6 DSTC Pty Ltd 7 Patrik Faltstrom 8 Tele2/Swipnet 10 URN Namespace Definition Mechanisms 12 Status of this Document 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 29 Coast), or ftp.isi.edu (US West Coast). 31 0.0 Abstract 33 The URN WG has defined a syntax for Uniform Resource Names 34 (URNs) [RFC2141], as well as some proposed mechanisms for their 35 resolution and use in Internet applications ([RFC2168, RFC2169]). 36 The whole rests on the concept of individual "namespaces" within the 37 URN structure. Apart from proof-of-concept namespaces, the use 38 of existing identifiers in URNs has been discussed ([RFC2288]), 39 and this document lays out general definitions of and 40 mechanisms for establishing URN "namespaces". 42 1.0 Introduction 44 Uniform Resource Names (URNs) are resource identifiers with the 45 specific requirements for enabling location independent 46 identification of a resource, as well as longevity of reference. 47 There are 2 assumptions that are key to this document: 49 Assumption #1: 51 Assignment of a URN is a managed process. 53 I.e., not all strings that conform to URN syntax are necessarily 54 valid URNs. A URN is assigned according to the rules of a 55 particular namespace (in terms of syntax, semantics, and process). 57 Assumption #2: 59 The space of URN namespaces is managed. 61 I.e., not all syntactically correct URN namespaces (per the URN 62 syntax definition) are valid URN namespaces. A URN namespace 63 must have a recognized definition in order to be valid. 65 The purpose of this document is to outline a mechanism and provide a 66 template for explicit namespace definition, along with the mechanism 67 for associating an identifier (called a "Namespace ID", or NID) which 68 is registered with the Internet Assigned Number Authority, IANA. 70 Note that this document restricts itself to the description of 71 processes for the creation of URN namespaces. If "resolution" of any 72 so-created URN identifiers is desired, a separate process of 73 registration in a global NID directory, such as that provided by the 74 NAPTR system [RFC2168], is necessary. See [NAPTR-REG] for information 75 on obtaining registration in the NAPTR global NID directory. 77 2.0 What is a URN Namespace? 79 For the purposes of URNs, a "namespace" is a collection of 80 uniquely-assigned identifiers. A URN namespace itself has an 81 identifier in order to 83 . ensure global uniqueness of URNs 84 . (where desired) provide a cue for the structure of the 85 identifier 87 For example, ISBNs and ISSNs are both collections of identifiers used 88 in the traditional publishing world; while there may some number (or 89 numbers) that is both a valid ISBN identifier and ISSN identifier, 90 using different designators for the two collections ensures that no 91 two URNs will be the same for different resources. 93 The development of an identifier structure, and thereby a collection 94 of identifiers, is a process that is inherently dependent on the 95 requirements of the community defining the identifier, how they will 96 be assigned, and the uses to which they will be put. All of these 97 issues are specific to the individual community seeking to define a 98 namespace (e.g., publishing community, association of booksellers, 99 protocol developers, etc); they are beyond the scope of the IETF 100 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 Registration Information: 135 This is information to identify the particular version of 136 registration information: 138 . registration version number: starting with 1, incrementing by 1 139 with each new version 140 . registration date: date submitted to the IANA, using 141 the format 142 YYYY-MM-DD 143 as outlined in [ISO8601]. 145 Declared registrant of the namespace: 147 Required: Name and e-mail address. 148 Recommended: Affiliation, address, etc. 150 Declaration of syntactic structure: 152 This section should outline any structural features of 153 identifiers in this namespace. At the very least, this 154 description may be used to introduce terminology used in 155 other sections. This structure may also be used for 156 determining realistic caching/shortcuts approaches; suitable 157 caveats should be provided. If there are any specific 158 character encoding rules (e.g., which character should 159 always be used for single-quotes), these should be listed 160 here. 162 Answers might include, but are not limited to: 164 . the structure is opaque (no exposition) 165 . a regular expression for parsing the identifier into 166 components, including naming authorities 168 Relevant ancillary documentation: 170 This section should list any RFCs, standards, or other published 171 documentation that defines or explains all or part of the 172 namespace structure. 174 Answers might include, but are not limited to: 176 . RFCs outlining syntax of the namespace 177 . Other of the defining community's (e.g., ISO) documents 178 outlining syntax of the identifiers in the namespace 179 . Explanatory material introducing the namespace 181 Identifier uniqueness considerations: 183 This section should address the requirement that 184 URN identifiers be assigned uniquely -- they are assigned 185 to at most one resource, and are not reassigned. 187 (Note that the definition of "resource" is fairly 188 broad; for example, information on "Today's Weather" might 189 be considered a single resource, although the content is 190 dynamic.) 192 Possible answers include, but are not limited to: 194 . exposition of the structure of the identifiers, and 195 partitioning of the space of identifiers amongst 196 assignment authorities which are individually responsible 197 for respecting uniqueness rules 198 . identifiers are assigned sequentially 199 . information is withheld; the namespace is opaque 201 Identifier persistence considerations: 203 Although non-reassignment of URN identifiers ensures 204 that a URN will persist in identifying a particular 205 resource even after the "lifetime of the resource", 206 some consideration should be given to the persistence 207 of the usability of the URN. This is particularly 208 important in the case of URN namespaces providing 209 global resolution. 211 Possible answers include, but are not limited to: 213 . quality of service considerations 215 Process of identifier assignment: 217 This section should detail the mechanisms and/or authorities 218 for assigning URNs to resources. It should make clear whether 219 assignment is completely open, or if limited, how 220 to become an assigner of identifiers, and/or get one 221 assigned by existing assignment authorities. Answers 222 could include, but are not limited to: 224 . assignment is completely open, following a particular 225 algorithm 226 . assignment is delegated to authorities recognized by 227 a particular organization (e.g., the Digital Object 228 Identifier Foundation controls the DOI assignment space and 229 its delegation) 230 . assignment is completely closed (e.g., for a private 231 organization) 233 Process for identifier resolution: 235 If a namespace is intended to be accessible for global 236 resolution, it must be registerd in an RDS (Resolution 237 Discovery System, see [RFC2276]) such as NAPTR. Resolution 238 then proceeds according to standard URI resolution processes, 239 and the mechanisms of the RDS. What this section should 240 outline is the requirements for becoming a recognized resolver 241 of URNs in this namespace (and being so-listed in the RDS 242 registry). 244 Answers may include, but are not limited to: 246 . the namespace is not listed with an RDS; this is not 247 relevant 248 . resolution mirroring is completely open, with a mechanism 249 for updating an appropriate RDS 250 . resolution is controlled by entities to which assignment 251 has been delegated 253 Rules for Lexical Equivalence: 255 If there are particular algorithms for determining 256 equivalence between two identifiers in the underlying 257 namespace (hence, in the URN string itself), rules can 258 be provided here. 260 Some examples include: 262 . equivalence between hyphenated and non-hyphenated 263 groupings in the identifier string 264 . equivalence between single-quotes and double-quotes 265 . Namespace-defined equivalences between specific 266 characters, such as "character X with or without 267 diacritic marks". 269 Note that these are not normative statements for any kind of 270 best practice for handling equivalences between characters; 271 they are statements limited to reflecting the namespace's 272 own rules. 274 Conformance with URN Syntax: 276 This section should outline any special considerations 277 required for conforming with the URN syntax. This is 278 particularly applicable in the case of legacy naming 279 systems that are used in the context of URNs. 281 For example, if a namespace is used in contexts other 282 than URNs, it may make use of characters that are reserved 283 in the URN syntax. This section should flag any such 284 characters, and outline necessary mappings to conform to 285 URN syntax. Normally, this will be handled by hex encoding 286 the symbol. 288 For example, see the section on SICIs in [RFC2288]. 290 Validation mechanism: 292 Apart from attempting resolution of a URN, a URN namespace 293 may provide mechanism for "validating" a URN -- i.e., 294 determining whether a given string is currently a 295 validly-assigned URN. For example, even if an ISBN 296 URN namespace is created, it is not clear that 297 all ISBNs will translate directly into "assigned URNs". 299 A validation mechanims might be: 301 . a syntax grammar 302 . an on-line service 303 . an off-line service 305 Scope: 307 This section should outline the scope of the use of the 308 identifiers in this namespace. Apart from considerations 309 of private vs. public namespaces, this section is critical 310 in evaluating the applicability of a requested NID. For 311 example, a namespace claiming to deal in "social security 312 numbers" should have a global scope and address all 313 social security number structures (unlikely). On the 314 other hand, at a national level, it is reasonable to 315 posit a URN namespace for "this nation's social security 316 numbers". 318 4.0 URN Namespace Registration, Update, and NID Assignment Process 320 Different levels of disclosure are expected/defined for namespaces. 321 According to the level of open-forum discussion surrounding 322 the disclosure, a URN namespace may be assigned or may request a 323 particular identifier. The [IANA-CONSIDERATIONS] document suggests 324 the need to specify update mechanisms for registrations -- who 325 is given the authority to do so, from time to time, and what are 326 the processes. Since URNs are meant to be persistently useful, few 327 (if any) changes should be made to the structural interpretation of 328 URN strings (e.g., adding or removing rules for lexical equivalence that 329 might affect the interpretation of URN IDs already assigned). However, it 330 may be important to introduce clarifications, expand the list of 331 authorized URN assigners, etc, over the natural course of a namespace's 332 lifetime. Specific processes are outlined below. 334 There are 3 categories of URN namespaces defined here, distinguished 335 by expected level of service and required procedures for registration. 336 Furthermore, registration maintenance procedures vary slightly from 337 one category to another. 339 I. Experimental: These are not explicitly registered with IANA. They 340 take the form 342 x- 344 No provision is made for avoiding collision of experimental 345 NIDs; they are intended for use within internal or limited 346 experimental contexts. 348 As there is no registration, no registration maintenance 349 procedures are needed. 351 II. Informal: These are registered with IANA and are assigned a 352 number sequence as an identifier, in the format: 354 "iana-" 356 where is chosen by the IANA on a First Come First 357 Served basis (see [IANA-CONSIDERATIONS]). 359 Registrants should send a copy of the registration 360 template (see section 3.0), duly completed, to the 362 urn-nid@apps.ietf.org 364 mailing and allow for a 2 week discussion period for 365 clarifying the expression of the registration information 366 and suggestions for improvements to the namespace proposal. 368 After suggestions for clarification of the registration 369 information have been incorporated, the template may be 370 submitted to: 372 iana@iana.org 374 for assignment of a NID. 376 The only restrictions on are that it consist 377 strictly of digits and that it not cause the NID to exceed 378 length limitations outlined in the URN syntax ([RFC2168]). 380 Registrations may be updated by the original registrant, 381 or an entity designated by the registrant, by updating 382 the registration template, submitting it to the discussion 383 list for a further 2 week discussion period, and finally 384 resubmitting it to IANA, as described above. 386 III. Formal: These are processed through an RFC review 387 process. The RFC need not be standards-track. The 388 template defined in section 3.0 may be included as part 389 of an RFC defining some other aspect of the namespace, 390 or it may be put forward as an RFC in its own right. 391 The proposed template should be sent to the 393 urn-nid@apps.ietf.org 395 mailing list to allow for a 2 week discussion period for 396 clarifying the expression of the registration information, 397 before the IESG progresses the document to RFC status. 399 A particular NID string is requested, and is assigned by IETF 400 consensus (as defined in [IANA-CONSIDERATIONS]), with 401 the additional constraints that the NID string must 402 not start with "x-" (see Type I above) or "iana-" (see Type II 403 above), is not already a registered NID, and is more 404 than 2 letters long. 406 ALL two-letter combinations are reserved for use 407 as country code NIDs for eventual national registrations of 408 URN namespaces. 410 Registrations may be updated by updating the RFC through 411 standard IETF RFC update mechanisms. Thus, proposals for 412 updates may be made by the original authors, other IETF 413 participants, or the IESG. In any case, the proposed 414 updated template must be circulated on the urn-nid 415 discussion list, allowing for a 2 week review period. 417 URN namespace registrations will be posted in the anonymous FTP directory 418 "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/". 420 5.0 Example 422 The following example is provided for the purposes of illustration of 423 the URN NID template described in section 3.0. Although it is based on 424 a posited "generic Internet namespace" that has been discussed informally 425 within the URN WG, there are still technical and infrastructural issues 426 that would have to be resolved before such a namespace could be properly 427 and completely described. 429 Namespace ID: 431 To be assigned 433 Registration Information: 435 Version 1 436 Date: 438 Declared registrant of the namespace: 440 Required: Name and e-mail address. 441 Recommended: Affiliation, address, etc. 443 Declared registrant of the namespace: 445 Name: T. Cat 446 E-mail: leslie@thinkingcat.com 447 Affiliation: Thinking Cat Enterprises 448 Address: 1 ThinkingCat Way 449 Trupville, NewCountry 451 Declaration of structure: 453 The identifier structure is as follows: 455 URN::: 457 where FQDN is a fully-qualified domain name, and the 458 assigned string is conformant to URN syntax requirements. 460 Relevant ancillary documentation: 462 Definition of domain names, found in: 464 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 465 RFC1035, November 1987. 467 Identifier uniqueness considerations: 469 Uniqueness is guaranteed as long as the assigned 470 string is never reassigned for a given FQDN, and that the FQDN 471 is never reassigned. 473 N.B.: operationally, there is nothing that prevents a domain 474 name from being reassigned; indeed, it is not an uncommon 475 occurrence. This is one of the reasons that this example 476 makes a poor URN namespace in practice, and is therefore not 477 seriously being proposed as it stands. 479 Identifier persistence considerations: 481 Persistence of identifiers is dependent upon suitable 482 delegation of resolution at the level of "FQDN"s, and persistence 483 of FQDN assignment. 485 Same note as above. 487 Process of identifier assignment: 489 Assignment of these URNs delegated to individual domain 490 name holders (for FQDNs). The holder of the FQDN registration 491 is required to maintain an entry (or delegate it) in the 492 NAPTR RDS. Within each of these delegated name partitions, 493 the string may be assigned per local requirements. 495 e.g. urn::thinkingcat.com:001203 497 Process for identifier resolution: 499 Domain name holders are responsible for operating or 500 delegating resolution servers for the FQDN in which they 501 have assigned URNs. 503 Rules for Lexical Equivalence: 505 FQDNs are case-insensitive. Thus, the portion of the URN 507 urn::: 509 is case-insenstive for matches. The remainder of the identifier 510 must be considered case-sensitve. 512 Conformance with URN Syntax: 514 No special considerations. 516 Validation mechanism: 518 None specified. 520 Scope: 522 Global. 524 6.0 Security Considerations 526 This document largely focuses on providing mechanisms for the 527 declaration of public information. Nominally, these declarations 528 should be of relatively low security profile, however there is 529 always the danger of "spoofing" and providing mis-information. 530 Information in these declarations should be taken as advisory. 532 7.0 References 534 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 535 Resource Identifiers using the Domain Name System", RFC 2168, 536 June 1997. 538 [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN 539 Resolution", RFC 2169, June 1997. 541 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - 542 Information interchange - Representation of dates and times" 544 [RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 545 Bibliographic Identifiers as Uniform Resource Names", RFC 2288, 546 February 1998. 548 [NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution 549 using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt. 551 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 553 [IANA-CONSIDERATIONS] T. Narten and H. Alvestrand, "Guidelines for 554 Writing an IANA Considerations Section in RFCs", 555 draft-iesg-iana-considerations-06.txt. 557 [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements 558 for Uniform Resource Names", RFC1737, December 1994 560 [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 561 Name Resolution", RFC 2276, January 1998. 563 8.0 Authors' Addresses 565 Leslie L. Daigle 566 Bunyip Information Systems Inc 567 310 Ste. Catherine St. W 568 Suite 300 569 Montreal, Quebec, CANADA 570 H2X 2A1 571 voice: +1 514 875-8611 572 fax: +1 514 875-8134 573 email: leslie@bunyip.com 575 Dirk-Willem van Gulik 576 ISIS/STA/CEO - TP 270 577 Joint Research Centre Ispra 578 21020 Ispra (Va) 579 Italy. 580 voice: +39 332 78 9549 or 5044 581 fax: +39 332 78 9185 582 email: Dirk.vanGulik@jrc.it 584 Renato Iannella 585 DSTC Pty Ltd 586 Gehrmann Labs, The Uni of Queensland 587 AUSTRALIA, 4072 588 voice: +61 7 3365 4310 589 fax: +61 7 3365 4311 590 email: renato@dstc.edu.au 592 Patrik Faltstrom 593 Tele2/Swipnet 594 Borgarfjordsgatan 16 595 P.O. Box 62 596 S-164 94 Kista 597 SWEDEN 598 voice: +46-5626 4000 599 fax: +46-5626 4200 600 email: paf@swip.net