idnits 2.17.1 draft-ietf-urn-nid-req-07.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-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 663 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 6 characters in excess of 72. ** There are 234 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 322 has weird spacing: '...n-forum discu...' == Line 396 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 565, 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. -------------------------------------------------------------------------------- 2 Internet Draft Leslie L. Daigle 3 October 20, 1998 Bunyip Information Systems 4 draft-ietf-urn-nid-req-07.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), ftp.ietf.org (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 be 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 96 requirements of the community defining the identifier, how they will 97 be assigned, and the uses to which they will be put. All of these 98 issues are specific to the individual community seeking to define a 99 namespace (e.g., publishing community, association of booksellers, 100 protocol developers, etc); they are beyond the scope of the IETF 101 URN work. 103 This document outlines the processes by which a collection of 104 identifiers satisfying certain constraints (uniqueness of assignment, 105 etc) can become a bona fide URN namespace by obtaining a NID. In a 106 nutshell, a template for the definition of the namespace is completed 107 for deposit with IANA, and a NID is assigned. The details of the 108 process and possibilities for NID strings are outlined below; first, a 109 template for the definition is provided. 111 3.0 URN Namespace Definition Template 113 Definition of a URN namespace is accomplished by completing the 114 following information template. Apart from providing a mechanism 115 for disclosing structure of the URN namespace, this information 116 is designed to be useful for 118 . entities seeking to have a URN assigned in a namespace 119 (if applicable) 120 . entities seeking to provide URN resolvers for a namespace 121 (if applicable) 123 This is particularly important for communities evaluating the 124 possibility of using a portion of an existing URN namespace rather 125 than creating their own. 127 Information in the template is as follows: 129 Namespace ID: 131 Assigned by IANA. In some contexts, a particular one 132 may be requested (see below). 134 Registration Information: 136 This is information to identify the particular version of 137 registration information: 139 . registration version number: starting with 1, incrementing by 1 140 with each new version 141 . registration date: date submitted to the IANA, using 142 the format 143 YYYY-MM-DD 144 as outlined in [ISO8601]. 146 Declared registrant of the namespace: 148 Required: Name and e-mail address. 149 Recommended: Affiliation, address, etc. 151 Declaration of syntactic structure: 153 This section should outline any structural features of 154 identifiers in this namespace. At the very least, this 155 description may be used to introduce terminology used in 156 other sections. This structure may also be used for 157 determining realistic caching/shortcuts approaches; suitable 158 caveats should be provided. If there are any specific 159 character encoding rules (e.g., which character should 160 always be used for single-quotes), these should be listed 161 here. 163 Answers might include, but are not limited to: 165 . the structure is opaque (no exposition) 166 . a regular expression for parsing the identifier into 167 components, including naming authorities 169 Relevant ancillary documentation: 171 This section should list any RFCs, standards, or other published 172 documentation that defines or explains all or part of the 173 namespace structure. 175 Answers might include, but are not limited to: 177 . RFCs outlining syntax of the namespace 178 . Other of the defining community's (e.g., ISO) documents 179 outlining syntax of the identifiers in the namespace 180 . Explanatory material introducing the namespace 182 Identifier uniqueness considerations: 184 This section should address the requirement that 185 URN identifiers be assigned uniquely -- they are assigned 186 to at most one resource, and are not reassigned. 188 (Note that the definition of "resource" is fairly 189 broad; for example, information on "Today's Weather" might 190 be considered a single resource, although the content is 191 dynamic.) 193 Possible answers include, but are not limited to: 195 . exposition of the structure of the identifiers, and 196 partitioning of the space of identifiers amongst 197 assignment authorities which are individually responsible 198 for respecting uniqueness rules 199 . identifiers are assigned sequentially 200 . information is withheld; the namespace is opaque 202 Identifier persistence considerations: 204 Although non-reassignment of URN identifiers ensures 205 that a URN will persist in identifying a particular 206 resource even after the "lifetime of the resource", 207 some consideration should be given to the persistence 208 of the usability of the URN. This is particularly 209 important in the case of URN namespaces providing 210 global resolution. 212 Possible answers include, but are not limited to: 214 . quality of service considerations 216 Process of identifier assignment: 218 This section should detail the mechanisms and/or authorities 219 for assigning URNs to resources. It should make clear whether 220 assignment is completely open, or if limited, how 221 to become an assigner of identifiers, and/or get one 222 assigned by existing assignment authorities. Answers 223 could include, but are not limited to: 225 . assignment is completely open, following a particular 226 algorithm 227 . assignment is delegated to authorities recognized by 228 a particular organization (e.g., the Digital Object 229 Identifier Foundation controls the DOI assignment space and 230 its delegation) 231 . assignment is completely closed (e.g., for a private 232 organization) 234 Process for identifier resolution: 236 If a namespace is intended to be accessible for global 237 resolution, it must be registerd in an RDS (Resolution 238 Discovery System, see [RFC2276]) such as NAPTR. Resolution 239 then proceeds according to standard URI resolution processes, 240 and the mechanisms of the RDS. What this section should 241 outline is the requirements for becoming a recognized resolver 242 of URNs in this namespace (and being so-listed in the RDS 243 registry). 245 Answers may include, but are not limited to: 247 . the namespace is not listed with an RDS; this is not 248 relevant 249 . resolution mirroring is completely open, with a mechanism 250 for updating an appropriate RDS 251 . resolution is controlled by entities to which assignment 252 has been delegated 254 Rules for Lexical Equivalence: 256 If there are particular algorithms for determining 257 equivalence between two identifiers in the underlying 258 namespace (hence, in the URN string itself), rules can 259 be provided here. 261 Some examples include: 263 . equivalence between hyphenated and non-hyphenated 264 groupings in the identifier string 265 . equivalence between single-quotes and double-quotes 266 . Namespace-defined equivalences between specific 267 characters, such as "character X with or without 268 diacritic marks". 270 Note that these are not normative statements for any kind of 271 best practice for handling equivalences between characters; 272 they are statements limited to reflecting the namespace's 273 own rules. 275 Conformance with URN Syntax: 277 This section should outline any special considerations 278 required for conforming with the URN syntax. This is 279 particularly applicable in the case of legacy naming 280 systems that are used in the context of URNs. 282 For example, if a namespace is used in contexts other 283 than URNs, it may make use of characters that are reserved 284 in the URN syntax. This section should flag any such 285 characters, and outline necessary mappings to conform to 286 URN syntax. Normally, this will be handled by hex encoding 287 the symbol. 289 For example, see the section on SICIs in [RFC2288]. 291 Validation mechanism: 293 Apart from attempting resolution of a URN, a URN namespace 294 may provide mechanism for "validating" a URN -- i.e., 295 determining whether a given string is currently a 296 validly-assigned URN. For example, even if an ISBN 297 URN namespace is created, it is not clear that 298 all ISBNs will translate directly into "assigned URNs". 300 A validation mechanims might be: 302 . a syntax grammar 303 . an on-line service 304 . an off-line service 306 Scope: 308 This section should outline the scope of the use of the 309 identifiers in this namespace. Apart from considerations 310 of private vs. public namespaces, this section is critical 311 in evaluating the applicability of a requested NID. For 312 example, a namespace claiming to deal in "social security 313 numbers" should have a global scope and address all 314 social security number structures (unlikely). On the 315 other hand, at a national level, it is reasonable to 316 propose a URN namespace for "this nation's social security 317 numbers". 319 4.0 URN Namespace Registration, Update, and NID Assignment Process 321 Different levels of disclosure are expected/defined for namespaces. 322 According to the level of open-forum discussion surrounding 323 the disclosure, a URN namespace may be assigned or may request a 324 particular identifier. The [IANA-CONSIDERATIONS] document suggests 325 the need to specify update mechanisms for registrations -- who 326 is given the authority to do so, from time to time, and what are 327 the processes. Since URNs are meant to be persistently useful, few 328 (if any) changes should be made to the structural interpretation of 329 URN strings (e.g., adding or removing rules for lexical equivalence that 330 might affect the interpretation of URN IDs already assigned). However, it 331 may be important to introduce clarifications, expand the list of 332 authorized URN assigners, etc, over the natural course of a namespace's 333 lifetime. Specific processes are outlined below. 335 There are 3 categories of URN namespaces defined here, distinguished 336 by expected level of service and required procedures for registration. 337 Furthermore, registration maintenance procedures vary slightly from 338 one category to another. 340 I. Experimental: These are not explicitly registered with IANA. They 341 take the form 343 x- 345 No provision is made for avoiding collision of experimental 346 NIDs; they are intended for use within internal or limited 347 experimental contexts. 349 As there is no registration, no registration maintenance 350 procedures are needed. 352 II. Informal: These are registered with IANA and are assigned a 353 number sequence as an identifier, in the format: 355 "iana-" 357 where is chosen by the IANA on a First Come First 358 Served basis (see [IANA-CONSIDERATIONS]). 360 Registrants should send a copy of the registration 361 template (see section 3.0), duly completed, to the 363 urn-nid@apps.ietf.org 365 mailing and allow for a 2 week discussion period for 366 clarifying the expression of the registration information 367 and suggestions for improvements to the namespace proposal. 369 After suggestions for clarification of the registration 370 information have been incorporated, the template may be 371 submitted to: 373 iana@iana.org 375 for assignment of a NID. 377 The only restrictions on are that it consist 378 strictly of digits and that it not cause the NID to exceed 379 length limitations outlined in the URN syntax ([RFC2168]). 381 Registrations may be updated by the original registrant, 382 or an entity designated by the registrant, by updating 383 the registration template, submitting it to the discussion 384 list for a further 2 week discussion period, and finally 385 resubmitting it to IANA, as described above. 387 III. Formal: These are processed through an RFC review 388 process. The RFC need not be standards-track. The 389 template defined in section 3.0 may be included as part 390 of an RFC defining some other aspect of the namespace, 391 or it may be put forward as an RFC in its own right. 392 The proposed template should be sent to the 394 urn-nid@apps.ietf.org 396 mailing list to allow for a 2 week discussion period for 397 clarifying the expression of the registration information, 398 before the IESG progresses the document to RFC status. 400 A particular NID string is requested, and is assigned by IETF 401 consensus (as defined in [IANA-CONSIDERATIONS]), with 402 the additional constraints that the NID string must 404 . not be an already-registered NID 405 . not start with "x-" (see Type I above) 406 . not start with "iana-" (see Type II above) 407 . not start with "XY-", where XY is any 408 combination of 2 ASCII letters (see NOTE, below) 409 . be more than 2 letters long 411 NOTE: ALL two-letter combinations, and two-letter combinations 412 followed by "-" and any sequence of valid NID characters, are 413 reserved for potential use as countrycode-based NIDs for 414 eventual national registrations of URN namespaces. The 415 definition and scoping of rules for allocation of responsibility 416 for such namespaces is beyond the scope of this document. 418 Registrations may be updated by updating the RFC through 419 standard IETF RFC update mechanisms. Thus, proposals for 420 updates may be made by the original authors, other IETF 421 participants, or the IESG. In any case, the proposed 422 updated template must be circulated on the urn-nid 423 discussion list, allowing for a 2 week review period. 425 URN namespace registrations will be posted in the anonymous FTP directory 426 "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/". 428 5.0 Example 430 The following example is provided for the purposes of illustration of 431 the URN NID template described in section 3.0. Although it is based on 432 a hypothetical "generic Internet namespace" that has been discussed informally 433 within the URN WG, there are still technical and infrastructural issues 434 that would have to be resolved before such a namespace could be properly 435 and completely described. 437 Namespace ID: 439 To be assigned 441 Registration Information: 443 Version 1 444 Date: 446 Declared registrant of the namespace: 448 Required: Name and e-mail address. 449 Recommended: Affiliation, address, etc. 451 Declared registrant of the namespace: 453 Name: T. Cat 454 E-mail: leslie@thinkingcat.com 455 Affiliation: Thinking Cat Enterprises 456 Address: 1 ThinkingCat Way 457 Trupville, NewCountry 459 Declaration of structure: 461 The identifier structure is as follows: 463 URN::: 465 where FQDN is a fully-qualified domain name, and the 466 assigned string is conformant to URN syntax requirements. 468 Relevant ancillary documentation: 470 Definition of domain names, found in: 472 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 473 RFC1035, November 1987. 475 Identifier uniqueness considerations: 477 Uniqueness is guaranteed as long as the assigned 478 string is never reassigned for a given FQDN, and that the FQDN 479 is never reassigned. 481 N.B.: operationally, there is nothing that prevents a domain 482 name from being reassigned; indeed, it is not an uncommon 483 occurrence. This is one of the reasons that this example 484 makes a poor URN namespace in practice, and is therefore not 485 seriously being proposed as it stands. 487 Identifier persistence considerations: 489 Persistence of identifiers is dependent upon suitable 490 delegation of resolution at the level of "FQDN"s, and persistence 491 of FQDN assignment. 493 Same note as above. 495 Process of identifier assignment: 497 Assignment of these URNs delegated to individual domain 498 name holders (for FQDNs). The holder of the FQDN registration 499 is required to maintain an entry (or delegate it) in the 500 NAPTR RDS. Within each of these delegated name partitions, 501 the string may be assigned per local requirements. 503 e.g. urn::thinkingcat.com:001203 505 Process for identifier resolution: 507 Domain name holders are responsible for operating or 508 delegating resolution servers for the FQDN in which they 509 have assigned URNs. 511 Rules for Lexical Equivalence: 513 FQDNs are case-insensitive. Thus, the portion of the URN 515 urn::: 517 is case-insenstive for matches. The remainder of the identifier 518 must be considered case-sensitve. 520 Conformance with URN Syntax: 522 No special considerations. 524 Validation mechanism: 526 None specified. 528 Scope: 530 Global. 532 6.0 Security Considerations 534 This document largely focuses on providing mechanisms for the 535 declaration of public information. Nominally, these declarations 536 should be of relatively low security profile, however there is 537 always the danger of "spoofing" and providing mis-information. 538 Information in these declarations should be taken as advisory. 540 7.0 References 542 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 543 Resource Identifiers using the Domain Name System", RFC 2168, 544 June 1997. 546 [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN 547 Resolution", RFC 2169, June 1997. 549 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - 550 Information interchange - Representation of dates and times" 552 [RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 553 Bibliographic Identifiers as Uniform Resource Names", RFC 2288, 554 February 1998. 556 [NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution 557 using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt. 559 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 561 [IANA-CONSIDERATIONS] T. Narten and H. Alvestrand, "Guidelines for 562 Writing an IANA Considerations Section in RFCs", 563 draft-iesg-iana-considerations-06.txt. 565 [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements 566 for Uniform Resource Names", RFC1737, December 1994 568 [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 569 Name Resolution", RFC 2276, January 1998. 571 8.0 Authors' Addresses 573 Leslie L. Daigle 574 Bunyip Information Systems Inc 575 310 Ste. Catherine St. W 576 Suite 300 577 Montreal, Quebec, CANADA 578 H2X 2A1 579 voice: +1 514 875-8611 580 fax: +1 514 875-8134 581 email: leslie@bunyip.com 583 Dirk-Willem van Gulik 584 ISIS/STA/CEO - TP 270 585 Joint Research Centre Ispra 586 21020 Ispra (Va) 587 Italy. 588 voice: +39 332 78 9549 or 5044 589 fax: +39 332 78 9185 590 email: Dirk.vanGulik@jrc.it 592 Renato Iannella 593 DSTC Pty Ltd 594 Gehrmann Labs, The Uni of Queensland 595 AUSTRALIA, 4072 596 voice: +61 7 3365 4310 597 fax: +61 7 3365 4311 598 email: renato@dstc.edu.au 600 Patrik Faltstrom 601 Tele2/Swipnet 602 Borgarfjordsgatan 16 603 P.O. Box 62 604 S-164 94 Kista 605 SWEDEN 606 voice: +46-5626 4000 607 fax: +46-5626 4200 608 email: paf@swip.net