idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.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 (October 31, 2011) is 4561 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-01 ** 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) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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) October 31, 2011 5 Intended status: BCP 6 Expires: May 3, 2012 8 Uniform Resource Name (URN) Namespace Definition Mechanisms 9 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01 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 specifies a hierarchy that 16 divides the set of possible URNs into "URN Namespaces" that can be 17 individually defined and managed. URN Namespaces in particular serve 18 to map existing identifier systems into the URN system and thereby 19 make available generic, network-based resolution services for the 20 identified documents, artifacts, and other objects (and their 21 metadata). 23 To actually leverage such synergetic advantage, URN Namespaces need 24 to be specified in a comparable manner, and their Namespace 25 Identifiers (NIDs) need to be registered with IANA, so that naming 26 conflicts are avoided and implementers of services can follow a 27 structured approach in support of various namespaces, guided by the 28 registry to the related documents and the particularities of specific 29 namespaces, as described in these namespace registration documents. 31 This document serves as a guideline for authors of URN Namespace 32 definition and registration documents. It describes the essential 33 content of such documents and how they shall be structured to allow 34 readers familar with the scheme to quickly assess the properties of a 35 specific URN Namespace. Further, this RFC describes the process to 36 be followed to get a URN Namespace registered with IANA. 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 May 3, 2012. 62 Copyright Notice 64 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . 5 93 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5 94 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 6 95 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 6 96 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 97 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 98 4. URN Namespace Registry: Processes for Registration and 99 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 100 4.1. Experimental Namespaces: No Registration . . . . . . . . . 9 101 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 102 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 10 103 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 11 104 4.4.1. Namespace Considerations in Registration Documents . . 11 105 4.4.2. Community Considerations in Registration Documents . . 12 106 4.4.3. Security Considerations in Registration Documents . . 12 107 4.4.4. IANA Considerations in Registration Documents . . . . 13 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 110 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 113 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 114 Appendix A. URN Namespace Definition Template . . . . . . . . . . 16 115 Appendix B. Illustration . . . . . . . . . . . . . . . . . . . . 22 116 B.1. Example Template . . . . . . . . . . . . . . . . . . . . . 22 117 B.2. Registration steps in practice . . . . . . . . . . . . . . 24 118 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25 119 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25 120 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25 121 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . . 28 123 1. Introduction 125 Uniform Resource Names (URNs) are resource identifiers with the 126 specific requirements for 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 There are two assumptions that are key to this document: 135 Assumption #1: Assignment of a URN is a managed process. 137 I.e., not all strings that conform to URN syntax are necessarily 138 valid URNs. A URN is assigned according to the rules of a 139 particular namespace (in terms of syntax, semantics, and process). 141 Assumption #2: The space of URN Namespaces is managed. 143 I.e., not all syntactically correct URN Namespaces (per the URN 144 syntax definition) are valid URN Namespaces. A URN Namespace must 145 have a recognized definition in order to be valid. 147 The purpose of this document is to outline a mechanism and provide a 148 template for explicit namespace definition, as well as provide the 149 mechanism for associating an identifier (called a "Namespace ID", or 150 NID), which is registered with the Internet Assigned Numbers 151 Authority (IANA) [IANA] in the URN Namespaces registry maintained at 152 [IANA-URN]. 154 The URN Namespace definition and registration mechanisms originally 155 have been specified in RFC 2611 [RFC2611], which has been obsoleted 156 by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing 157 IANA procedures have been revised as well over the years, and at the 158 time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative 159 document. This document is a revision of RFC 3406 based on the 160 revised URN Syntax specification RFC 2141bis 161 [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. 163 The reader is referred to Section 1.1 of RFC 2141bis 164 [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the 165 history of documents fundamental for URNs. 167 Note that this document restricts itself to the description of 168 processes for the creation of URN Namespaces. If generic 169 "resolution" of any so-created URN identifiers is desired, a separate 170 process of registration in a global NID directory, such as that 171 provided by the DDDS system [RFC3401], is necessary. See [RFC3405] 172 for information on obtaining registration in the DDDS global NID 173 directory. 175 1.1. Requirement Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 In this document, these key words describe requirements for the 181 process to be followed and the content to be provided in namespace 182 definition documents and registration templates. 184 For the purpose of this document, its subject is spelled "URN 185 Namespace" (in headline case), whereas in other context, "namespace" 186 is spelled in lowercase, e.g. to designate a (standard or non- 187 standard) identifier system on which a URN Namespace is based. 189 2. What is a URN Namespace? 191 For the purposes of URNs, a "namespace" is a collection of uniquely- 192 assigned identifiers. That is, the identifiers are not ever assigned 193 to more than 1 resource, nor are they ever re-assigned to a different 194 resource. A single resource, however, may have more than one URN 195 assigned to it for different purposes. Such namespace might be 196 defined by some pre-established (standard or non-standard) identifier 197 system that can be made "network-actionable" by embedding it into the 198 URN framework using a specific URN Namespace. A URN Namespace itself 199 has an identifier in order to: 201 - ensure global uniqueness of URNs, 203 - (where desired) provide a cue for the structure of the identifier. 205 For example, many identifier systems use strings of numbers as 206 identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable 207 that there might be some numbers that are valid identifiers in two 208 different established identifier systems. Using different 209 designators for the two collections ensures that no two URNs will be 210 the same for different resources (since each collection is required 211 to uniquely assign each identifier). 213 The development of an identifier structure, and thereby a collection 214 of identifiers, is a process that is inherently dependent on the 215 requirements of the community defining the identifier, how they will 216 be assigned, and the uses to which they will be put. All of these 217 issues are specific to the individual community seeking to define a 218 namespace (e.g., publishing community, association of booksellers, 219 protocol developers, etc.); they are beyond the scope of the IETF URN 220 work. 222 This document outlines the processes by which a collection of 223 identifiers satisfying certain constraints (uniqueness of assignment, 224 etc.) can become a bona fide URN Namespace by obtaining a NID. In a 225 nutshell, a template for the definition of the namespace is completed 226 for deposit with IANA, and a NID is assigned. The details of the 227 process and possibilities for NID strings are outlined below. 229 3. URN Namespace (Registration) Types 231 There are three categories of URN Namespaces defined here, 232 distinguished by expected level of service and required procedures 233 for registration. Registration processes for each of these namespace 234 types are given in Section 4. 236 3.1. Experimental Namespaces 238 These are not explicitly registered with IANA. 240 No provision is made for avoiding collision of experimental NIDs; 241 they are intended for use within internal or limited experimental 242 contexts. However, as described below in Section 4.1, these are 243 designated by a specific form of the NID to allow differentiation 244 (without preexisting knowledge of details) from the other URN 245 Namespace types. 247 [[ Editorial Note: 248 Has anybody ever seen usage of such experimental URN Namespaces? 249 According to the observations of the author, three years of RFC 2611 250 and nine years of RFC 3406 have constantly seen "tentative grabbing" 251 and subsequent usage of NIDs that the stakeholders later have tried 252 to register with IANA as Formal NIDs (with varying success). 253 So should this kind of namespaces better be dropped and a kind of 254 provisional NIDs be created? -- This would be in the spirit of BCP 255 100, RFC 4020 [RFC4020], and it would resemble the manner how URI 256 Scheme registrations are dealt with (RFC 4395 [RFC4395], [IANA-URI]). 257 ]] 259 3.2. Informal Namespaces 261 These are fully fledged URN Namespaces, with all the rights and 262 requirements associated thereto. Informal namespaces can be 263 registered in global registration services. They are required to 264 uphold the general principles of a well-managed URN Namespace -- 265 providing persistent identification of resources and unique 266 assignment of identifier strings. Informal and formal namespaces 267 (described below) differ in the NID assignment. IANA will assign an 268 alphanumeric NID (following a defined pattern) to registered informal 269 namespaces, per the process outlined in Section 4. 271 3.3. Formal Namespaces 273 A formal namespace may be requested, and IETF review sought, in cases 274 where the publication of the NID proposal and the underlying 275 namespace will provide benefit to some subset of users on the 276 Internet. That is, a formal NID proposal, if accepted, must be 277 functional on and with the global Internet, not limited to users in 278 communities or networks not connected to the Internet. For example, 279 assume a NID is requested that is meant for naming of physics 280 research. If that NID request required that the user use a 281 proprietary network or service that was not at all open to the 282 general Internet user, then it would make a poor request for a formal 283 NID. The intent is that, while the community of those who may 284 actively use the names assigned within that NID may be small (but no 285 less important), the potential use of names within that NID is open 286 to any user on the Internet. 288 It is expected that Formal NIDs may be applied to namespaces where 289 some aspects are not fully open. For example, a namespace may make 290 use of a fee-based, privately managed, or proprietary registry for 291 assignment of URNs in the namespace, but it may still provide benefit 292 to some Internet users if the services associated have openly- 293 published access protocols. 295 In addition to the basic registration information defined in the 296 registration template (in Appendix A), a formal namespace request 297 must be accompanied by documented considerations of the need for a 298 new namespace and of the community benefit from formally establishing 299 the proposed URN Namespace. 301 Additionally, since the goal of URNs is to provide persistent 302 identification, some consideration as to the longevity and 303 maintainability of the namespace must be given. The collective 304 experience of the IETF community contains a wealth of information on 305 technical factors that will prevent longevity of identification. 306 Thus, the IESG may elect not to accept a proposed namespace 307 registration if the IETF community consensus is that the registration 308 document contains technical flaws that will prevent (or seriously 309 impair the possibility of) persistent identification, and that it 310 therefore should not be published as an RFC. 312 In addition to the technical aspects of the namespace and its 313 resolution, consideration should be given to the following 314 organizatorial aspects: 316 - the organization maintaining the URN Namespace should demonstrate 317 stability and the ability to maintain the URN namespace for a long 318 time, and/or it should be clear how the namespace can continue to 319 be usable/useful if the organization ceases to be able to foster 320 it; 322 - it should demonstrate ability and competency in name assignment; 323 this should improve the likelihood of persistence (e.g., to 324 minimize the likelihood of conflicts); 326 - it needs to commit to not re-assigning existing names and allowing 327 old names to continue to be valid, even if the owners or assignees 328 of those names are no longer members or customers of that 329 organization; this does not mean that there must be resolution of 330 such names, but that they must not resolve the name to false or 331 stale information, and that they must not be reassigned. 333 These aspects, though hard to quantify objectively, should be 334 considered by organizations/people considering the development of a 335 Formal URN Namespace, and they will be kept in mind when evaluating 336 the technical merits of any proposed Formal URN Namespace. The kind 337 of mandate upon which the organization aims to undertake this 338 activity might give a strong indication for this evaluation, because 339 it likely mirrors the trust that other parties (e.g. states, 340 international treaty organizations, professionals' associations, 341 etc.) put on the organization. 343 4. URN Namespace Registry: Processes for Registration and Update 345 Different levels of disclosure are expected/defined for namespaces. 346 According to the level of open-forum discussion surrounding the 347 disclosure, a URN Namespace may be assigned an identifier or may 348 request a particular identifier. 350 The IANA Considerations Guidelines document (BCP 26, RFC 5226 351 [RFC5226]) suggests the need to specify update mechanisms for 352 registrations -- who is given the authority to do so, from time to 353 time, and what are the processes. Since URNs are meant to be 354 persistently useful, few (if any) changes should be made to the 355 structural interpretation of URN strings (e.g., adding or removing 356 rules for lexical equivalence that might affect the interpretation of 357 URN IDs already assigned). However, it may be important to introduce 358 clarifications, expand the list of authorized URN assigners, etc., 359 over the natural course of a namespace's lifetime. Specific 360 processes are outlined below. 362 The official list of registered URN Namespaces is currently 363 maintained by IANA at 364 . 366 The registraty is subdivided into two sub-registries, one for "Formal 367 URN Namespaces" and one for "Informal URN Namespaces", and each entry 368 there links to a stable repository of the registration document or 369 (an escrow copy of) the filled-out registration template. 371 The registration and maintenance procedures vary slightly between the 372 namespace types. 374 4.1. Experimental Namespaces: No Registration 376 The NIDs of Experimental Namespaces (Section 3.1) are not explicitly 377 registered with IANA. They take the form: 379 X- 381 where is a string consisting solely of letters, decimal digits, 382 and hyphen ("-") characters, as specified by the NID syntax 383 specification in Section 2.1 of RFC 2141bis 384 [I-D.ietf-urnbis-rfc2141bis-urn]. 386 No provision is made for avoiding collision of experimental NIDs; 387 they are intended for use within internal or limited experimental 388 contexts exclusively. 390 As there is no registration, no registration/maintenance procedures 391 are needed. 393 Usage of Experimental URN Namespaces MUST be short-lived and whithin 394 a private scope; it MUST NOT be disclosed to the Internet at large, 395 e.g. by distribution of software versions that make use of such. 397 4.2. Informal Namespaces 399 The NIDs of Informal Namespaces are synthesized by the IANA using an 400 assigned sequence number and registered in their own sub-registry, as 401 indicated in Section 4; they take the format: 403 urn- 405 where is the decimal representation of a natural number, 406 with no leading zeroes. This sequence number is assigned by the IANA 407 on a First-Come-First-Served [RFC5226] basis to registration requests 408 for informal namespaces. 410 Registrants should send a copy of the registration template (as shown 411 in Appendix A), duly completed, to the urn-nid@ietf.org mailing list 412 for review and allow for a two-week discussion period for clarifying 413 the expression of the registration information and suggestions for 414 technical improvements to the namespace proposal. 415 [[ NOTE: Longer time is needed in practice! Increase to 4 weeks? ]] 417 After suggestions for clarification of the registration information 418 have been incorporated, the template may be submitted for assignment 419 of a NID by email to iana@iana.org . 421 Registrations may be updated later by the original registrant, or by 422 an entity designated by the registrant, by updating the registration 423 template, submitting it to the discussion list for a further two-week 424 discussion period, and finally resubmitting it to IANA in a message 425 to iana@iana.org . 427 4.3. Formal Namespaces 429 Formal NIDs are assigned via IETF Review, as defined in BCP 26 430 [RFC5226]. The designated expert(s) for URN Namespace registrations 431 are nominated by the IESG, and their role adheres to the regulations 432 in BCP 26, unless specified otherwise below. 434 NIDs for Formal URN Namespaces MUST NOT have the forms indicated in 435 the preceding two sections for the other two Namespace types. (The 436 detailed formal rules are given below in Section 4.4.4.) Applicants, 437 in concert with the IANA experts, should ensure that the sought NID 438 strings are "proper" for the designated purpose, according to common 439 sense (and applicable legal rules). 441 This means that the Formal NID application is made via submission to 442 the IETF of an Internet-Draft that contains the namespace definition 443 and targets publication as an RFC of Informational or Standards Track 444 category, which needs to be approved by the IESG after performing an 445 IETF Last Call on the document and evaluating review comments. The 446 applicant can be an individual or an IETF working group, in alignment 447 with the designation of the Internet-Draft. It is RECOMMENDED that 448 the registration documents for NIDs belonging to an established 449 standard namespace aim at Standards Track, whereas other applications 450 aim at Informational. 452 Before publication can be requested, however, the draft namespace 453 specification document must undergo an Expert Review process 454 [RFC5226] pursuant to the guidelines written here (as well as 455 standard RFC publication guidelines). The template defined in 456 Appendix A SHOULD be included as part of an RFC-to-be defining some 457 other aspect(s) of the namespace, or it may be put forward as a 458 namespace definition document in its own right. The proposed 459 template (including a pointer to a readily available copy of the 460 registration document) should be sent to the urn-nid@ietf.org mailing 461 list for review. This list is monitored by the designated expert(s). 463 The applicant has to allow for a two-week [[ four-week ? ]] 464 discussion period for clarifying the expression of the registration 465 information, and SHOULD improve the namespace document and/or 466 registration template based on the comments received, under the 467 guidance of the designated expert(s), before the IESG reviews the 468 document. 470 Working groups generally SHOULD seek early expert review for a 471 namespace definition document, before they hand it over to the IESG, 472 and individual applicants are also advised to seek expert comments 473 early enough. The aforementioned list can be contacted for informal 474 advice at any stage. 476 4.4. Registration Documents 478 The following subsections describe essential, MANDATORY parts of URN 479 Namespace registration documents, which will be focal in the expert 480 Review process and IETF Review. 482 4.4.1. Namespace Considerations in Registration Documents 484 The namespace definition document MUST include a "Namespace 485 Considerations" section that outlines the perceived need for a new 486 namespace (i.e., where existing namespaces fall short of the 487 proposer's requirements). 489 Considerations MUST include, directly or with the help of referenced 490 stable (and preferably readily available) documents: 492 - URN assignment procedures; 494 - URN resolution/delegation; 496 - type of resources to be identified; 498 - type of services to be supported. 500 NOTE: It is expected that more than one namespace may serve the same 501 "functional" purpose; the intent of the "Namespace Considerations" 502 section is to provide a record of the proposer's "due diligence" in 503 exploring existing possibilities, for the IESG's consideration. 505 [[ Editorial Note: See the endnote of the next section! 506 In particular, the above list (from RFC 3406) seems to be rather 507 orthogonal to the primary purpose of such section (as indicated in 508 the first paragraph), namely to provide evidence for the perceived 509 need for the new namespace. 510 ]] 512 4.4.2. Community Considerations in Registration Documents 514 The namespace definition document MUST also include a "Community 515 Considerations" section that indicates the dimensions upon which the 516 proposer expects its community to be able to benefit by publication 517 of this namespace, as well as how a general Internet user will be 518 able to use the space if they care to do so. 520 Potential considerations include: 522 - open assignment and use of identifiers within the namespace; 524 - open operation of resolution servers for the namespace 525 (server); 527 - creation of software that can meaningfully resolve and access 528 services for the namespace (client). 530 [[ Editorial Note: 531 It is acknowledged that, in many cases, the Namespace Considerations 532 and Community Considerations are closely intertwined. Further, the 533 bulleted lists above (from RFC 3406) seems to be more related to the 534 items in the registration template entitled "Identifier uniqueness 535 considerations", "Identifier persistence considerations", "Process of 536 identifier assignment", and "Process for identifier resolution" than 537 to the primary objectives presented in the first paragraph above 538 (also from RFC 3406). 539 In fact, namespace registration documents seen so far duplicate in 540 the registration template material from the "Community 541 Considerations" that addresses the above bullets. 542 Therefore: Should this specification now allow a combined section 543 "Namespace and Community Considerations" that focuses on the 544 (non-)utility of possible alternate namespace re-use and the 545 *benefits* of an independent new namespace? 546 ]] 548 4.4.3. Security Considerations in Registration Documents 550 According to the general procurements for RFCs, URN Namespace 551 definition documents must include a "Security Considerations" section 552 (cf. BCP 72 [RFC3552]). That section has to identify the security 553 considerations specific to the subject URN Namespace. If the subject 554 URN Namespace is based on an underlying namespace, the registration 555 can include substantive security considerations described in 556 specifications related to that particular namespace by reference to 557 these documents. For general security considerations regarding URN 558 usage (and more generally, URI usage), for the sake of clarity and 559 brevity, it should refer to the Security Considerations in STD 63 561 [RFC3986] and in the URN Syntax document 562 [I-D.ietf-urnbis-rfc2141bis-urn]. 564 4.4.4. IANA Considerations in Registration Documents 566 According to the general procurements for RFCs, URN Namespace 567 definitions documents must include an "IANA Considerations" section 568 (cf. BCP 26 [RFC5226]). That section has to indicate that the 569 document includes a URN Namespace registration that is to be entered 570 into the IANA registry of Formal URN Namespaces. 572 Registration documents for formal URN Namespaces will provide a 573 particular, unique, desired NID string, and this will be assigned by 574 the Standards/Protocol Action of the IESG that approves the 575 publication of the registration document as an RFC. RFC 2141bis 576 [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII 577 strings that are interpreted in a case-insensitive manner, but the 578 NID string SHALL be registered in the capitalization form preferred 579 by the registrant. The proposed NID string MUST conform with the 580 syntax rule in Section 2.1 of RFC 2141bis 581 [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following 582 additional constraints: 584 - not be an already-registered NID; 586 - not start with "X-" (see Section 4.1 above); 588 - not start with "urn-" (see Section 4.2 above); 590 - not start with "xy-", where xy is any combination of 2 ASCII 591 letters (see NOTE below); 593 - be more than 2 characters long. 595 NOTE: All two-letter combinations as well as two-letter combinations 596 followed by "-" and any sequence of valid NID characters are reserved 597 for potential use as countrycode-based NIDs for eventual national 598 registrations of URN Namespaces. The definition and scoping of rules 599 for allocation of responsibility for such namespaces is beyond the 600 scope of this document. 601 Further, to avoid confusion, "urn" is not allowed as an NID string; 602 IANA has permanently reserved this string to prohibit assignment. 604 Registrations may be revised by updating the RFC through standard 605 IETF RFC update processes. In any case, a revised document, in the 606 form of a new Internet-Draft, must be published, and the proposed 607 updated template must be circulated on the urn-nid discussion list, 608 allowing for a two-week [[ four-week ? ]] review period before 609 pursuing RFC publication of the new document. 611 5. Security Considerations 613 This document largely focuses on providing mechanisms for the 614 declaration of public information. Nominally, these declarations 615 should be of relatively low security profile, however there is always 616 the danger of "spoofing" and providing mis-information. Information 617 in these declarations should be taken as advisory. 619 6. IANA Considerations 621 This document outlines the processes for registering URN Namespaces, 622 and has implications for the IANA in terms of registries to be 623 maintained, as previously defined in RFC 3406 [RFC3406]. This 624 document replaces RFC 3406; it contains a revised description for the 625 management of the "Uniform Resource Names (URN) Namespaces" IANA 626 Registry that uses the policy designation terms from BCP 26, RFC 5226 627 [RFC5226], but does not introduce significant changes to the 628 applicable procedures. 630 All references there to the predecessor, [RFC3406], should be 631 replaced by references to this document. 632 We would appreciate a reorganization of the Registry web page to make 633 the registration templates for Informal URN Namespaces directly 634 linked from the main page; this would make the page /assignments/ 635 urn-informal.htm page dispensable (for persistency's sake, the web 636 server should redirect requests to the /assignments/urn-namespaces 637 page. 639 Section 4.4.4 above describes the syntax rules for NIDs to which the 640 registry needs to obey. As pointed out in Section 4.4.4 above and in 641 RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is 642 permanently reserved and MUST NOT be assigned as an NID. 644 In all cases of new namespace registration proposals, the IANA should 645 provisionally assign the appropriate NID (informal or formal), as 646 described throughout the body of this memo, once an IESG-designated 647 expert has confirmed that the requisite registration process steps 648 have been completed. These registrations become permanent and can be 649 made publicly available once the registration document has been 650 approved by the IESG for publications as a Standards Track or 651 Informational RFC. 653 7. Acknowledgements 655 This document is heavily based on RFC 3406, the authors of which are 656 cordially acknowledged. 658 This document also been inspired by other recent documents that have 659 updated important IANA registries, and the countless authors and 660 contributors to these efforts are acknowledged anonymously. 662 Several individuals in the URNbis working group have participated in 663 the detailed discussion of this memo. Particular thanks for detailed 664 review comments and text suggestions go to Juha Hakala and Mykyta 665 Yevstifeyev. 667 8. References 669 8.1. Normative References 671 [I-D.ietf-urnbis-rfc2141bis-urn] 672 Hoenes, A., "Uniform Resource Name (URN) Syntax", 673 draft-ietf-urnbis-rfc2141bis-urn-01 (work in progress), 674 October 2011. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 680 Internet: Timestamps", RFC 3339, July 2002. 682 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 683 Resource Identifier (URI): Generic Syntax", STD 66, 684 RFC 3986, January 2005. 686 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 687 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 688 May 2008. 690 8.2. Informative References 692 [IANA] IANA, "The Internet Assigned Numbers Authority", 693 . 695 [IANA-URI] IANA, "URI Schemes Registry", 696 . 698 [IANA-URN] IANA, "Uniform Resource Names (URN) Namespace Registry", 699 . 701 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 702 Name Resolution", RFC 2276, January 1998. 704 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 705 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 706 June 1999. 708 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 709 IETF URI Planning Interest Group: Uniform Resource 710 Identifiers (URIs), URLs, and Uniform Resource Names 711 (URNs): Clarifications and Recommendations", RFC 3305, 712 August 2002. 714 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 715 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 717 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 718 Part Five: URI.ARPA Assignment Procedures", BCP 65, 719 RFC 3405, October 2002. 721 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 722 "Uniform Resource Names (URN) Namespace Definition 723 Mechanisms", BCP 66, RFC 3406, October 2002. 725 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 726 Text on Security Considerations", BCP 72, RFC 3552, 727 July 2003. 729 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 730 Standards Track Code Points", BCP 100, RFC 4020, 731 February 2005. 733 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 734 Registration Procedures for New URI Schemes", BCP 35, 735 RFC 4395, February 2006. 737 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 738 Specifications: ABNF", STD 68, RFC 5234, January 2008. 740 Appendix A. URN Namespace Definition Template 742 Definition of a URN Namespace is accomplished by completing the 743 following information template. 744 Apart from providing a mechanism for disclosing the structure of the 745 URN Namespace, this information is designed to be useful for 746 - entities seeking to have a URN assigned in a namespace (if 747 applicable) and 749 - entities seeking to provide URN resolvers for a namespace (if 750 applicable). 752 This is particularly important for communities evaluating the 753 possibility of using a portion of an existing URN Namespace rather 754 than creating their own. 756 Applications for Formal URN Namespaces must also document "Namespace 757 Considerations", "Community Considerations", "Security 758 Considerations", and "IANA Considerations", as described in 759 Section 4.4. 761 Information in the template is as follows (text in curly braces is 762 tutorial and should be removed from filled-in templates): 764 Namespace ID: 766 { If request is for an Informal NID, indicate so; the number will 767 be assigned by IANA. In the case of a Formal NID registration, 768 regularly a particular NID string will be requested. } 770 Registration Information: 772 { This is information to identify the particular version of 773 registration information: } 774 - version number: 775 { starting with 1, incrementing by 1 with each new version } 776 - date: 777 { date submitted to the IANA or date of approval of 778 registration document, using the format outlined in "Date and 779 Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD } 781 Declared registrant of the namespace: 783 - Registering organization: 784 Name: { ... } 785 Address: { ... } 786 - Designated contact person: 787 Name: { ... } 788 { Address: ... 789 (at least one of: Email, Phone, Postal address) } 791 Declaration of syntactic structure of NSS part: 793 [[ Editorial Note: In the past, there has been iterated trouble in 794 tentative registration documents with confusion between entire URN 795 syntax and NSS syntax (only). Since the "urn:" prefix is fixed 796 and the NID is fully determined by the "Namespace ID" clause 797 above, in order to avoid error prone duplication, this version of 798 the template tentatively restricts this clause to the NSS 799 (namespace specific string) part of the new URNs. ]] 801 { 802 This section should outline any structural features of identifiers 803 in this namespace. At the very least, this description may be 804 used to introduce terminology used in other sections. This 805 structure may also be used for determining realistic caching/ 806 shortcuts approaches; suitable caveats should be provided. If 807 there are any specific character encoding rules (e.g., which 808 character should always be used for single-quotes), these should 809 be listed here. 811 Answers might include, but are not limited to: 812 - the structure is opaque (no exposition); 813 - a regular expression for parsing the identifier into 814 components, including naming authorities; 815 - formal syntax of the NSS, preferably in ABNF (STD 68 816 [RFC5234]). 817 } 819 Relevant ancillary documentation: 821 { 822 This section should list any RFCs, standards, or other published 823 documentation that defines or explains all or part of the 824 namespace structure. 826 Answers might include, but are not limited to: 827 - RFCs that outline the syntax of the namespace; 828 - other documents of the defining community (e.g., ISO) that 829 outline the syntax of the identifiers in the namespace; 830 - explanatory material that introduces the namespace. 831 } 833 Conformance with URN Syntax: 835 [[ Editorial Note: This clause moved into vicinity of "syntax". ]] 837 { 838 This section should outline any special considerations required 839 for conforming with the URN syntax. This is particularly 840 applicable in the case of legacy naming systems that are used in 841 the context of URNs. 843 For example, if a namespace is used in contexts other than URNs, 844 it may make use of characters that are reserved in the URN syntax. 846 This section should flag any such characters, and outline 847 necessary mappings to conform to URN syntax. Normally, this will 848 be handled by percent-encoding the symbol. 849 } 851 Rules for Lexical Equivalence of NSS part: 853 [[ Editorial Note: This clause moved into vicinity of "syntax". ]] 855 [[ Editorial Note: In the past, there has been iterated trouble in 856 tentative registration documents with regard to what rules can be 857 imposed for lexical equivalence. Since the "urn:" prefix and the 858 NID part both are invariably case-insensitive per RFC 3986 and RFC 859 2141[bis], in order to avoid repeated confusion, this version of 860 the template tentatively restricts this clause to only the NSS 861 part of the new URN Namespace definition documents. ]] 863 { 864 If there are particular algorithms for determining equivalence 865 between two identifiers in the underlying namespace (and hence, in 866 the URN string itself), rules can be provided here. 868 Some examples include: 869 - equivalence between hyphenated and non-hyphenated groupings in 870 the identifier string; 871 - equivalence between single-quotes and double-quotes; 872 - namespace-defined equivalences between specific characters, 873 such as "character X with or without diacritic marks". 875 Note that these are not normative statements for any kind of best 876 practice for handling equivalences between characters; they are 877 statements limited to reflecting the namespace's own rules. 878 } 880 Identifier uniqueness considerations: 882 { 883 This section should address the requirement that URN identifiers 884 be assigned uniquely -- they are assigned to at most one resource, 885 and are not reassigned. 887 (Note that the definition of "resource" is fairly broad; for 888 example, information on "Today's Weather" might be considered a 889 single resource, although the content is dynamic.) 891 Possible answers include, but are not limited to: 892 - exposition of the structure of the identifiers, and 893 partitioning of the space of identifiers amongst assignment 894 authorities that are individually responsible for respecting 895 uniqueness rules; 896 - identifiers are assigned sequentially; 897 - information is withheld; that is, the namespace is opaque. 898 } 900 Identifier persistence considerations: 902 { 903 Although non-reassignment of URN identifiers ensures that a URN 904 will persist in identifying a particular resource even after the 905 "lifetime of the resource", some consideration should be given to 906 the persistence of the usability of the URN. This is particularly 907 important in the case of URN Namespaces providing global 908 resolution. 910 Possible answers include, but are not limited to: 911 - quality of service considerations. 912 } 914 Process of identifier assignment: 916 { 917 This section should detail the mechanisms and/or authorities for 918 assigning URNs to resources. It should make clear whether 919 assignment is completely open, or if limited, how to become an 920 assigner of identifiers, and/or get one assigned by existing 921 assignment authorities. 923 Answers could include, but are not limited to: 924 - assignment is completely open, following a particular 925 algorithm; 926 - assignment is delegated to authorities recognized by a 927 particular organization (e.g., the Digital Object Identifier 928 Foundation controls the DOI assignment space and its 929 delegation); 930 - assignment is completely closed (e.g., for a private 931 organization). 932 } 934 Process for identifier resolution: 936 { 937 If a namespace is intended to be accessible for global resolution, 938 it must be registered in an RDS (Resolution Discovery System, see 939 RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]). 940 Resolution then proceeds according to standard URI resolution 941 processes, and the mechanisms of the RDS. What this section 942 should outline is the requirements for becoming a recognized 943 resolver of URNs in this namespace (and being so listed in the RDS 944 registry). 946 Answers may include, but are not limited to: 947 - the namespace is not listed with an RDS, this is not relevant; 948 - resolution mirroring is completely open, with a mechanism for 949 updating an appropriate RDS; 950 - resolution is controlled by entities to which assignment has 951 been delegated. 952 } 954 Validation mechanism: 956 { 957 Apart from attempting resolution of a URN, a URN Namespace may 958 provide mechanisms for "validating" a URN -- i.e., determining 959 whether a given string is currently a validly-assigned URN. There 960 are 2 issues here: 1) users should not "guess" URNs in a 961 namespace; 2) when the URN Namespace is based on an existing 962 identifier system, it may not be the case that all the existing 963 identifiers are assigned on Day 0. The reasonable expectation is 964 that the resource associated with each resulting URN is somehow 965 related to the thing identified by the original identifier system, 966 but those resources may not exist for each original identifier. 967 For example, even if a telephone number-based URN Namespace was 968 created, it is not clear that all telephone numbers would 969 immediately become "valid" URNs, that could be resolved using 970 whatever mechanisms are described as part of the namespace 971 registration. 973 Validation mechanisms might be: 974 - a syntax grammar; 975 - an on-line service; 976 - an off-line service. 977 } 979 Scope: 981 { 982 This section should outline the scope of the use of the 983 identifiers in this namespace. Apart from considerations of 984 private vs. public namespaces, this section is critical in 985 evaluating the applicability of a requested NID. For example, a 986 namespace claiming to deal with "social security numbers" should 987 have a global scope and address all social security number 988 structures (unlikely). On the other hand, at a national level, it 989 is reasonable to propose a URN Namespace for "this nation's social 990 security numbers". 991 } 993 Appendix B. Illustration 995 B.1. Example Template 997 [[ Editorial Note: Do we really need this any more? 998 Such an almost-concrete example likely contradicts current IESG 999 policy on usage of examples in RFCs. ]] 1001 The following example is provided for the purposes of illustrating 1002 the URN NID template described in Appendix A. Although it is based 1003 on a hypothetical "generic Internet namespace" that has been 1004 discussed informally within the URN WG, there are still technical and 1005 infrastructural issues that would have to be resolved before such a 1006 namespace could be properly and completely described. 1008 Namespace ID: 1010 To be assigned 1012 Registration Information: 1014 - version number: 1 1015 - date: 1017 Declared registrant of the namespace: 1019 - Registering organization: 1020 Name: Thinking Cat Example Enterprises 1021 Postal: 1 ThinkingCat Way 1022 Trupville, NewCountry 1024 - Designated contact person: 1025 Name: L. Daigle 1026 Email: leslie@thinkingcat.example 1028 Declaration of syntactic structure of NSS part: 1030 The namespace specific string structure is as follows: 1032 : 1034 where FQDN is a fully-qualified domain name, and the assigned 1035 string is conformant to URN syntax requirements. 1037 Relevant ancillary documentation: 1039 Definition of domain names, found in: 1041 P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, 1042 RFC 1034, November 1987. 1044 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 1045 STD 13, RFC 1035, November 1987. 1047 Conformance with URN Syntax: 1049 No special considerations. 1051 Rules for Lexical Equivalence of NSS part: 1053 FQDNs are case-insensitive. Thus, the leading portion of the URN 1054 up to the colon after the FQDN is case-insensitive for matches. 1055 The remainder of the identifier must be considered case-sensitive. 1057 Identifier uniqueness considerations: 1059 Uniqueness is guaranteed as long as the assigned string is never 1060 reassigned for a given FQDN, and that the FQDN is never 1061 reassigned. 1063 N.B.: operationally, there is nothing that prevents a domain name 1064 from being reassigned; indeed, it is not an uncommon occurrence. 1065 This is one of the reasons that this example makes a poor URN 1066 namespace in practice, and is therefore not seriously being 1067 proposed as it stands. 1069 Identifier persistence considerations: 1071 Persistence of identifiers is dependent upon suitable delegation 1072 of resolution at the level of "FQDN"s, and persistence of FQDN 1073 assignment. 1075 Same note as above. 1077 Process of identifier assignment: 1079 Assignment of these URNs is delegated to individual domain name 1080 holders (for FQDNs). The holder of the FQDN registration is 1081 required to maintain an entry (or delegate it) in the DDDS. 1082 Within each of these delegated name partitions, the string may be 1083 assigned per local requirements. 1085 E.g., urn:urn-:thinkingcat.example:001203 1087 Process for identifier resolution: 1089 Domain name holders are responsible for operating or delegating 1090 resolution servers for the FQDN in which they have assigned URNs. 1092 Validation mechanism: 1094 None specified. 1096 Scope: 1098 Global. 1100 B.2. Registration steps in practice 1102 The key steps for registration of informal or formal namespaces 1103 typically play out as follows: 1105 A) Informal NID: 1107 1. Complete the registration template. This may be done as part 1108 of an Internet-Draft. 1110 2. Communicate the registration template to urn-nid@ietf.org for 1111 technical review -- as an email with a pointer to the 1112 submitted I-D or inline text containing the template. 1114 3. Update the registration template (and/or document) as 1115 necessary from comments, and repeat steps 2 and 3 as 1116 necessary. 1118 4. Once comments have been addressed (and the review period has 1119 expired), send a request to IANA with the revised registration 1120 template. 1122 B) Formal NID: 1124 1. Write an Internet-Draft describing the namespace and include 1125 the registration template, duly completed. Be sure to include 1126 "Namespace Considerations", "Community Considerations", 1127 "Security Considerations", and "IANA Considerations" sections, 1128 as described in Section 4.4. 1130 2. Submit the Internet-Draft, and send a pointer to the I-D 1131 (perhaps using a copy of the I-D announcement) to 1132 urn-nid@ietf.org in order to solicit technical review. 1134 3. Update the Internet-Draft as necessary from comments, and 1135 repeat steps 2 and 3 as needed. 1137 4. If the Internet-Draft is the product of a working group in the 1138 IETF, follow the usual WG process to forward the document to 1139 the IESG for publication as an RFC. Otherwise, find a 1140 sponsoring Area Director willing to guide the draft through 1141 the IESG. The IESG (or the IETF at large in case an IETF-wide 1142 last call is deemed necessary) may request further changes 1143 (submitted as I-D revisions) and/or direct discussion to 1144 designated working groups, area experts, etc. 1146 5. The IESG evaluation process includes a review by IANA, and if 1147 the IESG approves the document for publication as an RFC, IANA 1148 processing of the document will follow the regular work-flow 1149 between the RFC Editor and IANA. This way, the NID 1150 registration will be made public by IANA when the RFC is 1151 published. 1153 Appendix C. Changes from RFC 3406 1155 C.1. Essential Changes since RFC 3406 1157 [ RFC Editor: please remove the Appendix C.1 headline and all 1158 subsequent subsections of Appendix C starting with Appendix C.2. ] 1160 T.B.D. (after consolidation of this memo) 1162 C.2. Changes from RFC 3406 to URNbis WG Draft -00 1163 o Abstract: rewritten entirely; 1165 o Section 1 (Introduction): added historical RFC information; 1167 o Section 1.1 (Requirements Language): added; 1169 o Section 3.1: added Note that challenges the utility of 1170 Experimental namespaces and raises question of whether formal 1171 "provisional" registrations would be useful; 1173 o Section 4: text expanded and updated; background material added; 1174 added Note to challenge IANA website practices; 1176 o Section 4.2 ff: changed "home" of URN-NID registration discussion 1177 list (it already had been moved to the IETF Secretariat servers); 1179 o Section 4.2: added Note to challenge the 2-week review period; in 1180 current practice, that is almost always exceeded, and some regard 1181 it as too short; 1183 o Section 4.3: largely clarified procedures as they happen in 1184 practice; adapted language for conformance with RFC 5226; use new 1185 home of URN-NID (as mentioned above); the registration template 1186 (Appendix A) now "SHOULD" be used; 1188 o Section 4.3: split off new Section 4.4 on Registration Documents, 1189 because registrants essentially are encouraged to follow these 1190 guidelines for Informal namespaces as well, as far as practical; 1191 replaced "RFC" by "Registration Document"; Section 4.4 is 1192 subdivided for all mandatory sections; 1194 o Section 4.4.1: made requirements a "MUST"; 1196 o Sections 4.4.1 and 4.4.2: added common Note that challenges the 1197 need to split Namespace and Community Considerations, based on 1198 observed problems in practice to separate the topics, and pointing 1199 to overlap with clauses in the registration template due to 1200 bullets listed that are not so clearly related to the headlines 1201 under which they appear; suggestion is to avoid duplication, place 1202 factual stuff into the template and focus on rationale in these 1203 Considerations, perhaps in a common section; 1205 o Section 4.4.3: added discussion of Security Considerations 1206 section; advice is to focus on namespace-specific considerations 1207 and refer to the SecCons in the "generic" RFCs for the general 1208 issues; 1210 o Section 4.4.4: amended discussion of IANA Considerations section; 1211 this tries to reflect standing practice and codifies that Formal 1212 NIDs are generally proposed by the registrant; added Note that 1213 "urn" is permanently reserved and MUST NOT be assigned as a NID, 1214 to avoid confusion (as also specified in RFC 2141bis draft); wrt 1215 registration maintenance: got rid of wrong reference in RFC 3406 1216 (to RFC 2606); 1218 o Section 6 (IANA Considerations): updated and rephrased description 1219 of the role of this document, including a sketch of the history; 1220 added teat that tries to precisely describe what is expected from 1221 IANA on approval of this draft; added text on procedures and 1222 suggest a provisional assignment practice upon "thumbs-up" of the 1223 IANA Expert to protect prospective registrants from collateral 1224 damage on NID precedence in case the document suffers from delays 1225 unrelated to the registration template before it eventually gets 1226 approved; 1228 o Section 7 (Acknowledgements): added; 1230 o References: Updated and amended references; added pointers to 1231 chartered URNbis work items; removed entirely outdated example 1232 material related to legacy documents; 1234 o Appendix A and B.1: added words on Security Considerations 1235 section; 1237 o Appendix A (Registration Template): clarified role of text 1238 snippets in the Template: hint and commentary now all enclosed in 1239 curly braces, with not that these parts shall be removed when 1240 filling in the tempalte; indicate that Formal NIDs are normally 1241 proposed by registrant; changed date/time ref. from ISO 8601 to 1242 RFC 3339; use inherited term "percent-encoding"; 1244 o Appendix A -- structure: moved formal clauses on Conformance with 1245 URN Syntax and Rules for Lexical Equivalence to vicinity of 1246 namespace specific syntax clause, to which these are closely 1247 related; 1249 o Appendix A -- changes of clauses: the Declaration of syntactic 1250 structure and Rules for Lexical Equivalence clauses now 1251 tentatively have been restricted to the NSS part only; this change 1252 is described in NOTEs and motivated by the observation of repeated 1253 confusion in past and present registration documents, which 1254 hopefully can be avoided (and the job of the Expert and reviewers 1255 made easier) by leaving discussion of the invariate parts that 1256 cannot be re-specified there at the single place where they belong 1257 to: the NID is fully specified in the initial clause, rules for 1258 the NID and the URI scheme name "urn" are inherited from RFC 1259 2141[bis] and RFC 3986, respectively, and hence the new clause 1260 descriptions avoid conflict by taking these components out of 1261 scope of these clauses; 1263 o Appendix B.1 (Example Template): facelifted a bit; concerns with 1264 IESG policy on examples in RFCs raised in a NOTE; 1266 o Appendix B.2 (Registration steps in practice): updated and 1267 clarified description of procedure, in alignment to current 1268 practice; 1270 o Appendix C: removed "Changes from RFC 2611"; added this change 1271 log; 1273 o General: numerous editorial changes and enhancements, following 1274 contemporary RFC style. 1276 Appendix D. Open Issues 1278 Discuss consequences of RFC 2141bis (once consensus is achieved); if 1279 proposal for fragment part is adopted, details need to be described 1280 per namespace that wants to adopt these possibilities, and maybe the 1281 registration template needs a new clause where this will be specified 1282 -- or the information has to be assigned to existing clauses. 1284 More elaboration on Services. Since RFC 2483 is considered outdated, 1285 but RFC 2483bis not yet a URNbis work item, we might need a registry 1286 for URN Services (initially populated from RFC 2483) that can be 1287 referred to in namespace registration documents, thus avoiding 1288 normative dependencies on a future RFC 2483bis. 1290 Do we actually need Experimental Namespaces? 1292 The syntax of the NID strings for the various NID types is given in 1293 an informal manner (as has been done in RFC 3406); is it worth the 1294 effort to introduce ABNF for this purpose? 1296 Increase review/timeout periods for urn-nid list and IANA experts to 1297 4 weeks? 1299 Clarification of the desired content of the "Namespace 1300 Considerations" and "Community Considerations" sections in 1301 registration documents. Shall we admit a combined section for both 1302 topics? (so far supported by 2 postings) Cf. the NOTEs in Sections 1303 4.4.1 and 4.4.2 for more details. 1305 Shall other strings than "urn" also be 'reserved' in the NID 1306 registry? (e.g. "uri", "url", "urc", "example", ...) 1307 Do we still need Appendix B.1 ? (There are lots of real-life 1308 examples now!) 1310 Also see the Editorial Notes interspersed in the body of this draft. 1312 Author's Address 1314 Alfred Hoenes 1315 TR-Sys 1316 Gerlinger Str. 12 1317 Ditzingen D-71254 1318 Germany 1320 EMail: ah@TR-Sys.de