idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03.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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC3986, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2141, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (October 19, 2012) is 4204 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-03 ** 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) -- Obsolete informational reference (is this intentional?): RFC 4020 (Obsoleted by RFC 7120) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF URNbis WG A. Hoenes, Ed. 3 Internet-Draft TR-Sys 4 Obsoletes: 3406 (if approved) October 19, 2012 5 Intended status: BCP 6 Expires: April 22, 2013 8 Defining Uniform Resource Name (URN) Namespaces 9 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 11 Abstract 13 RFC 2141bis formalizes the concept of Uniform Resource Names (URNs) 14 for persistent, location-independent, resource identifiers within the 15 generic URI system specified in RFC 3986. To structure and organize 16 URN usage, RFC 2141bis specifies a hierarchy that divides the set of 17 possible URNs into "URN Namespaces" that can be individually defined 18 and managed. URN Namespaces allow to map existing identifier systems 19 into the URN scheme and thereby make available generic, network-based 20 resolution services for the identified resources (documents, 21 artifacts, and other objects) and metadata related to them. 23 To this end, URN Namespaces need to be defined and 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 design guideline for stakeholders of URN 32 Namespaces and authors of URN Namespace definition and registration 33 documents. It describes the process to be followed to register a URN 34 Namespace with IANA and the essential content of such documents. 36 This document supersedes and replaces RFC 3406. 38 Discussion 40 Discussion of this memo utilizes the urn@ietf.org mailing list. 41 [[ RFC-Editor: this clause to be deleted before RFC publication ]] 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on April 22, 2013. 60 Copyright Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 This document may contain material from IETF Documents or IETF 76 Contributions published or made publicly available before November 77 10, 2008. The person(s) controlling the copyright in some of this 78 material may not have granted the IETF Trust the right to allow 79 modifications of such material outside the IETF Standards Process. 80 Without obtaining an adequate license from the person(s) controlling 81 the copyright in such materials, this document may not be modified 82 outside the IETF Standards Process, and derivative works of it may 83 not be created outside the IETF Standards Process, except to format 84 it for publication as an RFC or to translate it into languages other 85 than English. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 1.1. Requirement Language and Terminology . . . . . . . . . . . 5 91 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 6 92 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 8 93 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 8 94 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 95 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 8 96 4. URN Namespace Registry: Processes for Registration and 97 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 4.1. Experimental Namespaces: No Registration . . . . . . . . . 11 99 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 12 100 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 13 101 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 14 102 4.4.1. Namespace Considerations in Registration Documents . . 14 103 4.4.2. Community Considerations in Registration Documents . . 15 104 4.4.3. Security Considerations in Registration Documents . . 16 105 4.4.4. IANA Considerations in Registration Documents . . . . 16 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 112 Appendix A. URN Namespace Definition Template . . . . . . . . . . 21 113 A.1. Annotated URN Namespace Definition Template . . . . . . . 21 114 A.2. Plain URN Namespace Definition Template (Informative) . . 27 115 Appendix B. Summary of Registration Steps (Informative) . . . . . 28 116 Appendix C. Changes from RFC 3406 (Informative) . . . . . . . . . 29 117 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 29 118 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 29 119 C.3. Changes from URNbis WG I-D -00 to -01 . . . . . . . . . . 32 120 C.4. Changes from URNbis WG I-D -01 to -02 . . . . . . . . . . 32 121 C.5. Changes from URNbis WG I-D -02 to -03 . . . . . . . . . . 32 123 1. Introduction 125 Uniform Resource Names (URNs) are identifiers bound to resources with 126 the objective to provide location-independent identification of these 127 resources as well as longevity of reference. URNs are part of the 128 larger Uniform Resource Identifier (URI) family (see the joint W3C/ 129 IETF memorandum, RFC 3305 [RFC3305], and the IETF STD 66, RFC 3986 130 [RFC3986]), with the specific goal of persistent binding names to 131 resources. 133 The URN scheme formalized in 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 resources (documents, artifacts, abstract concepts, 141 and other objects) and their 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 Namespace identifiers (per 154 the URN syntax definition) designate valid URN Namespaces. A URN 155 Namespace must have a well recognized definition in order to be 156 valid. 158 To actually draw benefits from this unification (structured embedding 159 of existing namespaces into the URN framework), URN Namespaces have 160 common design considerations, they need to be specified in a 161 comparable manner, and their Namespace Identifiers (NIDs) need to be 162 centrally registered, so that naming conflicts are avoided and 163 implementers of services can follow a structured approach in support 164 of various namespaces, guided by the registry to the related 165 documents and the particularities of specific namespaces, as 166 described in these URN Namespace registration documents. 168 The primary purpose of this document is to outline a mechanism for 169 explicit URN Namespace definition, associating it with an identifier 170 (called a "Namespace ID", or NID). To this end, this RFC defines the 171 requirements for URN NID specification documents and provides a 172 registration template, which is to be registered with the Internet 173 Assigned Numbers Authority (IANA) [IANA] in the URN Namespaces 174 registry maintained at [IANA-URN]. However, to give additional 175 guidance to prospective stakeholders / designers of URN Namespaces in 176 fulfiling the requirements for registration, this document also 177 elaborates on generic considerations and design choices for the 178 establishment of URN Namespaces. 180 The URN Namespace definition and registration mechanisms originally 181 have been specified in BCP 33, RFC 2611 [RFC2611], which has been 182 obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents 183 prescribing IANA procedures have been revised as well over the years, 184 and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the 185 normative document. This document is a revision of RFC 3406 based on 186 the revised specification of URNs in RFC 2141bis 187 [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. 189 The reader is referred to Section 1.1 of RFC 2141bis 190 [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the 191 history of documents fundamental for URNs. 193 Note that this document restricts itself to the description of 194 processes for the creation of URN Namespaces. If generic 195 "resolution" of any so-created URN identifiers is desired, a separate 196 process of registration in a global NID directory, such as that 197 proposed by the DDDS system [RFC3401], is necessary. See [RFC3405] 198 for information on obtaining registration in the DDDS global NID 199 directory. RFC 2141bis establishes an IANA registry for URN 200 services, such that registration documents can unambiguously identify 201 such services and discuss their applicability to the particular URN 202 Namespace. 204 1.1. Requirement Language and Terminology 206 When spelled in all-capitals as in this paragraph, the key words 207 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 208 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 209 are to be interpreted as described in BCP 14 [RFC2119]. In this 210 document, these key words describe requirements for the process to be 211 followed and the content to be provided in URN Namespace definition 212 documents and registration templates. 214 For the purpose of this document, its subject is spelled "URN 215 Namespace" (in headline case), whereas in other context, "namespace" 216 is spelled in lower case, e.g., to designate a (standard or non- 217 standard) identifier system on which a URN Namespace is based. 219 2. What is a URN Namespace? 221 For the purposes of URNs, a "namespace" is a collection of uniquely- 222 assigned identifiers. That is, the identifiers are not ever assigned 223 to more than one resource. These resources may be stable (e.g., a 224 doctoral dissertation or an abstract concept of a protocol) or 225 dynamic (e.g., a continuously evolving web site of a periodical or a 226 specific protocol parameter registry subject to additions and 227 maintenance). If the identified resource is a metadata record, such 228 record may describe several objects (such as two versions of a book) 229 or a collection of objects (such as a periodical with, say, monthly 230 issues); in this case, these subordinate objects are not the 231 identified resources. For each namespace, it must be clear what the 232 identified resources are; if the namespace is heterogenous in this 233 respect, the registration and resolution systems must unambiguously 234 designate the kind of identified resource, for each identifier 235 assigned in the namespace. Once assigned, URNs are never re-assigned 236 to a different resource. A single resource, however, may have more 237 than one URN assigned to it -- within a particular Namespace or among 238 different Namespaces -- for different purposes, since the Namespaces 239 are not mutually exclusive. 241 Such abstract namespace might be defined by some pre-established 242 (standard or non-standard) identifier system that can be made 243 "network-actionable" by embedding it into the URN framework using a 244 specific URN Namespace. A URN Namespace itself has an identifier in 245 order to: 246 - ensure global uniqueness of URNs, 247 - (where desired) provide a cue for the structure of the identifier. 249 For example, many identifier systems use strings of numbers as 250 identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable 251 that there might be some numbers that are valid identifiers in two 252 different established identifier systems. Using different 253 designators for the two collections (and making these designators an 254 intrinsic syntactic part of URNs) ensures that no two URNs will be 255 the same for different resources (since each collection is required 256 to uniquely assign each identifier). 258 The development of an identifier structure, and thereby a collection 259 of identifiers, is a process that is inherently dependent on the 260 requirements of the community defining the identifier, how they will 261 be assigned, and the uses to which they will be put. All of these 262 issues are specific to the individual community seeking to define a 263 namespace (e.g., publishing community, association of booksellers, 264 protocol developers, technology-specific vendor groups, etc.); they 265 are beyond the scope of the IETF URN work. 267 If a namespace contains structured resources, per RFC 2141bis 268 [I-D.ietf-urnbis-rfc2141bis-urn] the designers of a related URN 269 Namespace and the implementers of the related resolution systems have 270 available three options for the Namespace to support identification 271 and resolution of component resources: 273 a. A Namespace can choose to assign individual identifiers 274 (Namespace Specific String, NSS) to some or all components of a 275 structured resource that is also named by the identifier system. 276 This method is independent of the Internet media types the 277 resolution system(s) for the Namespace can provide. This is the 278 preferred method. However, there may be rules for a pre-existing 279 identifier system (that is going to be made accessible via URNs) 280 and objectives for the NSS format desired that effectively 281 prohibit such identifier assignments; in such cases, the 282 Namespace designers cannot adopt this method. 284 b. A Namespace can choose to provide a resolution system that 285 interprets the 'component' ("c=") directive that can be 286 incorporated in the part of URI references to URNs (see 287 [I-D.ietf-urnbis-rfc2141bis-urn]). This way, only the basic 288 resources are assigned an NSS -- which will simplify the 289 identifier assignment/registration processes/systems for the 290 namespace, or even be dictated by existing processes/systems -- 291 and the URN resolvers for the Namespace can make use of 292 additional information captured from the owners of the individual 293 resources (in any way that is proper for the namespace). This 294 method is independent of the Internet media types that will be 295 used to return the URN resolution results for such Namespace, and 296 as such allows for stable assigned names yet a flexible, perhaps 297 evolving choice of media types provided by the resolution 298 system(s). 300 c. A Namespace that tightly controls the media types provided by 301 particular resolution services might specify how resolution 302 clients can make use of identifiers contained in URI 303 references to URNs of that Namespace (see 304 [I-D.ietf-urnbis-rfc2141bis-urn]) to pick a component resource 305 from the media returned by the URN service. Since per STD 66 306 [RFC3986] identifiers of URIs are evaluated at the 307 client side in a manner specific to each media type (if 308 applicable at all), this method depends on the specific 309 capabilities of the media types used. 311 Namespaces specified prior to RFC 2141bis are constricted to method 312 a. Future Namespace definitions MUST document the methods applicable 313 to it and available via its resolvers. 315 This document outlines the processes by which a collection of 316 identifiers satisfying certain constraints (uniqueness of assignment, 317 etc.) can become a bona fide URN Namespace by obtaining a NID. In a 318 nutshell, a template for the definition of the Namespace is completed 319 for deposit with IANA, and a NID is assigned. The details of the 320 process and possibilities for NID strings are outlined below. 322 3. URN Namespace (Registration) Types 324 There are three categories (types) of URN Namespaces defined here, 325 distinguished by expected level of service and required procedures 326 for registration. Registration processes for each of these Namespace 327 types are given in Section 4. In both this Section and Section 4 328 these categories are ordered by increasing relevance/importance for 329 the Internet and, accordingly, increasing strenght of requirements 330 for the definition and registration processes. 332 3.1. Experimental Namespaces 334 These are not explicitly registered with IANA. 336 No provision is made for avoiding collision of experimental NIDs; 337 they are intended for use within internal or limited experimental 338 contexts. However, as described below in Section 4.1, these are 339 designated by a specific form of the NID to allow differentiation 340 (without preexisting knowledge of details) from the other URN 341 Namespace types. 343 3.2. Informal Namespaces 345 These are fully fledged URN Namespaces, with all the rights and 346 requirements associated thereto. Informal Namespaces can be 347 registered in global registration services. They are required to 348 uphold the general principles of a well-managed URN Namespace -- 349 providing persistent identification of resources and unique 350 assignment of identifier strings. Informal and Formal Namespaces 351 (described below) differ in the NID assignment. IANA will assign to 352 registered Informal Namespaces a simply structured, alphanumeric, 353 ordinal NID (following a pattern defined in Section 4.2 below), per 354 the process outlined in Section 4. 356 3.3. Formal Namespaces 358 A Formal Namespace may be requested, and IETF review sought, in cases 359 where the publication of the NID proposal and the underlying 360 namespace will provide benefit to some subset of users on the 361 Internet. That is, a formal NID proposal, if accepted, must be 362 functional on and with the global Internet, not limited to users in 363 communities or networks not connected to the Internet. For example, 364 assume a NID is requested that is meant for naming of physics 365 research material. If that NID request required that the user use a 366 proprietary network or service that was not at all open to the 367 general Internet user, then it would make a poor request for a formal 368 NID. The intent is that, while the community of those who may 369 actively use the names assigned within that NID may be small (but no 370 less important), the potential use of names within that NID is open 371 to any user on the Internet. 373 It is however expected that Formal NIDs may be applied to Namespaces 374 where some aspects are not fully open. For example, a Namespace may 375 make use of a fee-based, privately managed, or proprietary registry 376 for assignment of URNs in the Namespace, but it may still provide 377 benefit to some Internet users if the services associated with it 378 have openly published access protocols. 380 In addition to the basic registration information defined in the 381 registration template (in Appendix A), a Formal Namespace request 382 must be accompanied by documented considerations of the need for a 383 new Namespace and of the benefit for the Internet community from 384 formally establishing the proposed URN Namespace -- see Sections 385 4.4.1 and 4.4.2 below. 387 Additionally, since the goal of URNs is to provide persistent 388 identification, careful consideration must be given to the longevity 389 and maintainability of the URN Namespace. The collective experience 390 of the IETF community contains a wealth of information on technical 391 factors that will prevent longevity of identification. Thus, the 392 IESG may elect not to accept a proposed Namespace registration if the 393 IETF community consensus is that the registration document contains 394 technical flaws that will prevent (or seriously impair the 395 possibility of) persistent identification, and that it therefore 396 should not be published as an RFC. 398 In addition to the technical aspects of the Namespace and its 399 resolution, consideration should be given to the following 400 organizatorial aspects: 402 - the organization maintaining the URN Namespace should credibly 403 demonstrate stability and the ability to maintain the URN 404 Namespace for a long time, and/or it should be clear how the 405 Namespace can continue to be usable/useful if the organization 406 ceases to be able to foster it; 408 - the organization(s) assigning URNs within the URN Namespace should 409 demonstrate ability and competency in name assignment; this should 410 improve the likelihood of persistence (e.g., to minimize the 411 likelihood of conflicts); 413 - the organization(s) assigning URNs within the URN Namespace need 414 to be committed to honor the scope, rules, and regulations 415 outlined in its registration document and the documents defining 416 the underlying namespace and covering its identifier assignment 417 and maintenance procedures (if any), and the organization 418 maintaining the URN Namespace needs to have procedures in force 419 that aim at ensuring this adherance at a very high confidence 420 level; and 422 - the involved organization(s) need to commit to not re-assign 423 existing names; old names MUST continue to be valid, even if the 424 owners or assignees of those names are no longer members or 425 customers of such organization; this does not mean that there 426 needs to be resolution of such names, but that they must not 427 resolve such names to false or stale information and that they 428 must not be reassigned. 430 If the underlying namespace is based on an established standard, the 431 standards body or the organization(s) in charge with the maintenance 432 of the namespace should be involved in the process, either by 433 performing the registration on their own, or by supporting the action 434 of the registrant and asserting support of the registration document. 436 These aspects, though hard to quantify objectively, should be 437 considered by organizations/people considering the development of a 438 Formal URN Namespace, and they will be kept in mind when evaluating 439 the technical merits of any proposed Formal URN Namespace. The kind 440 of mandate upon which the organization aims to undertake this 441 activity might give a strong indication for this evaluation, because 442 it likely mirrors the trust that other parties (for instance states, 443 international treaty organizations, professionals' associations, 444 etc.) put on the organization. 446 4. URN Namespace Registry: Processes for Registration and Update 448 Different levels of disclosure are expected/defined for Namespaces. 449 According to the level of open-forum discussion surrounding the 450 disclosure, a URN Namespace may be assigned an identifier by IANA or 451 may request a particular identifier. 453 The IANA Considerations Guidelines document (BCP 26 [RFC5226]) 454 suggests the need to specify update mechanisms for registrations -- 455 who is given the authority to do so, from time to time, and what are 456 the processes. Since URNs are meant to be persistently useful, few 457 (if any) changes should be made to the structural interpretation of 458 URN strings (e.g., adding or removing rules for lexical equivalence 459 that might affect the interpretation of URN IDs already assigned). 460 However, it may be important to introduce clarifications, expand the 461 list of authorized URN assigners, etc., over the natural course of a 462 Namespace's lifetime. Specific processes are outlined below. 464 The official list of registered URN Namespaces is currently 465 maintained at [IANA-URN]. The registry is subdivided into two sub- 466 registries, one for "Formal URN Namespaces" and one for "Informal URN 467 Namespaces", and each entry there links to a stable repository of the 468 registration document or (an escrow copy of) the filled-out 469 registration template. 471 The registration and maintenance procedures vary between the 472 Namespace types defined in Section 3. The process generally makes 473 use of the urn-nid@ietf.org discussion list, where, under the 474 auspices of the designated expert(s), volunteering experts and other 475 interested parties review URN Namespace proposals. 477 NOTE: The nominal review period on that list (repeatedly quoted 478 below) is specified in this document as four weeks. This is an 479 upper limit intended to grant the experts following the list 480 sufficient headroom and flexibility. The designated expert(s) may 481 always come to a conclusion earlier, based on personal judgement, 482 observation of feedback on the list, and the precedents of a 483 submission. 485 Registrations may be revised by updating the Namespace definition 486 document using the same process as used for initial registrations, 487 including the circulation of the draft form of the revised Namespace 488 definition document on the urn-nid discussion list. 490 4.1. Experimental Namespaces: No Registration 492 The NIDs of Experimental Namespaces (Section 3.1) are not explicitly 493 registered with IANA. They SHOULD take the form: 495 X- 497 where is a string of up to 30 characters, consisting solely of 498 letters, decimal digits, and hyphen ("-") characters, as specified by 499 the NID syntax specification in Section 2.1 of RFC 2141bis 500 [I-D.ietf-urnbis-rfc2141bis-urn]. 502 No provision is made for avoiding collision of experimental NIDs; 503 they are intended for use within internal or limited experimental 504 contexts exclusively. 506 NOTE: The above form is no more considered MANDATORY, in order to 507 accommodate experience and demonstrated evidence that, under 508 specific circumstances, experimental prototype systems have to 509 create and assign identifiers that the interested community 510 perceives are infeasible to be changed once the Namespace gets 511 formally registered. However, it is still RECOMMENDED to prefix 512 eventually targeted NIDs by "X-" during experiments and tests. 514 As there is no registration, no registration/maintenance procedures 515 are needed. 517 Usage of Experimental URN Namespaces MUST be short-lived and whithin 518 a private scope; it MUST NOT be disclosed to the Internet at large, 519 e.g., by distribution of software versions that make use of such. 521 4.2. Informal Namespaces 523 The NIDs of Informal Namespaces are synthesized by the IANA using an 524 assigned sequence number (ordinal) and registered in their own sub- 525 registry, as indicated in Section 4; they take the format: 527 urn- 529 where is the decimal representation of a natural number, 530 with no leading zeroes. This sequence number is assigned by the IANA 531 on a First-Come-First-Served [RFC5226] basis to registration requests 532 for Informal Namespaces. 534 Registrants should send a copy of the registration template (as shown 535 in Appendix A), duly completed, to the urn-nid@ietf.org mailing list 536 for review and allow for a four-week discussion period for clarifying 537 the expression of the registration information and suggestions for 538 technical improvements to the Namespace proposal. 540 After suggestions for clarification of the registration information 541 have been incorporated, the template may be submitted for assignment 542 of an Informal NID by email to iana@iana.org . 544 4.3. Formal Namespaces 546 Formal NIDs are assigned via IETF Review and Expert Review, as 547 defined in BCP 26 [RFC5226]. 549 "IETF Review" means that the Formal NID application is made via 550 submission to the IETF of an Internet-Draft that contains the 551 Namespace definition and targets publication as an RFC of 552 Informational or Standards-Track category, which needs to be approved 553 by the IESG after performing an IETF Last Call on the document and 554 evaluating review comments. The applicant can be an individual or an 555 IETF working group, in alignment with the designation of the 556 Internet-Draft. The actual choice should be properly considered by 557 applicants, but it is RECOMMENDED that the registration documents for 558 NIDs belonging to an established standard namespace aim at Standards- 559 Track, whereas other applications aim at Informational RFC. 561 Before publication can be requested, however, the draft Namespace 562 specification document must undergo an "Expert Review" process 563 [RFC5226] pursuant to the guidelines written here (as well as 564 standard RFC publication guidelines). The designated expert(s) for 565 URN Namespace registrations are nominated by the IESG, and their role 566 adheres to the guidelines in BCP 26, unless specified otherwise 567 below. The template defined in Appendix A SHOULD be included as part 568 of an RFC-to-be defining some other aspect(s) of the Namespace, but 569 it MAY be put forward as a Namespace definition document in its own 570 right. The proposed template (including a pointer to a readily 571 available copy of the registration document) should be sent to the 572 urn-nid@ietf.org mailing list for review. This list is monitored by 573 the designated expert(s). The applicant has to allow for a four-week 574 discussion period for clarifying the expression of the registration 575 information, and SHOULD improve the Namespace document and/or 576 registration template based on the comments received, under the 577 guidance of the designated expert(s). Multiple iterations can be 578 performed, before the proposal is accepted and the document can be 579 forwarded to the IESG for review at large. the 581 Working groups generally SHOULD seek early expert review for a 582 Namespace definition document, and individual applicants are also 583 advised to seek expert comments early enough. The aforementioned 584 list can be contacted for informal advice at any stage. The document 585 writeup needed for submitting a working group document to the IESG 586 requires that all applicable Expert Review processes have been 587 followed; this applies to the process described here. 589 NIDs for Formal URN Namespaces MUST NOT have the forms indicated in 590 the preceding two sections for the other two Namespace types. The 591 proposed NID string MUST conform with the syntax rule in 592 Section 2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and it 593 MUST adhere to the following additional constraints: 595 - not be an already-registered NID; 597 - not start with "X-" (see Section 4.1 above); 599 - not start with "urn-" (see Section 4.2 above); 601 - not start with "xy-", where xy is any combination of 2 ASCII 602 letters (see NOTE below); 604 - not be equal to or start with "example" (see NOTE below); 606 - be more than 2 characters long. 608 NOTE: All two-letter combinations as well as two-letter combinations 609 followed by "-" and any sequence of valid NID characters are 610 reserved for potential future use as countrycode-based NIDs for 611 eventual national registrations of URN Namespaces. The definition 612 and scoping of rules for allocation of responsibility for such 613 Namespaces is beyond the scope of this document. 614 Further, to avoid confusion, "urn" is not allowed as an NID 615 string; To allow neutral example URNs in code and documentation, 616 NID strings starting with "example" are set aside for use in 617 documentation; IANA has permanently reserved these string to 618 prohibit assignment. 620 Applicants, in concert with the designated expert(s), should ensure 621 that the sought NID strings are "proper" for the designated purpose, 622 according to common sense (and applicable legal rules). 624 4.4. Registration Documents 626 The following subsections describe essential, MANDATORY parts of URN 627 Namespace registration documents (beyond the registration template 628 specified in Appendix A), which will be focal in the Expert Review 629 process and IETF Review. 631 4.4.1. Namespace Considerations in Registration Documents 633 The Namespace definition document MUST include a section with 634 "Namespace Considerations" that outlines the perceived need for a new 635 namespace (i.e., where existing namespaces fall short of the 636 proposer's requirements). Part of the expected elaborations need to 637 be the arguments why other identifier systems, in particular a 638 specific/new URI Scheme would not be suitable for the intended 639 purpose. 641 The basis for the expected reasoning can be laid by collecting and 642 analyzing the requirements for the new namespace or, if an existing 643 identifier system shall be incorporated into the URN system, from 644 studying applicable stable (and preferably readily available) 645 documents related to that identifier system that can be quoted. 646 Particular insight to properly decide whether a new namespace is 647 needed can be gained from preparing the explanations to be filled 648 into clauses of the Registration template in Appendix A related to: 650 - kind of resources to be named; 652 - URN assignment procedures; 654 - URN resolution/delegation; 656 - type of services to be supported. 658 NOTE: It is expected that more than one Namespace may serve the same 659 "functional" purpose; the intent of the "Namespace Considerations" 660 section is to provide a record of the proposer's "due diligence" in 661 exploring existing possibilities, for the IESG's consideration. 663 If the need for a new namespace can be demonstrated, it needs to be 664 checked whether the requirements and properties of the desired 665 identifer system is properly matched to the basic assumptions and 666 requirements for URNs -- cf. the Introduction of RFC 2141bis 667 [I-D.ietf-urnbis-rfc2141bis-urn]. If that is not obvious, it needs 668 to be explained in detail in the Namespace Considerations. 670 See the trailing NOTE of the next Section for exceptional conditions 671 that might allow to waive the need for presenting the above-described 672 rationale in a standalone section of a particular Namespace 673 definition document. 675 4.4.2. Community Considerations in Registration Documents 677 The Namespace definition document MUST also include a section with 678 "Community Considerations" that indicates the dimensions upon which 679 the proposer expects its community to be able to benefit by 680 publication of this Namespace, as well as how a general Internet user 681 will be able to use the space if they care to do so. 683 Again, insight into arguments needed here might be possible to be 684 gained by preparing the material to be filled into clauses of the 685 Registration template in Appendix A related to: 687 - (open) assignment and use of identifiers within the Namespace; 689 - open operation of resolution servers for the Namespace 690 (server); 692 - creation of software that can meaningfully resolve and access 693 services for the Namespace (client). 695 NOTE: It is acknowledged that occasionally the Namespace 696 Considerations and Community Considerations are closely 697 intertwined; e.g., this has has been observed in the context of 698 legacy identifier systems to be embedded into a URN Namespace. 699 If such circumstances can be demonstrated, the Expert Review 700 process can waive the requirement to present the two independent 701 sections of a Namespace defintition document described in this and 702 the preceding Section and concede to the applicant(s) to combine 703 the content required for those two mandatory sections into a 704 single "Namespace and Community Considerations" section. 706 4.4.3. Security Considerations in Registration Documents 708 According to the general procurements for RFCs, URN Namespace 709 definition documents must include a "Security Considerations" section 710 (cf. BCP 72 [RFC3552]). That section has to identify the security 711 considerations specific to the subject URN Namespace. If the subject 712 URN Namespace is based on an underlying namespace, the registration 713 can include substantive security considerations described in 714 specifications related to that particular namespace by reference to 715 these documents. For general security considerations regarding URN 716 usage (and more generally, URI usage), for the sake of clarity and 717 brevity, it should refer to the Security Considerations in STD 63 718 [RFC3986] and in the URN Syntax document 719 [I-D.ietf-urnbis-rfc2141bis-urn]. 721 4.4.4. IANA Considerations in Registration Documents 723 According to the general procurements for RFCs, URN Namespace 724 definitions documents must include an "IANA Considerations" section 725 (cf. BCP 26 [RFC5226]). That section has to indicate that the 726 document includes a URN Namespace registration template that is to be 727 entered into the IANA registry of either Informal or Formal URN 728 Namespaces. 730 The completed Namespace registration template included in (or 731 referred by) the IANA Considerations section in the published form of 732 Registration documents will provide the particular, unique NID string 733 that has been assigned, in case of formal Namespaces, by the 734 Standards/Protocol Action of the IESG that approved the publication 735 of the registration document as an RFC, or, in case of informal 736 Namespaces, by the IANA after successful Expert Review. As specified 737 above in Section 4.3, draft registration documents for formal 738 Namespaces usually carry the NID suggested by the registrant (subject 739 to the expert review process); otherwise the NID will be assigned by 740 the IANA. RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] specifies 741 that NID strings are ASCII strings that are interpreted in a case- 742 insensitive manner, but the NID string SHALL be registered in the 743 capitalization form preferred by the registrant. Additional 744 syntactical constraints for NIDs are specified (per Namespace type) 745 in Sections 4.2 and 4.3 above. 747 Applicants and the designated expert(s) have to ensure that the 748 sought NID strings are suitable and proper for the designated purpose 749 and not misleading, according to common sense and applicable legal 750 rules. The IETF Review process gives interested parties the 751 opportunity to rise concerns if they want to challenge proposed 752 strings; the final approval decision still remains with the IESG. 754 To avoid clerical accidents, the IANA Considerations Section in 755 Namespace registration documents should clearly spell out the 756 implications of the registration on the URN Query Parameters 757 registries defined in RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], 758 if any. Namespace registration documents have to specify the use or 759 non-use of query instructions (by registered keyword) by the 760 resolvers related to the respective namespace. Additionally, they 761 can optionally define new query keywords (of specific scope) for that 762 Namespace or an entire group of Namespaces. 764 5. Security Considerations 766 This document largely focuses on providing mechanisms for the 767 declaration of public information. Nominally, these declarations 768 should be of relatively low security profile; however, there is 769 always the danger of "spoofing" and providing mis-information. 770 Information in these declarations should be taken as advisory. 772 6. IANA Considerations 774 This document outlines the processes for registering URN Namespaces, 775 and has implications for the IANA in terms of registries to be 776 maintained, as previously defined in RFC 3406 [RFC3406]. This 777 document replaces RFC 3406; it contains a revised description for the 778 management of the "Uniform Resource Names (URN) Namespaces" IANA 779 Registry that uses the policy designation terms from BCP 26, RFC 5226 780 [RFC5226], but does not introduce significant changes to the 781 applicable procedures described in Section 4 of this RFC. 783 IANA is asked to update the applicable policy for the registry of 784 Formal URN Namespaces in the list of protocol parameter registries at 785 http://www.iana.org/protocols/, replacing "IETF Consensus Action" by 786 "IETF Review after expert review on the urn-nid discussion list 787 (designated expert: ...)". 789 In both sub-registries of [IANA-URN] (for Formal and Informal 790 Namespaces), the registry column headings "URN Namespaces" should be 791 changed to "Namespace ID", and "Value" to "Ordinal"; preferably these 792 columns should be swapped in both sub-registries. 793 [[ DISCUSS: Do we actually need these numerical columns at all? ]] 795 IANA is asked to add to both sub-registries of [IANA-URN] a new third 796 column entitled "Kind of named resources"; entries into this column 797 shall be captured from the respective clause of received registration 798 templates conforming to Appendix A. For legacy entries, the original 799 registrants are encouraged to provide proper short descriptions to 800 IANA. 801 [[ DISCUSS: Shall *we* provide sensical values for legacy entries 802 and/or actively poll the Namespace owners instead? ]] 804 All references there to the predecessor, [RFC3406], should be 805 replaced by references to this document. 806 We would appreciate a reorganization of the Registry web page to make 807 the registration templates for Informal URN Namespaces directly 808 linked from the main page; this would make the page /assignments/ 809 urn-informal.htm page dispensable (for persistency's sake, the web 810 server should redirect requests to the /assignments/urn-namespaces 811 page. 813 Section 4 of this document outlines the general procedures. Sections 814 4.2 and 4.3 above describe the syntax rules for NIDs to which the 815 registry needs to obey. 817 As pointed out in Section 4.3 above and in RFC 2141bis 818 [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is permanently 819 reserved and MUST NOT be assigned as an NID. All strings starting 820 with "example" are permanently reserved for use in code and 821 documentation, and hence MUST NOT be assigned as an NID. 823 In conformance with BCP 100 [RFC4020], in all cases of new Namespace 824 registration proposals, the IANA should provisionally assign the 825 appropriate NID (informal or formal), as described throughout the 826 body of this memo, once an IESG-designated expert has confirmed that 827 the requisite registration process steps have been completed. These 828 registrations become permanent and can be made publicly available 829 once the registration document has been approved by the IESG for 830 publications as a Standards-Track or Informational RFC. 832 Once a Namespace registration template has been accepted for IANA 833 processing, the IANA is expected to also update the "Supported by" 834 lists in the registry specified by Section 9.2.1 of RFC 2141bis 835 [I-D.ietf-urnbis-rfc2141bis-urn], based on the information supplied 836 in the "Usage of query instructions" clause of the registration 837 template. 839 7. Acknowledgements 841 This document is heavily based on RFC 3406 (and thereby its 842 predecessor, RFC 2611), authored by Leslie Daigle, Dirk-Willem van 843 Gulik, Renato Ianella, and Patrik Faltstrom, whose work is cordially 844 acknowledged. 846 This document also been inspired by other recent documents that have 847 updated important IANA registries, and the countless authors and 848 contributors to these efforts are acknowledged anonymously. 850 Several individuals in the URNbis working group have participated in 851 the detailed discussion of this memo. Particular thanks for detailed 852 review comments and text suggestions go to (in alphabetical order) 853 Leslie Daigle Juha Hakala, Subramanian Moonesamy. Peter Saint-Andre, 854 Lars Svensson, and Mykyta Yevstifeyev. 856 8. References 858 8.1. Normative References 860 [I-D.ietf-urnbis-rfc2141bis-urn] 861 Hoenes, A., "Uniform Resource Name (URN) Syntax", 862 draft-ietf-urnbis-rfc2141bis-urn-03 (work in progress), 863 October 2012. 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 868 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 869 Resource Identifier (URI): Generic Syntax", STD 66, 870 RFC 3986, January 2005. 872 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 873 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 874 May 2008. 876 8.2. Informative References 878 [IANA] IANA, "The Internet Assigned Numbers Authority", 879 . 881 [IANA-URN] 882 IANA, "Uniform Resource Names (URN) Namespace Registry", 883 . 885 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 886 Name Resolution", RFC 2276, January 1998. 888 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 889 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 890 June 1999. 892 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 893 IETF URI Planning Interest Group: Uniform Resource 894 Identifiers (URIs), URLs, and Uniform Resource Names 895 (URNs): Clarifications and Recommendations", RFC 3305, 896 August 2002. 898 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 899 Internet: Timestamps", RFC 3339, July 2002. 901 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 902 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 904 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 905 Part Five: URI.ARPA Assignment Procedures", BCP 65, 906 RFC 3405, October 2002. 908 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 909 "Uniform Resource Names (URN) Namespace Definition 910 Mechanisms", BCP 66, RFC 3406, October 2002. 912 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 913 Text on Security Considerations", BCP 72, RFC 3552, 914 July 2003. 916 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 917 Standards Track Code Points", BCP 100, RFC 4020, 918 February 2005. 920 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 921 Specifications: ABNF", STD 68, RFC 5234, January 2008. 923 Appendix A. URN Namespace Definition Template 925 Definition of a URN Namespace is accomplished by completing the 926 following information template. It is provided in two versions; the 927 annotated template with comments explaining what should go into the 928 filled-out template is shown in Appendix A.1 and the plain template 929 that can be used as a starting point for filling in the required 930 information via plaintext editing is shown in Appendix A.2. 931 To further the application of the template, both forms will be made 932 available in xml2rfc form on the IETF Tools and/or IANA web site [[ 933 to be decided ]]. 934 In case of (unintended) deviations, Appendix A.1 takes precedence 935 over Appendix A.2. 937 Apart from providing a mechanism for disclosing the structure of the 938 URN Namespace, this information is designed to be useful for 940 - entities seeking to have a URN assigned in a Namespace (if 941 applicable) and 943 - entities seeking to provide URN resolvers for a Namespace (if 944 applicable). 946 This is particularly important for communities evaluating the 947 possibility of using a portion of an existing URN Namespace rather 948 than creating their own. 950 Applications for Formal URN Namespaces must also document "Namespace 951 Considerations", "Community Considerations", "Security 952 Considerations", and "IANA Considerations", as described in 953 Section 4.4. 955 A.1. Annotated URN Namespace Definition Template 957 Information in the template is as follows (text in curly braces 958 describes the expected content and should be removed from filled-in 959 templates): 961 Namespace ID: 963 { If request is for an Informal NID, indicate so; the number will 964 be assigned by IANA. In the case of a Formal NID registration, 965 regularly a particular NID string will be requested. } 967 Kind of named resources: 969 { Short description of what resources are named under this NID. } 971 Registration Information: 973 { This is information to identify the particular version of 974 registration information: } 975 - version number: 976 { starting with 1, incrementing by 1 with each new version } 977 - date: 978 { date submitted to the IANA or date of approval of 979 registration document, using the format outlined in "Date and 980 Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD } 982 Declared registrant of the Namespace: 984 - Registering organization: 985 Name: { ... } 986 Address: { ... } 987 - Designated contact person: 988 Name: { ... } 989 { Address: ... 990 (at least one of: Email, Phone, Postal address) } 992 Declaration of syntactic structure of NSS part: 994 { 995 This clause should outline any structural features of identifiers 996 in this Namespace. At the very least, this description may be 997 used to introduce terminology used in other clauses. This 998 structure may also be used for determining realistic caching/ 999 shortcuts approaches; suitable caveats should be provided. If 1000 there are any specific character encoding rules (e.g., which 1001 character should always be used for single-quotes), these should 1002 be listed here. 1004 Answers might include, but are not limited to: 1005 - the structure is opaque (no exposition); 1006 - a regular expression for parsing the identifier into 1007 components, including naming authorities; 1008 - formal syntax of the NSS, preferably in ABNF (STD 68 1009 [RFC5234]). 1010 } 1012 Relevant ancillary documentation: 1014 { 1015 This clause should list any RFCs, standards, or other published 1016 documentation that defines or explains all or part of the 1017 namespace structure. 1019 Answers might include, but are not limited to: 1020 - RFCs that outline the syntax of the namespace; 1021 - other documents of the defining community (e.g., ISO) that 1022 outline the syntax of the identifiers in the namespace; 1023 - explanatory material that introduces the namespace. 1024 } 1026 Conformance with URN Syntax: 1028 { 1029 This clause should outline any special considerations required for 1030 conforming with the URN syntax. This is particularly applicable 1031 in the case of legacy naming systems that are used in the context 1032 of URNs. 1034 For example, if a namespace is used in contexts other than URNs, 1035 it may make use of characters that are reserved in the URN syntax. 1037 This clause should flag any such characters, and outline necessary 1038 mappings to conform to URN syntax. Normally, this will be handled 1039 by percent-encoding the symbol. 1040 } 1042 Rules for Lexical Equivalence of NSS part: 1044 { 1045 If there are particular algorithms for determining equivalence 1046 between two identifiers in the underlying namespace (and hence, in 1047 the URN string itself), rules can be provided here. 1049 Some examples include: 1050 - equivalence between hyphenated and non-hyphenated groupings in 1051 the identifier string; 1052 - equivalence between single-quotes and double-quotes; 1053 - namespace-defined equivalences between specific characters, 1054 such as "character X with or without diacritic marks". 1056 Note that these are not normative statements for any kind of best 1057 practice for handling equivalences between characters; they are 1058 statements limited to reflecting the namespace's own rules. 1060 However, namespaces that seek to provide higher-level lexical 1061 equivalence rules should preferably make use of established and 1062 standardized normalization procedures (like the methods leading to 1063 the various Unicode Normalization Forms, which would have to be 1064 applied before UTF-8 encoding) and not invent their own "magic"; 1065 in practice, the utility of such things is likely to be limited 1066 since test of lexical equivalence is a typical client-side pre- 1067 screening operation performed by applications that try to remain 1068 as general as possible and typically will not have built-in, NID- 1069 specific knowledge -- ultimately, functional (or semantical) 1070 equivalence of URNs can only be decided in the NID-specific 1071 assignment/resolution systems, and their internal rules can be 1072 handled much more flexibly than more complicated, nailed-down 1073 lexical equivalence rules that are unlikely to be implemented at 1074 large. 1075 } 1077 Usage of query instructions: 1079 { 1080 Either say "not applicable" or describe the query instructions 1081 (keywords and associated values) supported by the resolvers for 1082 this Namespace (cf. Sections 2.5 and 9.2 of RFC 2141bis). 1083 Is the "s" keyword supported to select component resources? 1084 If yes: Which registered services can be selected with it? What 1085 is the default/fallback service if "s=" is not given or if the 1086 value specified for it is unknown/unsupported? 1087 For which services is the "c" keyword supported (if any)? 1088 If affirmative, specify the values that can be used with it and 1089 the behavior if an unrecognized / inapplicable value is used. 1090 } 1092 Usage of fragment part: 1094 { 1095 Either say "not applicable" if parts cannot sensically 1096 be used with URI references to URNs of this NID, 1097 or specify (by URN service supported) which media types that 1098 support fragment identifiers will be returned by the resolvers for 1099 this Namespace, and the designators that will be 1100 applicable. (Cf. Section 2.4 of RFC 2141bis.) 1101 } 1103 Identifier uniqueness considerations: 1105 { 1106 This clause should address the requirement that URN identifiers be 1107 assigned uniquely -- they are assigned to at most one resource, 1108 and are not reassigned. 1110 (Note that the definition of "resource" is fairly broad; for 1111 example, information on "Today's Weather" might be considered a 1112 single resource, although the content is dynamic.) 1114 Possible answers include, but are not limited to: 1116 - exposition of the structure of the identifiers, and 1117 partitioning of the space of identifiers amongst assignment 1118 authorities that are individually responsible for respecting 1119 uniqueness rules; 1120 - identifiers are assigned sequentially; 1121 - information is withheld; that is, the namespace is opaque. 1122 } 1124 Identifier persistence considerations: 1126 { 1127 Although non-reassignment of URN identifiers ensures that a URN 1128 will persist in identifying a particular resource even after the 1129 "lifetime of the resource", some consideration should be given to 1130 the persistence of the usability of the URN. This is particularly 1131 important in the case of URN Namespaces providing global 1132 resolution. 1134 Possible answers include, but are not limited to: 1135 - quality of service considerations. 1136 } 1138 Process of identifier assignment: 1140 { 1141 This clause should detail the mechanisms and/or authorities for 1142 assigning URNs to resources. It should make clear whether 1143 assignment is completely open, or if limited, how to become an 1144 assigner of identifiers, and/or get one assigned by existing 1145 assignment authorities. 1147 Answers could include, but are not limited to: 1148 - assignment is completely open, following a particular 1149 algorithm; 1150 - assignment is delegated to authorities recognized by a 1151 particular organization (e.g., the Digital Object Identifier 1152 Foundation controls the DOI assignment space and its 1153 delegation); 1154 - assignment is completely closed (e.g., for a private 1155 organization). 1156 } 1158 Process for identifier resolution: 1160 { 1161 Which URN resolution services will be supported? 1162 What is the default service provided by the resolvers for this 1163 Namespace? 1164 (The "Usage of query instructions:" clause above only reports 1165 which services can be selected by the "s" query instruction, if 1166 any.) 1167 } 1168 { 1169 If a Namespace is intended to be accessible for global resolution, 1170 it must be registered in an RDS (Resolution Discovery System, see 1171 RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]). 1172 Resolution then proceeds according to standard URI resolution 1173 processes, and the mechanisms of the RDS. What this clause should 1174 outline is the requirements for becoming a recognized resolver of 1175 URNs in this Namespace (and being so listed in the RDS registry). 1177 Answers may include, but are not limited to: 1178 - the Namespace is not listed with an RDS, this is not relevant; 1179 - resolution mirroring is completely open, with a mechanism for 1180 updating an appropriate RDS; 1181 - resolution is controlled by entities to which assignment has 1182 been delegated. 1183 } 1185 Validation mechanism: 1187 { 1188 Apart from attempting resolution of a URN, a URN Namespace may 1189 provide mechanisms for "validating" a URN -- i.e., determining 1190 whether a given string is currently a validly-assigned URN. There 1191 are 2 issues here: 1) users should not "guess" URNs in a 1192 Namespace; 2) when the URN Namespace is based on an existing 1193 identifier system, it may not be the case that all the existing 1194 identifiers are assigned on Day 0. The reasonable expectation is 1195 that the resource associated with each resulting URN is somehow 1196 related to the thing identified by the original identifier system, 1197 but those resources may not exist for each original identifier. 1198 For example, even if a telephone number-based URN Namespace was 1199 created, it is not clear that all telephone numbers would 1200 immediately become "valid" URNs, that could be resolved using 1201 whatever mechanisms are described as part of the Namespace 1202 registration. 1204 Validation mechanisms might be: 1205 - a syntax grammar; 1206 - an on-line service; 1207 - an off-line service. 1208 } 1210 Scope: 1212 { 1213 This clause should outline the scope of the use of the identifiers 1214 in this namespace, i.e. the precise kind of resources to which the 1215 URNs are assigned. Apart from considerations of private vs. 1216 public namespaces, this clause is critical in evaluating the 1217 applicability of a requested NID. For example, a namespace 1218 claiming to deal with "social security numbers" should have a 1219 global scope and address all social security number structures 1220 (unlikely). On the other hand, at a national level, it is 1221 reasonable to propose a URN Namespace for "this nation's social 1222 security numbers". 1223 } 1225 A.2. Plain URN Namespace Definition Template (Informative) 1227 Namespace ID: ... 1229 Kind of named resources: ... 1231 Registration Information: 1233 - version number: _ 1234 - date: yyyy-mm-dd 1236 Declared registrant of the Namespace: 1238 - Registering organization: 1239 Name: ... 1240 Address: ... 1241 - Designated contact person: 1242 Name: ... 1243 { Address: ... } 1245 Declaration of syntactic structure of NSS part: 1247 ... 1249 Relevant ancillary documentation: 1251 ... 1253 Conformance with URN Syntax: 1255 ... 1257 Rules for Lexical Equivalence of NSS part: 1259 ... 1261 Identifier uniqueness considerations: 1263 ... 1265 .. [[ to be completed in next draft rev if this idea is accepted ]] 1267 ... 1269 Appendix B. Summary of Registration Steps (Informative) 1271 The key steps for registration of Informal or Formal Namespaces 1272 typically play out as follows: 1274 A) Informal NID: 1276 1. Complete the registration template. This may be done as part 1277 of an Internet-Draft. 1279 2. Communicate the registration template to urn-nid@ietf.org for 1280 technical review -- as an email with a pointer to the 1281 submitted I-D or inline text containing the template. 1283 3. Update the registration template (and/or document) as 1284 necessary from comments, and repeat steps 2 and 3 as 1285 necessary. 1287 4. Once comments have been addressed (and the review period has 1288 expired), send a request to IANA with the revised registration 1289 template. 1291 B) Formal NID: 1293 1. Write an Internet-Draft describing the namespace and include 1294 the registration template, duly completed. Be sure to include 1295 "Namespace Considerations" and "Community Considerations" 1296 sections (or a combined section for these), "Security 1297 Considerations" and "IANA Considerations" sections, as 1298 described in Section 4.4. 1300 2. Submit the Internet-Draft, and send a pointer to the I-D 1301 (perhaps using a copy of the I-D announcement) to 1302 urn-nid@ietf.org in order to solicit technical review. 1304 3. Update the Internet-Draft as necessary from comments, and 1305 repeat steps 2 and 3 as needed. 1307 4. If the Internet-Draft is the product of a working group in the 1308 IETF, follow the usual WG process to forward the document to 1309 the IESG for publication as an RFC. Otherwise, find a 1310 sponsoring Area Director willing to guide the draft through 1311 the IESG. The IESG (or the IETF at large in case an IETF-wide 1312 last call is deemed necessary) may request further changes 1313 (submitted as I-D revisions) and/or direct discussion to 1314 designated working groups, area experts, etc. 1316 5. The IESG evaluation process includes a review by IANA, and if 1317 the IESG approves the document for publication as an RFC, IANA 1318 processing of the document will follow the regular work-flow 1319 between the RFC Editor and IANA. This way, the NID 1320 registration will be made public by IANA when the RFC is 1321 published. 1323 Appendix C. Changes from RFC 3406 (Informative) 1325 C.1. Essential Changes since RFC 3406 1327 [ RFC Editor: please remove the Appendix C.1 headline and all 1328 subsequent subsections of Appendix C starting with Appendix C.2. ] 1330 [[ T.B.D. in next iteration of this memo. ]] 1332 C.2. Changes from RFC 3406 to URNbis WG Draft -00 1334 o Abstract: rewritten entirely; 1336 o Section 1 (Introduction): added historical RFC information; 1338 o Section 1.1 (Requirements Language): added; 1340 o Section 3.1: added Note that challenges the utility of 1341 Experimental Namespaces and raises question of whether formal 1342 "provisional" registrations would be useful; 1344 o Section 4: text expanded and updated; background material added; 1345 added Note to challenge IANA website practices; 1347 o Section 4.2 ff: changed "home" of URN-NID registration discussion 1348 list (it already had been moved to the IETF Secretariat servers); 1350 o Section 4.2: added Note to challenge the 2-week review period; in 1351 current practice, that is almost always exceeded, and some regard 1352 it as too short; 1354 o Section 4.3: largely clarified procedures as they happen in 1355 practice; adapted language for conformance with RFC 5226; use new 1356 home of URN-NID (as mentioned above); the registration template 1357 (Appendix A) now "SHOULD" be used; 1359 o Section 4.3: split off new Section 4.4 on Registration Documents, 1360 because registrants essentially are encouraged to follow these 1361 guidelines for Informal Namespaces as well, as far as practical; 1362 replaced "RFC" by "Registration Document"; Section 4.4 is 1363 subdivided for all mandatory sections; 1365 o Section 4.4.1: made requirements a "MUST"; 1367 o Sections 4.4.1 and 4.4.2: added common Note that challenges the 1368 need to split Namespace and Community Considerations, based on 1369 observed problems in practice to separate the topics, and pointing 1370 to overlap with clauses in the registration template due to 1371 bullets listed that are not so clearly related to the headlines 1372 under which they appear; suggestion is to avoid duplication, place 1373 factual stuff into the template and focus on rationale in these 1374 Considerations, perhaps in a common section; 1376 o Section 4.4.3: added discussion of Security Considerations 1377 section; advice is to focus on namespace-specific considerations 1378 and refer to the SecCons in the "generic" RFCs for the general 1379 issues; 1381 o Section 4.4.4: amended discussion of IANA Considerations section; 1382 this tries to reflect standing practice and codifies that Formal 1383 NIDs are generally proposed by the registrant; added Note that 1384 "urn" is permanently reserved and MUST NOT be assigned as a NID, 1385 to avoid confusion (as also specified in RFC 2141bis draft); wrt 1386 registration maintenance: got rid of wrong reference in RFC 3406 1387 (to RFC 2606); 1389 o Section 6 (IANA Considerations): updated and rephrased description 1390 of the role of this document, including a sketch of the history; 1391 added teat that tries to precisely describe what is expected from 1392 IANA on approval of this draft; added text on procedures and 1393 suggest a provisional assignment practice upon "thumbs-up" of the 1394 IANA Expert to protect prospective registrants from collateral 1395 damage on NID precedence in case the document suffers from delays 1396 unrelated to the registration template before it eventually gets 1397 approved; 1399 o Section 7 (Acknowledgements): added; 1401 o References: Updated and amended references; added pointers to 1402 chartered URNbis work items; removed entirely outdated example 1403 material related to legacy documents; 1405 o Appendix A and B.1: added words on Security Considerations 1406 section; 1408 o Appendix A (Registration Template): clarified role of text 1409 snippets in the Template: hint and commentary now all enclosed in 1410 curly braces, with not that these parts shall be removed when 1411 filling in the tempalte; indicate that Formal NIDs are normally 1412 proposed by registrant; changed date/time ref. from ISO 8601 to 1413 RFC 3339; use inherited term "percent-encoding"; 1415 o Appendix A -- structure: moved formal clauses on Conformance with 1416 URN Syntax and Rules for Lexical Equivalence to vicinity of 1417 namespace specific syntax clause, to which these are closely 1418 related; 1420 o Appendix A -- changes of clauses: the Declaration of syntactic 1421 structure and Rules for Lexical Equivalence clauses now 1422 tentatively have been restricted to the NSS part only; this change 1423 is described in NOTEs and motivated by the observation of repeated 1424 confusion in past and present registration documents, which 1425 hopefully can be avoided (and the job of the Expert and reviewers 1426 made easier) by leaving discussion of the invariate parts that 1427 cannot be re-specified there at the single place where they belong 1428 to: the NID is fully specified in the initial clause, rules for 1429 the NID and the URI scheme name "urn" are inherited from RFC 1430 2141[bis] and RFC 3986, respectively, and hence the new clause 1431 descriptions avoid conflict by taking these components out of 1432 scope of these clauses; 1434 o Appendix B.1 (Example Template): facelifted a bit; concerns with 1435 IESG policy on examples in RFCs raised in a NOTE; 1437 o Appendix B.2 (Registration steps in practice): updated and 1438 clarified description of procedure, in alignment to current 1439 practice; 1441 o Appendix C: removed "Changes from RFC 2611"; added this change 1442 log; 1444 o General: numerous editorial changes and enhancements, following 1445 contemporary RFC style. 1447 C.3. Changes from URNbis WG I-D -00 to -01 1449 Usage of terminology strenghtened. 1451 Clarified role and usage of Experimental Namespaces. 1453 Clarified NID strings for Formal Namespaces. 1455 Added hint that recommends Std. Track RFCs for NID applications based 1456 on established standard namespaces, and Informational for others. 1458 Changed standard review period from 2 to 4 weeks (pending 1459 discussion). 1461 Resolved with IANA: simple, traditional and generic URL used by IANA 1462 for the URN Namespace registry. (Needed to be re-opened in -02!) 1464 Numerous editorial enhancements and fixes. 1466 C.4. Changes from URNbis WG I-D -01 to -02 1468 General text edits based on evaluation of meeting and on-list 1469 comments. 1471 Updated and tightened the organizatorial requirements for Formal 1472 Namespace requests. 1474 Restored additional IANA Considerations -- due to observed defects. 1476 Reserved NID strings "example.*" for documentation (as suggested by 1477 Larry Masinter, Peter Saint-Andre, and Julian Reschke). 1479 Added text on possible "higher level" methods to establish lexical 1480 equivalence of URNs, with the caveats that such things are rather 1481 unlikely to get traction in general-purpose client software. 1483 Removed historical Appendix B.1 (Example Template). 1485 Various editorial enhancements and fixes. 1487 Updated and expanded "Issues" Appendix (below) in preparation of 1488 usage of the IETF Issue Tracker. 1490 C.5. Changes from URNbis WG I-D -02 to -03 1492 Due to the scattered discussion of the previous draft version, the 1493 items below not only list effected changes but also give rationale 1494 for where suggested changes have not been applied. 1496 Document title shortened to better reflect entire purpose of 1497 document. 1499 Abstract: revised and shortened (comments from SM). 1501 Introduction: 1502 Rephrased 1st para to put emphasis on name binding property (derived 1503 from list discussion on related topic, Keith Moore et al.). 1504 Amended / modified text to better reflect the intended audience of 1505 the memo and its contents, and to accommodate the evolution of the 1506 rfc2141bis I-D. 1507 Wordsmithing Assumption: "_well_ recognized" (Lars Svensson). 1508 Contrary to a proposal (PSA), the draft text keeps the Assumptions 1509 separate from the consequences/conclusions drawn from these; the 1510 registration process is what is to be followed to maintain the 1511 assumption, not the 2nd assumption itself. 1512 Text reworked based on comments (SM, PSA, et al.). 1513 The single paragraph with a historical perspective on previous 1514 documents is deemed rather helpful for the intended audience (note 1515 the confusing artifact caused by RFC Editor mistake, giving the 1516 replacement of a BCP a different BCP number!), and it serves to 1517 capture important motivations for the document revision effort; 1518 therefore, it is kept in the draft. 1519 The pargraph describing the purpose of the document has been 1520 rephrased. It isn't barely about an IANA procedure, it is also about 1521 what prospective registrants are well advised to consider before 1522 deciding on a new Namespace and the processes they have to implement, 1523 and finally capturing the results in a URN Namespace registration 1524 document. 1526 Section 2: 1527 Amended by text describing the 3 methods available to Namespace 1528 designers / stakeholdes to make component resources of structured 1529 resources identifiable/accessible. 1530 Some existing text reworded based on comments (SM et al.). 1531 It has been argued that text on URN Namespaces in s2 would better be 1532 placed into the rfc2141bis document, but on the other hand, it has 1533 been argued that text introducing and discussing Namespace properties 1534 from rfc2141bis should better be placed into this memo. To keep both 1535 documents as much self-contained as practical, text on URN Namespaces 1536 of specific interest to prospective stakeholders of URN Namespaces 1537 and authors of registration documents has been kept in s2 of this 1538 draft, and new such material has been added there. (The rfc2141bis 1539 draft now points to this.) 1541 s3.3: Reworded "benefit" clause to clarify distinction between the 1542 community interested in a new Namespace and the Internet community at 1543 large (corollary to comments on and revision of s4.4.2.). 1545 s4: (dealing with comments from SM, PSA) 1546 The justification for the need to consider and specify registration 1547 maintenance procedures has been in RFC 3406; the text from there has 1548 been updated according to our chartered, to update for RFC 5226. 1549 This matter needs to be taken into account by prospective Namespace 1550 owners, and thus the text makes sense in this document. 1551 Reorganization of subsequent text made it logically necessary to 1552 include into this section a high level description of the 1553 urn-nid@ietf.org list. The nominal review period is left a four 1554 weeks in this draft revision, but a Note has been added to s4 1555 indicating that this is an upper limit to accommodate headroom, 1556 whereas the designated expert(s) may always come to a conclusion 1557 earlier. 1558 Repeated references to IANA have been consolidated. 1559 The common shorthand designation "IANA experts" for the designated 1560 expert(s) supporting IANA in the maintenance of the URN NID registry 1561 is now being avoided. 1563 s4.1: No technical changes. The continued use of the "X-" prefix for 1564 Experimental Namespaces does not violate RFC 6648 because this is 1565 legacy practice, experimental NIDs are not being registered, and this 1566 memo again prohibits the use of Experimental Namespaces in the open 1567 Internet. 1569 s4.3: 1570 Text reorganized, incorporating material from s4.4.4 (see below). 1571 The text on the (modified) "IETF Review" policy has been upgraded 1572 from RFC 3406 (and thereby effectively shortened). It serves to give 1573 concise information to the expected primary audience of the document, 1574 applicants for Namespaces, which according to experience are rather 1575 unlikely inclined to read the full RFC 5226, but just need to know 1576 what is said in the single sentence in the draft. Further, this 1577 sentence supplies the background information for the following 1578 sentences and thus improved the readability of the text. Therefore, 1579 no substantive changes applied here. 1581 s4.4: text amended to avoid confusion about registration template. 1583 s4.4.1 and s4.4.2: Heavily reworked based on discussion (Leslie, PSA, 1584 Juha, et al.). Bullet lists now point to clauses of the registration 1585 template where working on the text to be supplied there will likely 1586 give insights to answer the basic questions to be answered here. 1587 A NOTE now tentatively allows to include a combined Namespace and 1588 Community Considerations section into a Namespace registration 1589 document, if the expert review admits it. 1591 s4.4.3: The first sentence lays the foundation for the subsequent 1592 sentences and gives the appropriate reference (to BCP 72); hence it 1593 is regarded as non-disposable -- no change. 1594 Repeated negative experience has motivated the addition of a hint 1595 that emphasizes that WG documents including URN Namespace definitions 1596 need to go through the urn-nid process before they can be forwarded 1597 to the IESG (document writeup requirement). 1599 s4, s4.4.4: Last paragraph ostensibly belonging to s4.4.4 moved to 1600 end of s4, then adjusted to context. (The RFC format doesn't allow 1601 to recognize the continuation of a higher-level section after the 1602 inclusion of sub-sections.) 1604 s4.3, s4.4.4: The checklist of syntactical constraints for NIDs of 1605 formal namespaces was intended as a checklist for IANA; following 1606 comments from Lars Svensson, it has been moved from s4.4.4 to s4.3 1607 and related text has been modified accordingly. 1609 s4.4.4: substantially revised (comments from Lars Svensson et al.). 1611 IANA Cons. (s6): Added request to IANA to clarify the procedures for 1612 Formal NIDs in the list of ptorocol parameter registries. 1614 Updated and expanded Acknowledgements. 1616 References: RFC 3339 demoted to Informational; you don't need to read 1617 it to insert the date into the registration template, the applicable 1618 pattern is shown there directly; this change avoids a potential 1619 normative downref. 1621 Clarified role of Appendices. 1623 Appendix A: 1624 Clarified purpose of the explanations in curly braces embedded in the 1625 annotated registration template. Use term "clause" throughout. 1626 Removed Notes from template that served to explain previous changes. 1627 Template now provided in both annotated and bare form (suggestion 1628 from SM); once finalized, both forms will be provided in xml2rfc 1629 format (location to be decided: IETF Tools and/or IANA). 1630 Added new items to registration template for Purpose of Namespace 1631 (short description of named resources), applicability of part 1632 and supported query instructions (if any), and applicability of 1633 part. 1635 Appendix B: The document organization is carried over from RFC 3406. 1636 Modified title of App. B, declared it Informative. 1638 This Appendix C.5 added; previous Appendix D (Issues) dropped. 1640 Multiple editorial fixes and enhancements. 1642 Author's Address 1644 Alfred Hoenes (editor) 1645 TR-Sys 1646 Gerlinger Str. 12 1647 Ditzingen D-71254 1648 Germany 1650 EMail: ah@TR-Sys.de