idnits 2.17.1 draft-ietf-urn-nid-req-08.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 249 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 41 has weird spacing: '...rt from proof...' == Line 325 has weird spacing: '...n-forum discu...' == Line 399 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 568, 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: 15 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 March 31, 1999 Bunyip Information Systems 3 draft-ietf-urn-nid-req-08.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 and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 0.0 Abstract 37 The URN WG has defined a syntax for Uniform Resource Names 38 (URNs) [RFC2141], as well as some proposed mechanisms for their 39 resolution and use in Internet applications ([RFC2168, RFC2169]). 40 The whole rests on the concept of individual "namespaces" within the 41 URN structure. Apart from proof-of-concept namespaces, the use 42 of existing identifiers in URNs has been discussed ([RFC2288]), 43 and this document lays out general definitions of and 44 mechanisms for establishing URN "namespaces". 46 1.0 Introduction 48 Uniform Resource Names (URNs) are resource identifiers with the 49 specific requirements for enabling location independent 50 identification of a resource, as well as longevity of reference. 51 There are 2 assumptions that are key to this document: 53 Assumption #1: 55 Assignment of a URN is a managed process. 57 I.e., not all strings that conform to URN syntax are necessarily 58 valid URNs. A URN is assigned according to the rules of a 59 particular namespace (in terms of syntax, semantics, and process). 61 Assumption #2: 63 The space of URN namespaces is managed. 65 I.e., not all syntactically correct URN namespaces (per the URN 66 syntax definition) are valid URN namespaces. A URN namespace 67 must have a recognized definition in order to be valid. 69 The purpose of this document is to outline a mechanism and provide a 70 template for explicit namespace definition, along with the mechanism 71 for associating an identifier (called a "Namespace ID", or NID) which 72 is registered with the Internet Assigned Number Authority, IANA. 74 Note that this document restricts itself to the description of 75 processes for the creation of URN namespaces. If "resolution" of any 76 so-created URN identifiers is desired, a separate process of 77 registration in a global NID directory, such as that provided by the 78 NAPTR system [RFC2168], is necessary. See [NAPTR-REG] for information 79 on obtaining registration in the NAPTR global NID directory. 81 2.0 What is a URN Namespace? 83 For the purposes of URNs, a "namespace" is a collection of 84 uniquely-assigned identifiers. A URN namespace itself has an 85 identifier in order to 87 . ensure global uniqueness of URNs 88 . (where desired) provide a cue for the structure of the 89 identifier 91 For example, ISBNs and ISSNs are both collections of identifiers used 92 in the traditional publishing world; while there may be some number (or 93 numbers) that is both a valid ISBN identifier and ISSN identifier, 94 using different designators for the two collections ensures that no 95 two URNs will be the same for different resources. 97 The development of an identifier structure, and thereby a collection 98 of identifiers, is a process that is inherently dependent on the 99 requirements of the community defining the identifier, how they will 100 be assigned, and the uses to which they will be put. All of these 101 issues are specific to the individual community seeking to define a 102 namespace (e.g., publishing community, association of booksellers, 103 protocol developers, etc); they are beyond the scope of the IETF 104 URN work. 106 This document outlines the processes by which a collection of 107 identifiers satisfying certain constraints (uniqueness of assignment, 108 etc) can become a bona fide URN namespace by obtaining a NID. In a 109 nutshell, a template for the definition of the namespace is completed 110 for deposit with IANA, and a NID is assigned. The details of the 111 process and possibilities for NID strings are outlined below; first, a 112 template for the definition is provided. 114 3.0 URN Namespace Definition Template 116 Definition of a URN namespace is accomplished by completing the 117 following information template. Apart from providing a mechanism 118 for disclosing structure of the URN namespace, this information 119 is designed to be useful for 121 . entities seeking to have a URN assigned in a namespace 122 (if applicable) 123 . entities seeking to provide URN resolvers for a namespace 124 (if applicable) 126 This is particularly important for communities evaluating the 127 possibility of using a portion of an existing URN namespace rather 128 than creating their own. 130 Information in the template is as follows: 132 Namespace ID: 134 Assigned by IANA. In some contexts, a particular one 135 may be requested (see below). 137 Registration Information: 139 This is information to identify the particular version of 140 registration information: 142 . registration version number: starting with 1, incrementing by 1 143 with each new version 144 . registration date: date submitted to the IANA, using 145 the format 146 YYYY-MM-DD 147 as outlined in [ISO8601]. 149 Declared registrant of the namespace: 151 Required: Name and e-mail address. 152 Recommended: Affiliation, address, etc. 154 Declaration of syntactic structure: 156 This section should outline any structural features of 157 identifiers in this namespace. At the very least, this 158 description may be used to introduce terminology used in 159 other sections. This structure may also be used for 160 determining realistic caching/shortcuts approaches; suitable 161 caveats should be provided. If there are any specific 162 character encoding rules (e.g., which character should 163 always be used for single-quotes), these should be listed 164 here. 166 Answers might include, but are not limited to: 168 . the structure is opaque (no exposition) 169 . a regular expression for parsing the identifier into 170 components, including naming authorities 172 Relevant ancillary documentation: 174 This section should list any RFCs, standards, or other published 175 documentation that defines or explains all or part of the 176 namespace structure. 178 Answers might include, but are not limited to: 180 . RFCs outlining syntax of the namespace 181 . Other of the defining community's (e.g., ISO) documents 182 outlining syntax of the identifiers in the namespace 183 . Explanatory material introducing the namespace 185 Identifier uniqueness considerations: 187 This section should address the requirement that 188 URN identifiers be assigned uniquely -- they are assigned 189 to at most one resource, and are not reassigned. 191 (Note that the definition of "resource" is fairly 192 broad; for example, information on "Today's Weather" might 193 be considered a single resource, although the content is 194 dynamic.) 196 Possible answers include, but are not limited to: 198 . exposition of the structure of the identifiers, and 199 partitioning of the space of identifiers amongst 200 assignment authorities which are individually responsible 201 for respecting uniqueness rules 202 . identifiers are assigned sequentially 203 . information is withheld; the namespace is opaque 205 Identifier persistence considerations: 207 Although non-reassignment of URN identifiers ensures 208 that a URN will persist in identifying a particular 209 resource even after the "lifetime of the resource", 210 some consideration should be given to the persistence 211 of the usability of the URN. This is particularly 212 important in the case of URN namespaces providing 213 global resolution. 215 Possible answers include, but are not limited to: 217 . quality of service considerations 219 Process of identifier assignment: 221 This section should detail the mechanisms and/or authorities 222 for assigning URNs to resources. It should make clear whether 223 assignment is completely open, or if limited, how 224 to become an assigner of identifiers, and/or get one 225 assigned by existing assignment authorities. Answers 226 could include, but are not limited to: 228 . assignment is completely open, following a particular 229 algorithm 230 . assignment is delegated to authorities recognized by 231 a particular organization (e.g., the Digital Object 232 Identifier Foundation controls the DOI assignment space and 233 its delegation) 234 . assignment is completely closed (e.g., for a private 235 organization) 237 Process for identifier resolution: 239 If a namespace is intended to be accessible for global 240 resolution, it must be registerd in an RDS (Resolution 241 Discovery System, see [RFC2276]) such as NAPTR. Resolution 242 then proceeds according to standard URI resolution processes, 243 and the mechanisms of the RDS. What this section should 244 outline is the requirements for becoming a recognized resolver 245 of URNs in this namespace (and being so-listed in the RDS 246 registry). 248 Answers may include, but are not limited to: 250 . the namespace is not listed with an RDS; this is not 251 relevant 252 . resolution mirroring is completely open, with a mechanism 253 for updating an appropriate RDS 254 . resolution is controlled by entities to which assignment 255 has been delegated 257 Rules for Lexical Equivalence: 259 If there are particular algorithms for determining 260 equivalence between two identifiers in the underlying 261 namespace (hence, in the URN string itself), rules can 262 be provided here. 264 Some examples include: 266 . equivalence between hyphenated and non-hyphenated 267 groupings in the identifier string 268 . equivalence between single-quotes and double-quotes 269 . Namespace-defined equivalences between specific 270 characters, such as "character X with or without 271 diacritic marks". 273 Note that these are not normative statements for any kind of 274 best practice for handling equivalences between characters; 275 they are statements limited to reflecting the namespace's 276 own rules. 278 Conformance with URN Syntax: 280 This section should outline any special considerations 281 required for conforming with the URN syntax. This is 282 particularly applicable in the case of legacy naming 283 systems that are used in the context of URNs. 285 For example, if a namespace is used in contexts other 286 than URNs, it may make use of characters that are reserved 287 in the URN syntax. This section should flag any such 288 characters, and outline necessary mappings to conform to 289 URN syntax. Normally, this will be handled by hex encoding 290 the symbol. 292 For example, see the section on SICIs in [RFC2288]. 294 Validation mechanism: 296 Apart from attempting resolution of a URN, a URN namespace 297 may provide mechanism for "validating" a URN -- i.e., 298 determining whether a given string is currently a 299 validly-assigned URN. For example, even if an ISBN 300 URN namespace is created, it is not clear that 301 all ISBNs will translate directly into "assigned URNs". 303 A validation mechanims might be: 305 . a syntax grammar 306 . an on-line service 307 . an off-line service 309 Scope: 311 This section should outline the scope of the use of the 312 identifiers in this namespace. Apart from considerations 313 of private vs. public namespaces, this section is critical 314 in evaluating the applicability of a requested NID. For 315 example, a namespace claiming to deal in "social security 316 numbers" should have a global scope and address all 317 social security number structures (unlikely). On the 318 other hand, at a national level, it is reasonable to 319 propose a URN namespace for "this nation's social security 320 numbers". 322 4.0 URN Namespace Registration, Update, and NID Assignment Process 324 Different levels of disclosure are expected/defined for namespaces. 325 According to the level of open-forum discussion surrounding 326 the disclosure, a URN namespace may be assigned or may request a 327 particular identifier. The [IANA-CONSIDERATIONS] document suggests 328 the need to specify update mechanisms for registrations -- who 329 is given the authority to do so, from time to time, and what are 330 the processes. Since URNs are meant to be persistently useful, few 331 (if any) changes should be made to the structural interpretation of 332 URN strings (e.g., adding or removing rules for lexical equivalence that 333 might affect the interpretation of URN IDs already assigned). However, it 334 may be important to introduce clarifications, expand the list of 335 authorized URN assigners, etc, over the natural course of a namespace's 336 lifetime. Specific processes are outlined below. 338 There are 3 categories of URN namespaces defined here, distinguished 339 by expected level of service and required procedures for registration. 340 Furthermore, registration maintenance procedures vary slightly from 341 one category to another. 343 I. Experimental: These are not explicitly registered with IANA. They 344 take the form 346 x- 348 No provision is made for avoiding collision of experimental 349 NIDs; they are intended for use within internal or limited 350 experimental contexts. 352 As there is no registration, no registration maintenance 353 procedures are needed. 355 II. Informal: These are registered with IANA and are assigned a 356 number sequence as an identifier, in the format: 358 "urn-" 360 where is chosen by the IANA on a First Come First 361 Served basis (see [IANA-CONSIDERATIONS]). 363 Registrants should send a copy of the registration 364 template (see section 3.0), duly completed, to the 366 urn-nid@apps.ietf.org 368 mailing and allow for a 2 week discussion period for 369 clarifying the expression of the registration information 370 and suggestions for improvements to the namespace proposal. 372 After suggestions for clarification of the registration 373 information have been incorporated, the template may be 374 submitted to: 376 iana@iana.org 378 for assignment of a NID. 380 The only restrictions on are that it consist 381 strictly of digits and that it not cause the NID to exceed 382 length limitations outlined in the URN syntax ([RFC2168]). 384 Registrations may be updated by the original registrant, 385 or an entity designated by the registrant, by updating 386 the registration template, submitting it to the discussion 387 list for a further 2 week discussion period, and finally 388 resubmitting it to IANA, as described above. 390 III. Formal: These are processed through an RFC review 391 process. The RFC need not be standards-track. The 392 template defined in section 3.0 may be included as part 393 of an RFC defining some other aspect of the namespace, 394 or it may be put forward as an RFC in its own right. 395 The proposed template should be sent to the 397 urn-nid@apps.ietf.org 399 mailing list to allow for a 2 week discussion period for 400 clarifying the expression of the registration information, 401 before the IESG progresses the document to RFC status. 403 A particular NID string is requested, and is assigned by IETF 404 consensus (as defined in [IANA-CONSIDERATIONS]), with 405 the additional constraints that the NID string must 407 . not be an already-registered NID 408 . not start with "x-" (see Type I above) 409 . not start with "urn-" (see Type II above) 410 . not start with "XY-", where XY is any 411 combination of 2 ASCII letters (see NOTE, below) 412 . be more than 2 letters long 414 NOTE: ALL two-letter combinations, and two-letter combinations 415 followed by "-" and any sequence of valid NID characters, are 416 reserved for potential use as countrycode-based NIDs for 417 eventual national registrations of URN namespaces. The 418 definition and scoping of rules for allocation of responsibility 419 for such namespaces is beyond the scope of this document. 421 Registrations may be updated by updating the RFC through 422 standard IETF RFC update mechanisms. Thus, proposals for 423 updates may be made by the original authors, other IETF 424 participants, or the IESG. In any case, the proposed 425 updated template must be circulated on the urn-nid 426 discussion list, allowing for a 2 week review period. 428 URN namespace registrations will be posted in the anonymous FTP directory 429 "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/". 431 5.0 Example 433 The following example is provided for the purposes of illustration of 434 the URN NID template described in section 3.0. Although it is based on 435 a hypothetical "generic Internet namespace" that has been discussed informally 436 within the URN WG, there are still technical and infrastructural issues 437 that would have to be resolved before such a namespace could be properly 438 and completely described. 440 Namespace ID: 442 To be assigned 444 Registration Information: 446 Version 1 447 Date: 449 Declared registrant of the namespace: 451 Required: Name and e-mail address. 452 Recommended: Affiliation, address, etc. 454 Declared registrant of the namespace: 456 Name: T. Cat 457 E-mail: leslie@thinkingcat.com 458 Affiliation: Thinking Cat Enterprises 459 Address: 1 ThinkingCat Way 460 Trupville, NewCountry 462 Declaration of structure: 464 The identifier structure is as follows: 466 URN::: 468 where FQDN is a fully-qualified domain name, and the 469 assigned string is conformant to URN syntax requirements. 471 Relevant ancillary documentation: 473 Definition of domain names, found in: 475 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 476 RFC1035, November 1987. 478 Identifier uniqueness considerations: 480 Uniqueness is guaranteed as long as the assigned 481 string is never reassigned for a given FQDN, and that the FQDN 482 is never reassigned. 484 N.B.: operationally, there is nothing that prevents a domain 485 name from being reassigned; indeed, it is not an uncommon 486 occurrence. This is one of the reasons that this example 487 makes a poor URN namespace in practice, and is therefore not 488 seriously being proposed as it stands. 490 Identifier persistence considerations: 492 Persistence of identifiers is dependent upon suitable 493 delegation of resolution at the level of "FQDN"s, and persistence 494 of FQDN assignment. 496 Same note as above. 498 Process of identifier assignment: 500 Assignment of these URNs delegated to individual domain 501 name holders (for FQDNs). The holder of the FQDN registration 502 is required to maintain an entry (or delegate it) in the 503 NAPTR RDS. Within each of these delegated name partitions, 504 the string may be assigned per local requirements. 506 e.g. urn::thinkingcat.com:001203 508 Process for identifier resolution: 510 Domain name holders are responsible for operating or 511 delegating resolution servers for the FQDN in which they 512 have assigned URNs. 514 Rules for Lexical Equivalence: 516 FQDNs are case-insensitive. Thus, the portion of the URN 518 urn::: 520 is case-insenstive for matches. The remainder of the identifier 521 must be considered case-sensitve. 523 Conformance with URN Syntax: 525 No special considerations. 527 Validation mechanism: 529 None specified. 531 Scope: 533 Global. 535 6.0 Security Considerations 537 This document largely focuses on providing mechanisms for the 538 declaration of public information. Nominally, these declarations 539 should be of relatively low security profile, however there is 540 always the danger of "spoofing" and providing mis-information. 541 Information in these declarations should be taken as advisory. 543 7.0 References 545 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 546 Resource Identifiers using the Domain Name System", RFC 2168, 547 June 1997. 549 [RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN 550 Resolution", RFC 2169, June 1997. 552 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - 553 Information interchange - Representation of dates and times" 555 [RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 556 Bibliographic Identifiers as Uniform Resource Names", RFC 2288, 557 February 1998. 559 [NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution 560 using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt. 562 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 564 [IANA-CONSIDERATIONS] T. Narten and H. Alvestrand, "Guidelines for 565 Writing an IANA Considerations Section in RFCs", 566 draft-iesg-iana-considerations-06.txt. 568 [RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements 569 for Uniform Resource Names", RFC1737, December 1994 571 [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 572 Name Resolution", RFC 2276, January 1998. 574 8.0 Authors' Addresses 576 Leslie L. Daigle 577 Bunyip Information Systems Inc 578 147 St. Paul St. West 579 Suite 200 580 Montreal, Quebec, CANADA 581 H2Y 1Z5 582 voice: +1 514 285-0088 583 fax: +1 514 285-4515 584 email: leslie@bunyip.com 586 Dirk-Willem van Gulik 587 ISIS/STA/CEO - TP 270 588 Joint Research Centre Ispra 589 21020 Ispra (Va) 590 Italy. 591 voice: +39 332 78 9549 or 5044 592 fax: +39 332 78 9185 593 email: Dirk.vanGulik@jrc.it 595 Renato Iannella 596 DSTC Pty Ltd 597 Gehrmann Labs, The Uni of Queensland 598 AUSTRALIA, 4072 599 voice: +61 7 3365 4310 600 fax: +61 7 3365 4311 601 email: renato@dstc.edu.au 603 Patrik Faltstrom 604 Tele2/Swipnet 605 Borgarfjordsgatan 16 606 P.O. Box 62 607 S-164 94 Kista 608 SWEDEN 609 voice: +46-5626 4000 610 fax: +46-5626 4200 611 email: paf@swip.net