idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2012) is 4425 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-02 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2611 (Obsoleted by RFC 3406) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF URNbis WG A. Hoenes 3 Internet-Draft TR-Sys 4 Obsoletes: 3406 (if approved) March 12, 2012 5 Intended status: BCP 6 Expires: September 13, 2012 8 Uniform Resource Name (URN) Namespace Definition Mechanisms 9 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 11 Abstract 13 Uniform Resource Names (URNs) are intended to serve as persistent, 14 location-independent, resource identifiers. To structure and 15 organize their usage, the URN syntax (RFC 2141bis) specifies a 16 hierarchy that divides the set of possible URNs into "URN Namespaces" 17 that can be individually defined and managed. URN Namespaces in 18 particular serve to map existing identifier systems into the URN 19 system and thereby make available generic, network-based resolution 20 services for the identified documents, artifacts, and other objects 21 (and metadata related to them). 23 To achive these goals, URN Namespaces need to be specified in a 24 comparable manner, and their Namespace Identifiers (NIDs) need to be 25 registered with IANA, so that naming conflicts are avoided and 26 implementers of services can follow a structured approach in support 27 of various namespaces, guided by the registry to the related 28 documents and the particularities of specific namespaces, as 29 described in these Namespace registration documents. 31 This RFC serves as a guideline for authors of URN Namespace 32 definition and registration documents and the process to be followed 33 to register a URN Namespace with IANA. It describes the essential 34 content of such documents and how they shall be structured to allow 35 readers familar with the scheme to quickly assess the properties of a 36 specific URN Namespace. 38 This document is a companion document to the revised URN Syntax 39 specification, RFC 2141bis; it supersedes and replaces RFC 3406. 41 Discussion 43 Discussion of this memo utilizes the urn@ietf.org mailing list. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on September 13, 2012. 62 Copyright Notice 64 Copyright (c) 2012 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 This document may contain material from IETF Documents or IETF 78 Contributions published or made publicly available before November 79 10, 2008. The person(s) controlling the copyright in some of this 80 material may not have granted the IETF Trust the right to allow 81 modifications of such material outside the IETF Standards Process. 82 Without obtaining an adequate license from the person(s) controlling 83 the copyright in such materials, this document may not be modified 84 outside the IETF Standards Process, and derivative works of it may 85 not be created outside the IETF Standards Process, except to format 86 it for publication as an RFC or to translate it into languages other 87 than English. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 1.1. Requirement Language and Terminology . . . . . . . . . . . 5 93 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5 94 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 7 95 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 7 96 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 7 97 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 98 4. URN Namespace Registry: Processes for Registration and 99 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 100 4.1. Experimental Namespaces: No Registration . . . . . . . . . 10 101 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 10 102 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 11 103 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 12 104 4.4.1. Namespace Considerations in Registration Documents . . 12 105 4.4.2. Community Considerations in Registration Documents . . 13 106 4.4.3. Security Considerations in Registration Documents . . 14 107 4.4.4. IANA Considerations in Registration Documents . . . . 14 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 110 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 112 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 113 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 114 Appendix A. URN Namespace Definition Template . . . . . . . . . . 18 115 Appendix B. Registration steps in practice . . . . . . . . . . . 24 116 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25 117 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25 118 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25 119 C.3. Changes from URNBIS WG I-D -00 to -01 . . . . . . . . . . 28 120 C.4. Changes from URNBIS WG I-D -01 to -02 . . . . . . . . . . 28 121 Appendix D. Issues in this Draft . . . . . . . . . . . . . . . . 28 123 1. Introduction 125 Uniform Resource Names (URNs) are resource identifiers adhering to 126 the specific requirements of enabling location-independent 127 identification of a resource, as well as longevity of reference. 128 URNs are part of the larger Uniform Resource Identifier (URI) family 129 (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF 130 STD 66, RFC 3986 [RFC3986]) with the specific goal of providing 131 persistent naming of resources. 133 The URN Syntax (see below and RFC 2141bis 134 [I-D.ietf-urnbis-rfc2141bis-urn]) structures and organizes the 135 entirety of URNs into a hierarchy that divides the set of possible 136 URNs into "URN Namespaces" that can be individually defined, managed, 137 and (optionally) further subdivided. URN Namespaces in particular 138 serve to map existing identifier systems into the URN system and 139 thereby make available generic, network-based resolution services for 140 the identified documents, artifacts, and other objects (and their 141 metadata). 143 There are two assumptions that are key to this document: 145 Assumption #1: Assignment of a URN is a managed process. 147 I.e., not all strings that conform to URN syntax are necessarily 148 valid URNs. A URN is assigned according to the rules of a 149 particular namespace (in terms of syntax, semantics, and process). 151 Assumption #2: The space of URN Namespaces is managed. 153 I.e., not all syntactically correct URN Namespaces (per the URN 154 syntax definition) are valid URN Namespaces. A URN Namespace must 155 have a recognized definition in order to be valid. 157 To actually leverage the potential synergetic advantage of this 158 unification (structured embedding of existing namespaces into the URN 159 framework), URN Namespaces need to be specified in a comparable 160 manner, and their Namespace Identifiers (NIDs) need to be centrally 161 registered, so that naming conflicts are avoided and implementers of 162 services can follow a structured approach in support of various 163 namespaces, guided by the registry to the related documents and the 164 particularities of specific namespaces, as described in these 165 Namespace registration documents. 167 The purpose of this document is to outline a mechanism and provide a 168 template for explicit URN Namespace definition, as well as provide 169 the mechanism for associating an identifier (called a "Namespace ID", 170 or NID), which is registered with the Internet Assigned Numbers 171 Authority (IANA) [IANA] in the URN Namespaces registry maintained at 172 [IANA-URN]. 174 The URN Namespace definition and registration mechanisms originally 175 have been specified in RFC 2611 [RFC2611], which has been obsoleted 176 by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing 177 IANA procedures have been revised as well over the years, and at the 178 time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative 179 document. This document is a revision of RFC 3406 based on the 180 revised URN Syntax specification RFC 2141bis 181 [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. 183 The reader is referred to Section 1.1 of RFC 2141bis 184 [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the 185 history of documents fundamental for URNs. 187 Note that this document restricts itself to the description of 188 processes for the creation of URN Namespaces. If generic 189 "resolution" of any so-created URN identifiers is desired, a separate 190 process of registration in a global NID directory, such as that 191 proposed by the DDDS system [RFC3401], is necessary. See [RFC3405] 192 for information on obtaining registration in the DDDS global NID 193 directory. There also is work in progress [Ref: t.b.d.] to establish 194 an IANA registry for URN services, such that registration documents 195 can unambiguously identify such services and discuss their 196 applicability to the particular URN Namespace. 198 1.1. Requirement Language and Terminology 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in RFC 2119 [RFC2119]. 203 In this document, these key words describe requirements for the 204 process to be followed and the content to be provided in URN 205 Namespace definition documents and registration templates. 207 For the purpose of this document, its subject is spelled "URN 208 Namespace" (in headline case), whereas in other context, "namespace" 209 is spelled in lower case, e.g. to designate a (standard or non- 210 standard) identifier system on which a URN Namespace is based. 212 2. What is a URN Namespace? 214 For the purposes of URNs, a "namespace" is a collection of uniquely- 215 assigned identifiers. That is, the identifiers are not ever assigned 216 to more than one resource. These resources may be stable (e.g., a 217 doctoral dissertation or an abstract concept of a protocol) or 218 dynamic (e.g., a continuously evolving web site of a periodical or a 219 specific protocol parameter registry subject to additions and 220 maintenance). If the identified resource is a metadata record, such 221 record may describe several objects (such as two versions of a book) 222 or a collection of objects (such as a periodical with, say, monthly 223 issues); in this case, these subordinate objects are not the 224 identified resources. For each namespace, it must be clear what the 225 identified resources are; if the namespace is heterogenous in this 226 respect, the registration and resolution systems must unambiguously 227 designate the kind of identified resource, for each identifier 228 assigned in the namespace. Once assigned, URNs are never re-assigned 229 to a different resource. A single resource, however, may have more 230 than one URN assigned to it -- within a particular Namespace or among 231 different Namespaces -- for different purposes, since the Namespaces 232 are not mutually exclusive. 234 Such abstract namespace might be defined by some pre-established 235 (standard or non-standard) identifier system that can be made 236 "network-actionable" by embedding it into the URN framework using a 237 specific URN Namespace. A URN Namespace itself has an identifier in 238 order to: 240 - ensure global uniqueness of URNs, 242 - (where desired) provide a cue for the structure of the identifier. 244 For example, many identifier systems use strings of numbers as 245 identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable 246 that there might be some numbers that are valid identifiers in two 247 different established identifier systems. Using different 248 designators for the two collections (and making these designators an 249 intrinsic syntactic part of URNs) ensures that no two URNs will be 250 the same for different resources (since each collection is required 251 to uniquely assign each identifier). 253 The development of an identifier structure, and thereby a collection 254 of identifiers, is a process that is inherently dependent on the 255 requirements of the community defining the identifier, how they will 256 be assigned, and the uses to which they will be put. All of these 257 issues are specific to the individual community seeking to define a 258 namespace (e.g., publishing community, association of booksellers, 259 protocol developers, technology-specific vendor groups, etc.); they 260 are beyond the scope of the IETF URN work. 262 This document outlines the processes by which a collection of 263 identifiers satisfying certain constraints (uniqueness of assignment, 264 etc.) can become a bona fide URN Namespace by obtaining a NID. In a 265 nutshell, a template for the definition of the Namespace is completed 266 for deposit with IANA, and a NID is assigned. The details of the 267 process and possibilities for NID strings are outlined below. 269 3. URN Namespace (Registration) Types 271 There are three categories (types) of URN Namespaces defined here, 272 distinguished by expected level of service and required procedures 273 for registration. Registration processes for each of these Namespace 274 types are given in Section 4. In both this Section and Section 4 275 these categories are ordered by increasing relevance/importance for 276 the Internet and, accordingly, increasing strenght of requirements 277 for the definition and registration processes. 279 3.1. Experimental Namespaces 281 These are not explicitly registered with IANA. 283 No provision is made for avoiding collision of experimental NIDs; 284 they are intended for use within internal or limited experimental 285 contexts. However, as described below in Section 4.1, these are 286 designated by a specific form of the NID to allow differentiation 287 (without preexisting knowledge of details) from the other URN 288 Namespace types. 290 3.2. Informal Namespaces 292 These are fully fledged URN Namespaces, with all the rights and 293 requirements associated thereto. Informal Namespaces can be 294 registered in global registration services. They are required to 295 uphold the general principles of a well-managed URN Namespace -- 296 providing persistent identification of resources and unique 297 assignment of identifier strings. Informal and Formal Namespaces 298 (described below) differ in the NID assignment. IANA will assign to 299 registered Informal Namespaces a simply structured, alphanumeric, 300 ordinal NID (following a pattern defined in Section 4.2 below), per 301 the process outlined in Section 4. 303 3.3. Formal Namespaces 305 A Formal Namespace may be requested, and IETF review sought, in cases 306 where the publication of the NID proposal and the underlying 307 namespace will provide benefit to some subset of users on the 308 Internet. That is, a formal NID proposal, if accepted, must be 309 functional on and with the global Internet, not limited to users in 310 communities or networks not connected to the Internet. For example, 311 assume a NID is requested that is meant for naming of physics 312 research material. If that NID request required that the user use a 313 proprietary network or service that was not at all open to the 314 general Internet user, then it would make a poor request for a formal 315 NID. The intent is that, while the community of those who may 316 actively use the names assigned within that NID may be small (but no 317 less important), the potential use of names within that NID is open 318 to any user on the Internet. 320 It is however expected that Formal NIDs may be applied to Namespaces 321 where some aspects are not fully open. For example, a Namespace may 322 make use of a fee-based, privately managed, or proprietary registry 323 for assignment of URNs in the Namespace, but it may still provide 324 benefit to some Internet users if the services associated with it 325 have openly published access protocols. 327 In addition to the basic registration information defined in the 328 registration template (in Appendix A), a Formal Namespace request 329 must be accompanied by documented considerations of the need for a 330 new Namespace and of the community benefit from formally establishing 331 the proposed URN Namespace. 333 Additionally, since the goal of URNs is to provide persistent 334 identification, careful consideration must be given to the longevity 335 and maintainability of the URN Namespace. The collective experience 336 of the IETF community contains a wealth of information on technical 337 factors that will prevent longevity of identification. Thus, the 338 IESG may elect not to accept a proposed Namespace registration if the 339 IETF community consensus is that the registration document contains 340 technical flaws that will prevent (or seriously impair the 341 possibility of) persistent identification, and that it therefore 342 should not be published as an RFC. 344 In addition to the technical aspects of the Namespace and its 345 resolution, consideration should be given to the following 346 organizatorial aspects: 348 - the organization maintaining the URN Namespace should credibly 349 demonstrate stability and the ability to maintain the URN 350 Namespace for a long time, and/or it should be clear how the 351 Namespace can continue to be usable/useful if the organization 352 ceases to be able to foster it; 354 - the organization(s) assigning URNs within the URN Namespace should 355 demonstrate ability and competency in name assignment; this should 356 improve the likelihood of persistence (e.g., to minimize the 357 likelihood of conflicts); 359 - the organization(s) assigning URNs within the URN Namespace need 360 to be committed to honor the scope, rules, and regulations 361 outlined its registration document and the documents defining the 362 underlying namespace and covering its identifier assignment and 363 maintenance procedures (if any), and the organization maintaining 364 the URN Namespace needs to have procedures in force that aim at 365 ensuring this adherance at a very high confidence level; and 367 - the involved organization(s) need to commit to not re-assign 368 existing names; old names MUST continue to be valid, even if the 369 owners or assignees of those names are no longer members or 370 customers of such organization; this does not mean that there 371 needs to be resolution of such names, but that they must not 372 resolve such names to false or stale information and that they 373 must not be reassigned. 375 If the underlying namespace is based on an established standard, the 376 standards body or the organization(s) in charge with the maintenance 377 of the namespace should be involved in the process, either by 378 performing the registration on their own, or by supporting the action 379 of the registrant and asserting support of the registration document. 381 These aspects, though hard to quantify objectively, should be 382 considered by organizations/people considering the development of a 383 Formal URN Namespace, and they will be kept in mind when evaluating 384 the technical merits of any proposed Formal URN Namespace. The kind 385 of mandate upon which the organization aims to undertake this 386 activity might give a strong indication for this evaluation, because 387 it likely mirrors the trust that other parties (for instance states, 388 international treaty organizations, professionals' associations, 389 etc.) put on the organization. 391 4. URN Namespace Registry: Processes for Registration and Update 393 Different levels of disclosure are expected/defined for Namespaces. 394 According to the level of open-forum discussion surrounding the 395 disclosure, a URN Namespace may be assigned an identifier or may 396 request a particular identifier. 398 The IANA Considerations Guidelines document (BCP 26 [RFC5226]) 399 suggests the need to specify update mechanisms for registrations -- 400 who is given the authority to do so, from time to time, and what are 401 the processes. Since URNs are meant to be persistently useful, few 402 (if any) changes should be made to the structural interpretation of 403 URN strings (e.g., adding or removing rules for lexical equivalence 404 that might affect the interpretation of URN IDs already assigned). 405 However, it may be important to introduce clarifications, expand the 406 list of authorized URN assigners, etc., over the natural course of a 407 Namespace's lifetime. Specific processes are outlined below. 409 The official list of registered URN Namespaces is currently 410 maintained by IANA at [IANA-URN]. 412 The registry is subdivided into two sub-registries, one for "Formal 413 URN Namespaces" and one for "Informal URN Namespaces", and each entry 414 there links to a stable repository of the registration document or 415 (an escrow copy of) the filled-out registration template. 417 The registration and maintenance procedures vary slightly between the 418 Namespace types. 420 4.1. Experimental Namespaces: No Registration 422 The NIDs of Experimental Namespaces (Section 3.1) are not explicitly 423 registered with IANA. They SHOULD take the form: 425 X- 427 where is a string of up to 30 characters, consisting solely of 428 letters, decimal digits, and hyphen ("-") characters, as specified by 429 the NID syntax specification in Section 2.1 of RFC 2141bis 430 [I-D.ietf-urnbis-rfc2141bis-urn]. 432 No provision is made for avoiding collision of experimental NIDs; 433 they are intended for use within internal or limited experimental 434 contexts exclusively. 436 Note: The above form is no more considered MANDATORY, in order to 437 accommodate experience and demonstrated evidence that, under 438 specific circumstances, experimental prototype systems have to 439 create and assign identifiers that the interested community 440 perceives are infeasible to be changed once the Namespace gets 441 formally registered. However, it is strongly RECOMMENDED to 442 prefix eventually targeted NIDs by "X-" during experiments and 443 tests. 445 As there is no registration, no registration/maintenance procedures 446 are needed. 448 Usage of Experimental URN Namespaces MUST be short-lived and whithin 449 a private scope; it MUST NOT be disclosed to the Internet at large, 450 e.g. by distribution of software versions that make use of such. 452 4.2. Informal Namespaces 454 The NIDs of Informal Namespaces are synthesized by the IANA using an 455 assigned sequence number and registered in their own sub-registry, as 456 indicated in Section 4; they take the format: 458 urn- 460 where is the decimal representation of a natural number, 461 with no leading zeroes. This sequence number is assigned by the IANA 462 on a First-Come-First-Served [RFC5226] basis to registration requests 463 for Informal Namespaces. 465 Registrants should send a copy of the registration template (as shown 466 in Appendix A), duly completed, to the urn-nid@ietf.org mailing list 467 for review and allow for a four-week discussion period for clarifying 468 the expression of the registration information and suggestions for 469 technical improvements to the Namespace proposal. 470 [[ Editorial NOTE: An even longer time is needed in practice! Should 471 we further increase the upper limit to 8 weeks? ]] 473 After suggestions for clarification of the registration information 474 have been incorporated, the template may be submitted for assignment 475 of a NID by email to iana@iana.org . 477 Registrations may be updated later by the original registrant, or by 478 an entity designated by the registrant, by updating the registration 479 template, submitting it to the discussion list for a further four- 480 week discussion period, and finally resubmitting it to IANA in a 481 message to iana@iana.org . 483 4.3. Formal Namespaces 485 Formal NIDs are assigned via IETF Review, as defined in BCP 26 486 [RFC5226]. The designated expert(s) for URN Namespace registrations 487 are nominated by the IESG, and their role adheres to the regulations 488 in BCP 26, unless specified otherwise below. 490 NIDs for Formal URN Namespaces MUST NOT have the forms indicated in 491 the preceding two sections for the other two Namespace types. (The 492 detailed formal rules are given below in Section 4.4.4.) Applicants, 493 in concert with the IANA experts, should ensure that the sought NID 494 strings are "proper" for the designated purpose, according to common 495 sense (and applicable legal rules). 497 "IETF Review" (per [RFC5226]) means that the Formal NID application 498 is made via submission to the IETF of an Internet-Draft that contains 499 the Namespace definition and targets publication as an RFC of 500 Informational or Standards-Track category, which needs to be approved 501 by the IESG after performing an IETF Last Call on the document and 502 evaluating review comments. The applicant can be an individual or an 503 IETF working group, in alignment with the designation of the 504 Internet-Draft. The actual choice should be properly considered by 505 applicants, but it is RECOMMENDED that the registration documents for 506 NIDs belonging to an established standard namespace aim at Standards- 507 Track, whereas other applications aim at Informational RFC. 509 Before publication can be requested, however, the draft Namespace 510 specification document must undergo an Expert Review process 511 [RFC5226] pursuant to the guidelines written here (as well as 512 standard RFC publication guidelines). The template defined in 513 Appendix A SHOULD be included as part of an RFC-to-be defining some 514 other aspect(s) of the Namespace, but it MAY be put forward as a 515 Namespace definition document in its own right. The proposed 516 template (including a pointer to a readily available copy of the 517 registration document) should be sent to the urn-nid@ietf.org mailing 518 list for review. This list is monitored by the designated expert(s). 519 The applicant has to allow for a four-week discussion period for 520 clarifying the expression of the registration information, and SHOULD 521 improve the Namespace document and/or registration template based on 522 the comments received, under the guidance of the designated 523 expert(s), before the IESG reviews the document. 525 Working groups generally SHOULD seek early expert review for a 526 Namespace definition document, before they hand it over to the IESG, 527 and individual applicants are also advised to seek expert comments 528 early enough. The aforementioned list can be contacted for informal 529 advice at any stage. 531 4.4. Registration Documents 533 The following subsections describe essential, MANDATORY parts of URN 534 Namespace registration documents, which will be focal in the expert 535 Review process and IETF Review. 537 4.4.1. Namespace Considerations in Registration Documents 539 The Namespace definition document MUST include a "Namespace 540 Considerations" section that outlines the perceived need for a new 541 namespace (i.e., where existing namespaces fall short of the 542 proposer's requirements). Part of the expected elaborations need to 543 be the arguments why other identifier systems, in particular a 544 specific/new URI Scheme would not be suitable for the intended 545 purpose. 547 Considerations MUST include, directly or with the help of referenced 548 stable (and preferably readily available) documents: 550 - URN assignment procedures; 552 - URN resolution/delegation; 554 - type of resources to be identified; 556 - type of services to be supported. 558 NOTE: It is expected that more than one Namespace may serve the same 559 "functional" purpose; the intent of the "Namespace Considerations" 560 section is to provide a record of the proposer's "due diligence" in 561 exploring existing possibilities, for the IESG's consideration. 563 [[ Editorial Note: See the endnote of the next section! 564 In particular, the above list (from RFC 3406) seems to be rather 565 orthogonal to the primary purpose of such section (as indicated in 566 the first paragraph), namely to provide evidence for the perceived 567 need for the new Namespace. ]] 569 4.4.2. Community Considerations in Registration Documents 571 The Namespace definition document MUST also include a "Community 572 Considerations" section that indicates the dimensions upon which the 573 proposer expects its community to be able to benefit by publication 574 of this Namespace, as well as how a general Internet user will be 575 able to use the space if they care to do so. 577 Potential considerations include: 579 - open assignment and use of identifiers within the Namespace; 581 - open operation of resolution servers for the Namespace 582 (server); 584 - creation of software that can meaningfully resolve and access 585 services for the Namespace (client). 587 [[ Editorial Note: 588 It is acknowledged that, in many cases, the Namespace Considerations 589 and Community Considerations are closely intertwined. Further, the 590 bulleted lists above (from RFC 3406) seems to be more related to the 591 items in the registration template entitled "Identifier uniqueness 592 considerations", "Identifier persistence considerations", "Process of 593 identifier assignment", and "Process for identifier resolution" than 594 to the primary objectives presented in the first paragraph above 595 (also from RFC 3406). 596 In fact, Namespace registration documents seen so far duplicate in 597 the registration template material from the "Community 598 Considerations" that addresses the above bullets. 599 Therefore: Should this specification now allow a combined section 600 "Namespace and Community Considerations" that focuses on the 601 (non-)utility of possible alternate namespace re-use and the 602 *benefits* of an independent new Namespace? 603 ]] 605 4.4.3. Security Considerations in Registration Documents 607 According to the general procurements for RFCs, URN Namespace 608 definition documents must include a "Security Considerations" section 609 (cf. BCP 72 [RFC3552]). That section has to identify the security 610 considerations specific to the subject URN Namespace. If the subject 611 URN Namespace is based on an underlying namespace, the registration 612 can include substantive security considerations described in 613 specifications related to that particular namespace by reference to 614 these documents. For general security considerations regarding URN 615 usage (and more generally, URI usage), for the sake of clarity and 616 brevity, it should refer to the Security Considerations in STD 63 617 [RFC3986] and in the URN Syntax document 618 [I-D.ietf-urnbis-rfc2141bis-urn]. 620 4.4.4. IANA Considerations in Registration Documents 622 According to the general procurements for RFCs, URN Namespace 623 definitions documents must include an "IANA Considerations" section 624 (cf. BCP 26 [RFC5226]). That section has to indicate that the 625 document includes a URN Namespace registration that is to be entered 626 into the IANA registry of Formal URN Namespaces. 628 Registration documents for formal URN Namespaces will provide a 629 particular, unique, desired NID string, and this will be assigned by 630 the Standards/Protocol Action of the IESG that approves the 631 publication of the registration document as an RFC. RFC 2141bis 632 [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII 633 strings that are interpreted in a case-insensitive manner, but the 634 NID string SHALL be registered in the capitalization form preferred 635 by the registrant. The proposed NID string MUST conform with the 636 syntax rule in Section 2.1 of RFC 2141bis 637 [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following 638 additional constraints: 640 - not be an already-registered NID; 642 - not start with "X-" (see Section 4.1 above); 644 - not start with "urn-" (see Section 4.2 above); 646 - not start with "xy-", where xy is any combination of 2 ASCII 647 letters (see NOTE below); 649 - not be equalt to or start with "example" (see NOTE below); 651 - be more than 2 characters long. 653 NOTE: All two-letter combinations as well as two-letter combinations 654 followed by "-" and any sequence of valid NID characters are reserved 655 for potential future use as countrycode-based NIDs for eventual 656 national registrations of URN Namespaces. The definition and scoping 657 of rules for allocation of responsibility for such Namespaces is 658 beyond the scope of this document. 659 Further, to avoid confusion, "urn" is not allowed as an NID string; 660 To allow neutral example URNs in code and documentation, NID strings 661 starting with "example" are set aside for use in documentation; IANA 662 has permanently reserved these string to prohibit assignment. 664 Applicants and the IANA experts have to ensure that the sought NID 665 strings are suitable and proper for the designated purpose and not 666 misleading, according to common sense and applicable legal rules. 667 The IETF Review process gives interested parties the opportunity to 668 rise concerns if they want to challenge proposed strings; the final 669 approval decision still remains with the IESG. 671 Registrations may be revised by updating the RFC through standard 672 IETF RFC update processes. In any case, a revised document, in the 673 form of a new Internet-Draft, must be published, and the proposed 674 updated template must be circulated on the urn-nid discussion list, 675 allowing for a four-week review period before pursuing RFC 676 publication of the new document. 678 5. Security Considerations 680 This document largely focuses on providing mechanisms for the 681 declaration of public information. Nominally, these declarations 682 should be of relatively low security profile; however, there is 683 always the danger of "spoofing" and providing mis-information. 684 Information in these declarations should be taken as advisory. 686 6. IANA Considerations 688 This document outlines the processes for registering URN Namespaces, 689 and has implications for the IANA in terms of registries to be 690 maintained, as previously defined in RFC 3406 [RFC3406]. This 691 document replaces RFC 3406; it contains a revised description for the 692 management of the "Uniform Resource Names (URN) Namespaces" IANA 693 Registry that uses the policy designation terms from BCP 26, RFC 5226 694 [RFC5226], but does not introduce significant changes to the 695 applicable procedures. 697 Until recently, that registry has been available in HTML, XML, and 698 plain text from the generic web page at 699 [IANA-URN]. 701 [[ NOTE: It would be preferable to restore the generic, most 702 universally supported (HTML) form of the registry be identified by an 703 implementation-neutral URL, as previously supported by IANA: 704 . Yet, currently 705 this URI and similar forms all resolve to an XML version. 706 The content there should link to alternate forms (.xml, .txt), and 707 those alternate versions should indicate the *other* versions; i.e., 708 where the .txt version (currently only available at ftp.IANA.ORG) 709 also says, "This registry is also available in XML and plain text 710 formats.", it should better say: "This registry is also available in 711 HTML and XML formats." Similarly, the XML form should point to the 712 HTML and plain text forms. ]] 714 All references there to the predecessor, [RFC3406], should be 715 replaced by references to this document. 716 We would appreciate a reorganization of the Registry web page to make 717 the registration templates for Informal URN Namespaces directly 718 linked from the main page; this would make the page /assignments/ 719 urn-informal.htm page dispensable (for persistency's sake, the web 720 server should redirect requests to the /assignments/urn-namespaces 721 page. 723 Section 4 of this document outlines the general procedures. 724 Section 4.4.4 above describes the syntax rules for NIDs to which the 725 registry needs to obey. 727 As pointed out in Section 4.4.4 above and in RFC 2141bis 728 [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently 729 reserved and MUST NOT be assigned as an NID. All strings starting 730 with "example" are permanently reserved for use in code and 731 documentation, and hence MUST NOT be assigned as an NID. 733 In all cases of new Namespace registration proposals, the IANA should 734 provisionally assign the appropriate NID (informal or formal), as 735 described throughout the body of this memo, once an IESG-designated 736 expert has confirmed that the requisite registration process steps 737 have been completed. These registrations become permanent and can be 738 made publicly available once the registration document has been 739 approved by the IESG for publications as a Standards-Track or 740 Informational RFC. 742 7. Acknowledgements 744 This document is heavily based on RFC 3406, the authors of which are 745 cordially acknowledged. 747 This document also been inspired by other recent documents that have 748 updated important IANA registries, and the countless authors and 749 contributors to these efforts are acknowledged anonymously. 751 Several individuals in the URNbis working group have participated in 752 the detailed discussion of this memo. Particular thanks for detailed 753 review comments and text suggestions go to Juha Hakala, Peter Saint- 754 Andre, and Mykyta Yevstifeyev. 756 8. References 758 8.1. Normative References 760 [I-D.ietf-urnbis-rfc2141bis-urn] 761 Hoenes, A., "Uniform Resource Name (URN) Syntax", 762 draft-ietf-urnbis-rfc2141bis-urn-02 (work in progress), 763 March 2012. 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, March 1997. 768 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 769 Internet: Timestamps", RFC 3339, July 2002. 771 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 772 Resource Identifier (URI): Generic Syntax", STD 66, 773 RFC 3986, January 2005. 775 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 776 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 777 May 2008. 779 8.2. Informative References 781 [IANA] IANA, "The Internet Assigned Numbers Authority", 782 . 784 [IANA-URN] IANA, "Uniform Resource Names (URN) Namespace Registry", 785 . 787 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 788 Name Resolution", RFC 2276, January 1998. 790 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 791 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 792 June 1999. 794 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 795 IETF URI Planning Interest Group: Uniform Resource 796 Identifiers (URIs), URLs, and Uniform Resource Names 797 (URNs): Clarifications and Recommendations", RFC 3305, 798 August 2002. 800 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 801 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 803 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 804 Part Five: URI.ARPA Assignment Procedures", BCP 65, 805 RFC 3405, October 2002. 807 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 808 "Uniform Resource Names (URN) Namespace Definition 809 Mechanisms", BCP 66, RFC 3406, October 2002. 811 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 812 Text on Security Considerations", BCP 72, RFC 3552, 813 July 2003. 815 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 816 Specifications: ABNF", STD 68, RFC 5234, January 2008. 818 Appendix A. URN Namespace Definition Template 820 Definition of a URN Namespace is accomplished by completing the 821 following information template. 822 Apart from providing a mechanism for disclosing the structure of the 823 URN Namespace, this information is designed to be useful for 825 - entities seeking to have a URN assigned in a Namespace (if 826 applicable) and 828 - entities seeking to provide URN resolvers for a Namespace (if 829 applicable). 831 This is particularly important for communities evaluating the 832 possibility of using a portion of an existing URN Namespace rather 833 than creating their own. 835 Applications for Formal URN Namespaces must also document "Namespace 836 Considerations", "Community Considerations", "Security 837 Considerations", and "IANA Considerations", as described in 838 Section 4.4. 840 Information in the template is as follows (text in curly braces is 841 tutorial and should be removed from filled-in templates): 843 Namespace ID: 845 { If request is for an Informal NID, indicate so; the number will 846 be assigned by IANA. In the case of a Formal NID registration, 847 regularly a particular NID string will be requested. } 849 Registration Information: 851 { This is information to identify the particular version of 852 registration information: } 853 - version number: 854 { starting with 1, incrementing by 1 with each new version } 855 - date: 856 { date submitted to the IANA or date of approval of 857 registration document, using the format outlined in "Date and 858 Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD } 860 Declared registrant of the Namespace: 862 - Registering organization: 863 Name: { ... } 864 Address: { ... } 865 - Designated contact person: 866 Name: { ... } 867 { Address: ... 868 (at least one of: Email, Phone, Postal address) } 870 Declaration of syntactic structure of NSS part: 872 { Note: In the past, there has been iterated trouble in tentative 873 registration documents with confusion between entire URN syntax 874 and NSS syntax (only). Since the "urn:" prefix is fixed and the 875 NID is fully determined by the "Namespace ID" clause above, in 876 order to avoid error prone duplication, this version of the 877 template restricts this clause to the NSS (Namespace Specific 878 String) part of the new URNs. } 880 { 881 This section should outline any structural features of identifiers 882 in this Namespace. At the very least, this description may be 883 used to introduce terminology used in other sections. This 884 structure may also be used for determining realistic caching/ 885 shortcuts approaches; suitable caveats should be provided. If 886 there are any specific character encoding rules (e.g., which 887 character should always be used for single-quotes), these should 888 be listed here. 890 Answers might include, but are not limited to: 891 - the structure is opaque (no exposition); 892 - a regular expression for parsing the identifier into 893 components, including naming authorities; 894 - formal syntax of the NSS, preferably in ABNF (STD 68 895 [RFC5234]). 896 } 898 Relevant ancillary documentation: 900 { 901 This section should list any RFCs, standards, or other published 902 documentation that defines or explains all or part of the 903 namespace structure. 905 Answers might include, but are not limited to: 906 - RFCs that outline the syntax of the namespace; 907 - other documents of the defining community (e.g., ISO) that 908 outline the syntax of the identifiers in the namespace; 909 - explanatory material that introduces the namespace. 910 } 912 Conformance with URN Syntax: 914 { 915 This section should outline any special considerations required 916 for conforming with the URN syntax. This is particularly 917 applicable in the case of legacy naming systems that are used in 918 the context of URNs. 920 For example, if a namespace is used in contexts other than URNs, 921 it may make use of characters that are reserved in the URN syntax. 923 This section should flag any such characters, and outline 924 necessary mappings to conform to URN syntax. Normally, this will 925 be handled by percent-encoding the symbol. 926 } 928 Rules for Lexical Equivalence of NSS part: 930 { Note: In the past, there has been iterated trouble in tentative 931 registration documents with regard to what rules can be imposed 932 for lexical equivalence. Since the "urn:" prefix and the NID part 933 both are invariably case-insensitive per RFC 3986 and RFC 2141bis, 934 in order to avoid repeated confusion, this version of the template 935 tentatively restricts this clause to only the NSS part of the 936 newly specified URNs. } 937 { 938 If there are particular algorithms for determining equivalence 939 between two identifiers in the underlying namespace (and hence, in 940 the URN string itself), rules can be provided here. 942 Some examples include: 943 - equivalence between hyphenated and non-hyphenated groupings in 944 the identifier string; 945 - equivalence between single-quotes and double-quotes; 946 - namespace-defined equivalences between specific characters, 947 such as "character X with or without diacritic marks". 949 Note that these are not normative statements for any kind of best 950 practice for handling equivalences between characters; they are 951 statements limited to reflecting the namespace's own rules. 953 However, namespaces that seek to provide higher-level lexical 954 equivalence rules should preferably make use of established and 955 standardized normalization procedures (like the methods leading to 956 the various Unicode Normalization Forms, which would have to be 957 applied before UTF-8 encoding) and not invent their own "magic"; 958 in practice, the utility of such things is likely to be limited 959 since test of lexical equivalence is a typical client-side pre- 960 screening operation performed by applications that try to remain 961 as general as possible and typically will not have built-in, NID- 962 specific knowledge -- ultimately, functional (or semantical) 963 equivalence of URNs can only be decided in the NID-specific 964 assignment/resolution systems, and their internal rules can be 965 handled much more flexibly than more complicated, nailed-down 966 lexical equivalence rules that are unlikely to be implemented at 967 large. 968 } 970 Identifier uniqueness considerations: 972 { 973 This section should address the requirement that URN identifiers 974 be assigned uniquely -- they are assigned to at most one resource, 975 and are not reassigned. 977 (Note that the definition of "resource" is fairly broad; for 978 example, information on "Today's Weather" might be considered a 979 single resource, although the content is dynamic.) 980 Possible answers include, but are not limited to: 981 - exposition of the structure of the identifiers, and 982 partitioning of the space of identifiers amongst assignment 983 authorities that are individually responsible for respecting 984 uniqueness rules; 985 - identifiers are assigned sequentially; 986 - information is withheld; that is, the namespace is opaque. 987 } 989 Identifier persistence considerations: 991 { 992 Although non-reassignment of URN identifiers ensures that a URN 993 will persist in identifying a particular resource even after the 994 "lifetime of the resource", some consideration should be given to 995 the persistence of the usability of the URN. This is particularly 996 important in the case of URN Namespaces providing global 997 resolution. 999 Possible answers include, but are not limited to: 1000 - quality of service considerations. 1001 } 1003 Process of identifier assignment: 1005 { 1006 This section should detail the mechanisms and/or authorities for 1007 assigning URNs to resources. It should make clear whether 1008 assignment is completely open, or if limited, how to become an 1009 assigner of identifiers, and/or get one assigned by existing 1010 assignment authorities. 1012 Answers could include, but are not limited to: 1013 - assignment is completely open, following a particular 1014 algorithm; 1015 - assignment is delegated to authorities recognized by a 1016 particular organization (e.g., the Digital Object Identifier 1017 Foundation controls the DOI assignment space and its 1018 delegation); 1019 - assignment is completely closed (e.g., for a private 1020 organization). 1021 } 1023 Process for identifier resolution: 1025 { 1026 If a Namespace is intended to be accessible for global resolution, 1027 it must be registered in an RDS (Resolution Discovery System, see 1028 RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]). 1029 Resolution then proceeds according to standard URI resolution 1030 processes, and the mechanisms of the RDS. What this section 1031 should outline is the requirements for becoming a recognized 1032 resolver of URNs in this Namespace (and being so listed in the RDS 1033 registry). 1035 Answers may include, but are not limited to: 1036 - the Namespace is not listed with an RDS, this is not relevant; 1037 - resolution mirroring is completely open, with a mechanism for 1038 updating an appropriate RDS; 1039 - resolution is controlled by entities to which assignment has 1040 been delegated. 1041 } 1043 Validation mechanism: 1045 { 1046 Apart from attempting resolution of a URN, a URN Namespace may 1047 provide mechanisms for "validating" a URN -- i.e., determining 1048 whether a given string is currently a validly-assigned URN. There 1049 are 2 issues here: 1) users should not "guess" URNs in a 1050 Namespace; 2) when the URN Namespace is based on an existing 1051 identifier system, it may not be the case that all the existing 1052 identifiers are assigned on Day 0. The reasonable expectation is 1053 that the resource associated with each resulting URN is somehow 1054 related to the thing identified by the original identifier system, 1055 but those resources may not exist for each original identifier. 1056 For example, even if a telephone number-based URN Namespace was 1057 created, it is not clear that all telephone numbers would 1058 immediately become "valid" URNs, that could be resolved using 1059 whatever mechanisms are described as part of the Namespace 1060 registration. 1062 Validation mechanisms might be: 1063 - a syntax grammar; 1064 - an on-line service; 1065 - an off-line service. 1066 } 1068 Scope: 1070 { 1071 This section should outline the scope of the use of the 1072 identifiers in this namespace, i.e. the precise kind of resources 1073 to which the URNs are assigned. Apart from considerations of 1074 private vs. public namespaces, this section is critical in 1075 evaluating the applicability of a requested NID. For example, a 1076 namespace claiming to deal with "social security numbers" should 1077 have a global scope and address all social security number 1078 structures (unlikely). On the other hand, at a national level, it 1079 is reasonable to propose a URN Namespace for "this nation's social 1080 security numbers". 1081 } 1083 Appendix B. Registration steps in practice 1085 The key steps for registration of Informal or Formal Namespaces 1086 typically play out as follows: 1088 A) Informal NID: 1090 1. Complete the registration template. This may be done as part 1091 of an Internet-Draft. 1093 2. Communicate the registration template to urn-nid@ietf.org for 1094 technical review -- as an email with a pointer to the 1095 submitted I-D or inline text containing the template. 1097 3. Update the registration template (and/or document) as 1098 necessary from comments, and repeat steps 2 and 3 as 1099 necessary. 1101 4. Once comments have been addressed (and the review period has 1102 expired), send a request to IANA with the revised registration 1103 template. 1105 B) Formal NID: 1107 1. Write an Internet-Draft describing the namespace and include 1108 the registration template, duly completed. Be sure to include 1109 "Namespace Considerations" and "Community Considerations" 1110 sections (or a combined section for these), "Security 1111 Considerations" and "IANA Considerations" sections, as 1112 described in Section 4.4. 1114 2. Submit the Internet-Draft, and send a pointer to the I-D 1115 (perhaps using a copy of the I-D announcement) to 1116 urn-nid@ietf.org in order to solicit technical review. 1118 3. Update the Internet-Draft as necessary from comments, and 1119 repeat steps 2 and 3 as needed. 1121 4. If the Internet-Draft is the product of a working group in the 1122 IETF, follow the usual WG process to forward the document to 1123 the IESG for publication as an RFC. Otherwise, find a 1124 sponsoring Area Director willing to guide the draft through 1125 the IESG. The IESG (or the IETF at large in case an IETF-wide 1126 last call is deemed necessary) may request further changes 1127 (submitted as I-D revisions) and/or direct discussion to 1128 designated working groups, area experts, etc. 1130 5. The IESG evaluation process includes a review by IANA, and if 1131 the IESG approves the document for publication as an RFC, IANA 1132 processing of the document will follow the regular work-flow 1133 between the RFC Editor and IANA. This way, the NID 1134 registration will be made public by IANA when the RFC is 1135 published. 1137 Appendix C. Changes from RFC 3406 1139 C.1. Essential Changes since RFC 3406 1141 [ RFC Editor: please remove the Appendix C.1 headline and all 1142 subsequent subsections of Appendix C starting with Appendix C.2. ] 1144 T.B.D. (after consolidation of this memo) 1146 C.2. Changes from RFC 3406 to URNbis WG Draft -00 1148 o Abstract: rewritten entirely; 1150 o Section 1 (Introduction): added historical RFC information; 1152 o Section 1.1 (Requirements Language): added; 1154 o Section 3.1: added Note that challenges the utility of 1155 Experimental Namespaces and raises question of whether formal 1156 "provisional" registrations would be useful; 1158 o Section 4: text expanded and updated; background material added; 1159 added Note to challenge IANA website practices; 1161 o Section 4.2 ff: changed "home" of URN-NID registration discussion 1162 list (it already had been moved to the IETF Secretariat servers); 1164 o Section 4.2: added Note to challenge the 2-week review period; in 1165 current practice, that is almost always exceeded, and some regard 1166 it as too short; 1168 o Section 4.3: largely clarified procedures as they happen in 1169 practice; adapted language for conformance with RFC 5226; use new 1170 home of URN-NID (as mentioned above); the registration template 1171 (Appendix A) now "SHOULD" be used; 1173 o Section 4.3: split off new Section 4.4 on Registration Documents, 1174 because registrants essentially are encouraged to follow these 1175 guidelines for Informal Namespaces as well, as far as practical; 1176 replaced "RFC" by "Registration Document"; Section 4.4 is 1177 subdivided for all mandatory sections; 1179 o Section 4.4.1: made requirements a "MUST"; 1181 o Sections 4.4.1 and 4.4.2: added common Note that challenges the 1182 need to split Namespace and Community Considerations, based on 1183 observed problems in practice to separate the topics, and pointing 1184 to overlap with clauses in the registration template due to 1185 bullets listed that are not so clearly related to the headlines 1186 under which they appear; suggestion is to avoid duplication, place 1187 factual stuff into the template and focus on rationale in these 1188 Considerations, perhaps in a common section; 1190 o Section 4.4.3: added discussion of Security Considerations 1191 section; advice is to focus on namespace-specific considerations 1192 and refer to the SecCons in the "generic" RFCs for the general 1193 issues; 1195 o Section 4.4.4: amended discussion of IANA Considerations section; 1196 this tries to reflect standing practice and codifies that Formal 1197 NIDs are generally proposed by the registrant; added Note that 1198 "urn" is permanently reserved and MUST NOT be assigned as a NID, 1199 to avoid confusion (as also specified in RFC 2141bis draft); wrt 1200 registration maintenance: got rid of wrong reference in RFC 3406 1201 (to RFC 2606); 1203 o Section 6 (IANA Considerations): updated and rephrased description 1204 of the role of this document, including a sketch of the history; 1205 added teat that tries to precisely describe what is expected from 1206 IANA on approval of this draft; added text on procedures and 1207 suggest a provisional assignment practice upon "thumbs-up" of the 1208 IANA Expert to protect prospective registrants from collateral 1209 damage on NID precedence in case the document suffers from delays 1210 unrelated to the registration template before it eventually gets 1211 approved; 1213 o Section 7 (Acknowledgements): added; 1215 o References: Updated and amended references; added pointers to 1216 chartered URNbis work items; removed entirely outdated example 1217 material related to legacy documents; 1219 o Appendix A and B.1: added words on Security Considerations 1220 section; 1222 o Appendix A (Registration Template): clarified role of text 1223 snippets in the Template: hint and commentary now all enclosed in 1224 curly braces, with not that these parts shall be removed when 1225 filling in the tempalte; indicate that Formal NIDs are normally 1226 proposed by registrant; changed date/time ref. from ISO 8601 to 1227 RFC 3339; use inherited term "percent-encoding"; 1229 o Appendix A -- structure: moved formal clauses on Conformance with 1230 URN Syntax and Rules for Lexical Equivalence to vicinity of 1231 namespace specific syntax clause, to which these are closely 1232 related; 1234 o Appendix A -- changes of clauses: the Declaration of syntactic 1235 structure and Rules for Lexical Equivalence clauses now 1236 tentatively have been restricted to the NSS part only; this change 1237 is described in NOTEs and motivated by the observation of repeated 1238 confusion in past and present registration documents, which 1239 hopefully can be avoided (and the job of the Expert and reviewers 1240 made easier) by leaving discussion of the invariate parts that 1241 cannot be re-specified there at the single place where they belong 1242 to: the NID is fully specified in the initial clause, rules for 1243 the NID and the URI scheme name "urn" are inherited from RFC 1244 2141[bis] and RFC 3986, respectively, and hence the new clause 1245 descriptions avoid conflict by taking these components out of 1246 scope of these clauses; 1248 o Appendix B.1 (Example Template): facelifted a bit; concerns with 1249 IESG policy on examples in RFCs raised in a NOTE; 1251 o Appendix B.2 (Registration steps in practice): updated and 1252 clarified description of procedure, in alignment to current 1253 practice; 1255 o Appendix C: removed "Changes from RFC 2611"; added this change 1256 log; 1258 o General: numerous editorial changes and enhancements, following 1259 contemporary RFC style. 1261 C.3. Changes from URNbis WG I-D -00 to -01 1263 Usage of terminology strenghtened. 1265 Clarified role and usage of Experimental Namespaces. 1267 Clarified NID strings for Formal Namespaces. 1269 Added hint that recommends Std. Track RFCs for NID applications based 1270 on established standard namespaces, and Informational for others. 1272 Changed standard review period from 2 to 4 weeks (pending 1273 discussion). 1275 Resolved with IANA: simple, traditional and generic URL used by IANA 1276 for the URN Namespace registry. (Needed to be re-opened in -02!) 1278 Numerous editorial enhancements and fixes. 1280 C.4. Changes from URNbis WG I-D -01 to -02 1282 General text edits based on evaluation of meeting and on-list 1283 comments. 1285 Updated and tightened the organizatorial requirements for Formal 1286 Namespace requests. 1288 Restored additional IANA Considerations -- due to observed defects. 1290 Reserved NID strings "example.*" for documentation (as suggested by 1291 Larry Masinter, Peter Saint-Andre, and Julian Reschke). 1293 Added text on possible "higher level" methods to establish lexical 1294 equivalence of URNs, with the caveats that such things are rather 1295 unlikely to get traction in general-purpose client software. 1297 Removed historical Appendix B.1 (Example Template). 1299 Various editorial enhancements and fixes. 1301 Updated and expanded "Issues" Appendix (below) in preparation of 1302 usage of the IETF Issue Tracker. 1304 Appendix D. Issues in this Draft 1306 [ Appendix to be replaced by use of IETF Tools issue tracker. ] 1308 For more details on the issues below, please also see the Editorial 1309 Notes interspersed in the body of this draft. 1311 Discuss consequences of RFC 2141bis (once consensus is achieved); if 1312 proposal for fragment part is adopted, details need to be described 1313 per Namespace that wants to adopt these possibilities, and maybe the 1314 registration template needs a new clause where this will be specified 1315 -- or the information has to be assigned to existing clauses. 1317 Do registration documents need more guidance and be caused to be more 1318 precise in their elaboration on the applicability of Services? Since 1319 RFC 2483 is considered outdated, but RFC 2483bis not yet alife (nor a 1320 URNbis work item), we might need a registry for URN Services 1321 (initially populated from RFC 2483) that can be referred to in 1322 Namespace registration documents, thus avoiding normative 1323 dependencies on a future RFC 2483bis. 1325 Do we actually need Experimental Namespaces? 1326 [Regarded as CLOSED affirmatively at IETF 80.] 1327 There are concerns regarding usage of "X-" NIDs, which is reported to 1328 having proven impractical in practice. This draft version contains 1329 tentative text to address these concerns; "X-" is now demoted to 1330 "SHOULD" level. 1332 The syntax of the NID strings for the various NID types is given in 1333 an informal manner (as has been done in RFC 3406); is it worth the 1334 effort to introduce ABNF for this purpose? 1335 [The request for ABNF has been voiced only once; the document Editor 1336 regards this issue as CLOSED.] 1338 Increase review/timeout periods for urn-nid list and IANA experts 1339 from 2 to 4 (or more) weeks? This draft version tentatively 1340 specifies 4 weeks. 1341 Juha Hakala has argued that the assessment of the responsible 1342 organizations needed to assure their ability to properly operate the 1343 Namespace could never be performed within the present 2 weeks time 1344 span; 8 weeks might be an even better choice for the future upper 1345 limit for the review period. It has been pointed out that even 8 1346 weeks are miniscule with regard to the expected lifetime of the to- 1347 be-registered Namespace and hence should not matter. In practice, 1348 the subsequent IESG evaluation of URN Namespace registration 1349 documents has typically needed much longer time. 1351 Clarification of the desired content of the "Namespace 1352 Considerations" and "Community Considerations" sections in 1353 registration documents. Shall we admit a combined section for both 1354 topics? (so far supported by 2 postings) Cf. the NOTEs in Sections 1355 4.4.1 and 4.4.2 for more details. 1356 [No feedback on the list since -01, so the draft text seems to have 1357 silent consensus and the issue is regarded as CLOSED.] 1358 Shall other strings beyond "urn" also be 'reserved' in the NID 1359 registry? (e.g. "uri", "url", "urc", ...) There have been voices in 1360 favor of leaving the decision of what is acceptable and reasonable in 1361 practice to the common sense of prospective registrants and the 1362 designated IANA experts. This draft version reserves NID strings 1363 matching the RE "^example.*" for documentation. 1365 Appendix A: Once RFC 2483 gets updated and an IANA registry for URN 1366 resolution services gets established, the "Process for identifier 1367 resolution" clause in the registration template should call out for 1368 enumerating the registered services that are applicable for the newly 1369 defined URN Namespace. 1370 How far can we go in this respect without an update to RFC 2483 at 1371 hands? 1373 Do we really still need Appendix B.1 ? (There are lots of real-life 1374 examples now!) 1375 [ Old B.1 removed, old B.2 became Appendix B; ==> CLOSED ] 1377 Author's Address 1379 Alfred Hoenes 1380 TR-Sys 1381 Gerlinger Str. 12 1382 Ditzingen D-71254 1383 Germany 1385 EMail: ah@TR-Sys.de