idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00.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 (December 17, 2010) is 4879 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-00 ** 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) December 17, 2010 5 Intended status: BCP 6 Expires: June 20, 2011 8 Uniform Resource Name (URN) Namespace Definition Mechanisms 9 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00 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 horizontally divides the set of possible URNs into "URN Namespaces" 17 that can be individually defined and managed. URN Namespaces in 18 particular serve to map existing identifier systems into the URN 19 system and thereby make available generic, network-based resolution 20 services for the identified documents, artifacts, and other objects 21 (and their 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 guidleline 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 This draft version has been obtained by importing the text from RFC 44 3406 into modern tools and making a first round of updating steps. 45 It is an initial chartered work item of the URNBIS WG. 47 Discussion of this memo utilizes the urn@ietf.org mailing list. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on June 20, 2011. 66 Copyright Notice 68 Copyright (c) 2010 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 This document may contain material from IETF Documents or IETF 82 Contributions published or made publicly available before November 83 10, 2008. The person(s) controlling the copyright in some of this 84 material may not have granted the IETF Trust the right to allow 85 modifications of such material outside the IETF Standards Process. 86 Without obtaining an adequate license from the person(s) controlling 87 the copyright in such materials, this document may not be modified 88 outside the IETF Standards Process, and derivative works of it may 89 not be created outside the IETF Standards Process, except to format 90 it for publication as an RFC or to translate it into languages other 91 than English. 93 Table of Contents 95 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 96 1.1. Requirement Language . . . . . . . . . . . . . . . . . . . 5 97 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5 98 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 6 99 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 6 100 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 101 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 6 102 4. URN Namespace Registry: Processes for Registration and 103 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 104 4.1. Experimental Namespaces: No Registration . . . . . . . . . 9 105 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 106 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 10 107 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 10 108 4.4.1. Namespace Considerations in Registration Documents . . 11 109 4.4.2. Community Considerations in Registration Documents . . 11 110 4.4.3. Security Considerations in Registration Documents . . 12 111 4.4.4. IANA Considerations in Registration Documents . . . . 12 112 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 114 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 115 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 116 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 117 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 118 Appendix A. URN Namespace Definition Template . . . . . . . . . . 16 119 Appendix B. Illustration . . . . . . . . . . . . . . . . . . . . 21 120 B.1. Example Template . . . . . . . . . . . . . . . . . . . . . 21 121 B.2. Registration steps in practice . . . . . . . . . . . . . . 23 122 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25 123 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25 124 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25 125 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . . 27 127 1. Introduction 129 Uniform Resource Names (URNs) are resource identifiers with the 130 specific requirements for enabling location-independent 131 identification of a resource, as well as longevity of reference. 132 URNs are part of the larger Uniform Resource Identifier (URI) family 133 (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF 134 STD 66, RFC 3986 [RFC3986]) with the specific goal of providing 135 persistent naming of resources. 137 There are two assumptions that are key to this document: 139 Assumption #1: Assignment of a URN is a managed process. 141 I.e., not all strings that conform to URN syntax are necessarily 142 valid URNs. A URN is assigned according to the rules of a 143 particular namespace (in terms of syntax, semantics, and process). 145 Assumption #2: The space of URN namespaces is managed. 147 I.e., not all syntactically correct URN namespaces (per the URN 148 syntax definition) are valid URN namespaces. A URN namespace must 149 have a recognized definition in order to be valid. 151 The purpose of this document is to outline a mechanism and provide a 152 template for explicit namespace definition, as well as provide the 153 mechanism for associating an identifier (called a "Namespace ID", or 154 NID), which is registered with the Internet Assigned Numbers 155 Authority (IANA) [IANA] in the URN Namespaces registry maintained at 156 [IANA-URN]. 158 The URN Namespace definition and registration mechanisms originally 159 have been specified in RFC 2611 [RFC2611], which has been obsoleted 160 by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing 161 IANA procedures have been revised as well over the years, and at the 162 time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative 163 document. This document is a revision of RFC 3406 based on the 164 revised URN Syntax specification RFC 2141bis 165 [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226. 167 The reader is referred to Section 1.1 of RFC 2141bis 168 [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the 169 history of documents fundamental for URNs. 171 Note that this document restricts itself to the description of 172 processes for the creation of URN namespaces. If "resolution" of any 173 so-created URN identifiers is desired, a separate process of 174 registration in a global NID directory, such as that provided by the 175 DDDS system [RFC3401], is necessary. See [RFC3405] for information 176 on obtaining registration in the DDDS global NID directory. 178 1.1. Requirement Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 In this document, these key words describe requirements for the 184 process to be followed and the content to be provided in namespace 185 definition documents and registration templates. 187 2. What is a URN Namespace? 189 For the purposes of URNs, a "namespace" is a collection of uniquely- 190 assigned identifiers. That is, the identifiers are not ever assigned 191 to more than 1 resource, nor are they ever re-assigned to a different 192 resource. A single resource, however, may have more than one URN 193 assigned to it for different purposes. A URN namespace itself has an 194 identifier in order to: 196 - ensure global uniqueness of URNs, 198 - (where desired) provide a cue for the structure of the identifier. 200 For example, many identifier systems use strings of numbers as 201 identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable 202 that there might be some numbers that are valid identifiers in two 203 different established identifier systems. Using different 204 designators for the two collections ensures that no two URNs will be 205 the same for different resources (since each collection is required 206 to uniquely assign each identifier). 208 The development of an identifier structure, and thereby a collection 209 of identifiers, is a process that is inherently dependent on the 210 requirements of the community defining the identifier, how they will 211 be assigned, and the uses to which they will be put. All of these 212 issues are specific to the individual community seeking to define a 213 namespace (e.g., publishing community, association of booksellers, 214 protocol developers, etc.); they are beyond the scope of the IETF URN 215 work. 217 This document outlines the processes by which a collection of 218 identifiers satisfying certain constraints (uniqueness of assignment, 219 etc.) can become a bona fide URN namespace by obtaining a NID. In a 220 nutshell, a template for the definition of the namespace is completed 221 for deposit with IANA, and a NID is assigned. The details of the 222 process and possibilities for NID strings are outlined below. 224 3. URN Namespace (Registration) Types 226 There are three categories of URN namespaces defined here, 227 distinguished by expected level of service and required procedures 228 for registration. Registration processes for each of these namespace 229 types are given in Section 4. 231 3.1. Experimental Namespaces 233 These are not explicitly registered with IANA. They take the form: 235 X- 237 No provision is made for avoiding collision of experimental NIDs; 238 they are intended for use within internal or limited experimental 239 contexts. 241 [[ Editorial Note: 242 Has anybody ever seen usage of such experimental URN Namespaces? 243 According to the observations of the author, three years of RFC 2611 244 and eight years of RFC 3406 have constantly seen "tentative grabbing" 245 and subsequent usage of NIDs that the stakeholders later have tried 246 to register with IANA as Formal NIDs (with varying success). 247 So should this kind of namespaces better be dropped and a kind of 248 provisional NIDs be created? -- This would be in the spirit of BCP 249 100, RFC 4020 [RFC4020], and it would resemble the manner how URI 250 Scheme registrations are dealt with (RFC 4395 [RFC4395], [IANA-URI]). 251 ]] 253 3.2. Informal Namespaces 255 These are fully fledged URN namespaces, with all the rights and 256 requirements associated thereto. Informal namespaces can be 257 registered in global registration services. They are required to 258 uphold the general principles of a well-managed URN namespace -- 259 providing persistent identification of resources and unique 260 assignment of identifier strings. Informal and formal namespaces 261 (described below) differ in the NID assignment. IANA will assign an 262 alphanumeric NID (following a defined pattern) to registered informal 263 namespaces, per the process outlined in Section 4. 265 3.3. Formal Namespaces 267 A formal namespace may be requested, and IETF review sought, in cases 268 where the publication of the NID proposal and the underlying 269 namespace will provide benefit to some subset of users on the 270 Internet. That is, a formal NID proposal, if accepted, must be 271 functional on and with the global Internet, not limited to users in 272 communities or networks not connected to the Internet. For example, 273 assume a NID is requested that is meant for naming of physics 274 research. If that NID request required that the user use a 275 proprietary network or service that was not at all open to the 276 general Internet user, then it would make a poor request for a formal 277 NID. The intent is that, while the community of those who may 278 actively use the names assigned within that NID may be small (but no 279 less important), the potential use of names within that NID is open 280 to any user on the Internet. 282 It is expected that Formal NIDs may be applied to namespaces where 283 some aspects are not fully open. For example, a namespace may make 284 use of a fee-based, privately managed, or proprietary registry for 285 assignment of URNs in the namespace, but it may still provide benefit 286 to some Internet users if the services associated have openly- 287 published access protocols. 289 In addition to the basic registration information defined in the 290 registration template (in Appendix A), a formal namespace request 291 must be accompanied by documented considerations of the need for a 292 new namespace and of the community benefit from formally establishing 293 the proposed URN namespace. 295 Additionally, since the goal of URNs is to provide persistent 296 identification, some consideration as to the longevity and 297 maintainability of the namespace must be given. The collective 298 experience of the IETF community contains a wealth of information on 299 technical factors that will prevent longevity of identification. 300 Thus, the IESG may elect not to accept a proposed namespace 301 registration if the IETF community consensus is that the registration 302 document contains technical flaws that will prevent (or seriously 303 impair the possibility of) persistent identification, and that it 304 therefore should not be published as an RFC. 306 Consideration should be given to these aspects: 308 - the organization maintaining the URN namespace should demonstrate 309 stability and the ability to maintain the URN namespace for a long 310 time, and/or it should be clear how the namespace can continue to 311 be usable/useful if the organization ceases to be able to foster 312 it; 314 - it should demonstrate ability and competency in name assignment; 315 this should improve the likelihood of persistence (e.g., to 316 minimize the likelihood of conflicts); 318 - it should commit to not re-assigning existing names and allowing 319 old names to continue to be valid, even if the owners or assignees 320 of those names are no longer members or customers of that 321 organization; this does not mean that there must be resolution of 322 such names, but that they must not resolve the name to false or 323 stale information, and that they must not be reassigned. 325 These aspects, though hard to quantify objectively, should be 326 considered by organizations/people considering the development of a 327 Formal URN namespace, and they will be kept in mind when evaluating 328 the technical merits of any proposed Formal URN namespace. 330 4. URN Namespace Registry: Processes for Registration and Update 332 Different levels of disclosure are expected/defined for namespaces. 333 According to the level of open-forum discussion surrounding the 334 disclosure, a URN namespace may be assigned an identifier or may 335 request a particular identifier. 337 The IANA Considerations Guidelines document (BCP 26, RFC 5226 338 [RFC5226]) suggests the need to specify update mechanisms for 339 registrations -- who is given the authority to do so, from time to 340 time, and what are the processes. Since URNs are meant to be 341 persistently useful, few (if any) changes should be made to the 342 structural interpretation of URN strings (e.g., adding or removing 343 rules for lexical equivalence that might affect the interpretation of 344 URN IDs already assigned). However, it may be important to introduce 345 clarifications, expand the list of authorized URN assigners, etc., 346 over the natural course of a namespace's lifetime. Specific 347 processes are outlined below. 349 The official list of registered URN namespaces is currently 350 maintained by IANA at 351 . 354 [[ NOTE: It would be preferable to restore the generic, most 355 universally supported (HTML) form of the registry be identified by an 356 implementation-neutral URL, as previously supported by IANA: 357 . The content there 358 should link to alternate forms (.xml, .txt), and those alternate 359 versions should indicate the *other* versions; i.e., where currently 360 the .txt version also says, "This registry is also available in XML 361 and plain text formats.", it should better say: "This registry is 362 also available in HTML and XML formats." ]] 364 The registration is subdivided into two sub-registries, one for 365 "Formal URN Namespaces" and one for "Informal URN Namespaces", and 366 each entry there links to a stable repository of the registration 367 document or (an escrow copy of) the filled-out registration template. 369 The registration and maintenance procedures vary slightly between the 370 namespace types. 372 4.1. Experimental Namespaces: No Registration 374 The NIDs of Experimental Namespaces (Section 3.1) are not explicitly 375 registered with IANA. They take the form: 377 X- 379 No provision is made for avoiding collision of experimental NIDs; 380 they are intended for use within internal or limited experimental 381 contexts exclusively. 383 As there is no registration, no registration/maintenance procedures 384 are needed. 386 4.2. Informal Namespaces 388 The NIDs of Informal Namespaces are synthesized by IANA using an 389 assigned sequence number and registered in their own sub-registry, as 390 indicated in Section 4; they take the format: 392 "urn-" 394 where is the decimal representation of a natural number, 395 with no leading zeroes. This sequence number is assigned by the IANA 396 on a First-Come-First-Served [RFC5226] basis to registration requests 397 for informal namespaces. 399 Registrants should send a copy of the registration template (as shown 400 in Appendix A), duly completed, to the urn-nid@ietf.org mailing list 401 for review and allow for a two-week discussion period for clarifying 402 the expression of the registration information and suggestions for 403 technical improvements to the namespace proposal. [ NOTE: Longer time 404 is needed in practice! Increase to 4 weeks? ] 406 After suggestions for clarification of the registration information 407 have been incorporated, the template may be submitted for assignment 408 of a NID by email to iana@iana.org . 410 Registrations may be updated later by the original registrant, or by 411 an entity designated by the registrant, by updating the registration 412 template, submitting it to the discussion list for a further two-week 413 discussion period, and finally resubmitting it to IANA in a message 414 to iana@iana.org . 416 4.3. Formal Namespaces 418 Formal NIDs are assigned via IETF Review, as defined in BCP 26 419 [RFC5226]. The designated expert(s) for URN namespace registrations 420 are nominated by the IESG, and their role adheres to the regulations 421 in BCP 26, unless specified otherwise below. 423 This means that the Formal NID application is made via submission to 424 the IETF of an Internet-Draft that contains the namespace definition 425 and targets publication as an RFC of Informational or Standards Track 426 category, which needs to be approved by the IESG after performing an 427 IETF Last Call on the document and evaluating review comments. The 428 applicant can be an individual or an IETF working group, in alignment 429 with the designation of the Internet-Draft. 431 Before publication can be requested, however, the draft namespace 432 specification document must undergo an Expert Review process 433 [RFC5226] pursuant to the guidelines written here (as well as 434 standard RFC publication guidelines). The template defined in 435 Appendix A SHOULD be included as part of an RFC-to-be defining some 436 other aspect(s) of the namespace, or it may be put forward as a 437 namespace definition document in its own right. The proposed 438 template (including a pointer to a readily available copy of the 439 registration document) should be sent to the urn-nid@ietf.org mailing 440 list for review. This list is monitored by the designated expert(s). 441 The applicant has to allow for a two-week discussion period for 442 clarifying the expression of the registration information, and SHOULD 443 improve the namespace document and/or registration template based on 444 the comments received, under the guidance of the designated 445 expert(s), before the IESG reviews the document. 447 Working groups generally SHOULD seek early expert review for a 448 namespace definition document, before they hand it over to the IESG, 449 and individual applicants are also advised to seek expert comments 450 early enough. The aforementioned list can be contacted for informal 451 advice at any stage. 453 4.4. Registration Documents 455 The following subsections describe essential, MANDATORY parts of URN 456 namespace registration documents, which will be focal in the expert 457 Review process and IETF Review. 459 4.4.1. Namespace Considerations in Registration Documents 461 The namespace definition document MUST include a "Namespace 462 Considerations" section that outlines the perceived need for a new 463 namespace (i.e., where existing namespaces fall short of the 464 proposer's requirements). 466 Considerations MUST include, directly or with the help of referenced 467 stable (and preferably readily available) documents: 469 - URN assignment procedures; 471 - URN resolution/delegation; 473 - type of resources to be identified; 475 - type of services to be supported. 477 NOTE: It is expected that more than one namespace may serve the same 478 "functional" purpose; the intent of the "Namespace Considerations" 479 section is to provide a record of the proposer's "due diligence" in 480 exploring existing possibilities, for the IESG's consideration. 482 [[ Editorial Note: See the endnote of the next section! ]] 484 4.4.2. Community Considerations in Registration Documents 486 The namespace definition document MUST also include a "Community 487 Considerations" section that indicates the dimensions upon which the 488 proposer expects its community to be able to benefit by publication 489 of this namespace, as well as how a general Internet user will be 490 able to use the space if they care to do so. 492 Potential considerations include: 494 - open assignment and use of identifiers within the namespace; 496 - open operation of resolution servers for the namespace 497 (server); 499 - creation of software that can meaningfully resolve and access 500 services for the namespace (client). 502 [[ Editorial Note: 503 It is acknowledged that, in many cases, the Namespace Considerations 504 and Community Considerations are closely intertwined. Further, the 505 bulleted list above (from RFC 3406) seems to be more related to the 506 items in the registration template entitled "Identifier uniqueness 507 considerations", "Identifier persistence considerations", "Process of 508 identifier assignment", and "Process for identifier resolution" than 509 to the primary objectives presented in the first paragraph above 510 (also from RFC 3406). 511 In fact, namespace registration documents seen so far duplicate in 512 the registration template material from the "Community 513 Considerations" that addresses the above bullets. 514 Therefore: Should this specification now allow a combined section 515 "Namespace and Community Considerations" that focuses on the 516 (non-)utility of possible alternate namespace re-use and the 517 *benefits* of an independent new namespace? 518 ]] 520 4.4.3. Security Considerations in Registration Documents 522 According to the general procurements for RFCs, URN namespace 523 definition documents must include a "Security Considerations" section 524 (cf. BCP 72 [RFC3552]). That section has to identify the security 525 considerations specific to the subject URN namespace. If the subject 526 URN namespace is based on an underlying namespace, the registration 527 can include substantive security considerations described in 528 specifications related to that particular namespace by reference to 529 these documents. For general security considerations regarding URN 530 usage (and more generally, URI usage), for the sake of clarity and 531 brevity, it should refer to the Security Considerations in STD 63 532 [RFC3986] and in the URN Syntax document 533 [I-D.ietf-urnbis-rfc2141bis-urn]. 535 4.4.4. IANA Considerations in Registration Documents 537 According to the general procurements for RFCs, URN namespace 538 definitions documents must include an "IANA Considerations" section 539 (cf. BCP 26 [RFC5226]). That section has to indicate that the 540 document includes a URN Namespace registration that is to be entered 541 into the IANA registry of Formal URN Namespaces. 543 Registration documents for formal URN namespaces will provide a 544 particular, unique, desired NID string, and this will be assigned by 545 the Standards/Protocol Action of the IESG that approves the 546 publication of the registration document as an RFC. RFC 2141bis 547 [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII 548 strings that are interpreted in a case-insensitive manner, but the 549 NID string SHALL be registered in the capitalization form preferred 550 by the registrant. The proposed NID string MUST conform with the 551 syntax rule in Section 2.1 of RFC 2141bis 552 [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following 553 additional constraints: 555 - not be an already-registered NID; 557 - not start with "X-" (see Section 4.1 above); 559 - not start with "urn-" (see Section 4.2 above); 561 - not start with "xy-", where xy is any combination of 2 ASCII 562 letters (see NOTE below); 564 - be more than 2 letters long. 566 NOTE: All two-letter combinations as well as two-letter combinations 567 followed by "-" and any sequence of valid NID characters are reserved 568 for potential use as countrycode-based NIDs for eventual national 569 registrations of URN namespaces. The definition and scoping of rules 570 for allocation of responsibility for such namespaces is beyond the 571 scope of this document. 572 Further, to avoid confusion, "urn" is not allowed as an NID string; 573 IANA has permanently reserved this string to prohibit assignment. 575 Registrations may be revised by updating the RFC through standard 576 IETF RFC update processes. In any case, a revised document, in the 577 form of a new Internet-Draft, must be published, and the proposed 578 updated template must be circulated on the urn-nid discussion list, 579 allowing for a two-week review period before pursuing RFC publication 580 of the new document. 582 5. Security Considerations 584 This document largely focuses on providing mechanisms for the 585 declaration of public information. Nominally, these declarations 586 should be of relatively low security profile, however there is always 587 the danger of "spoofing" and providing mis-information. Information 588 in these declarations should be taken as advisory. 590 6. IANA Considerations 592 This document outlines the processes for registering URN namespaces, 593 and has implications for the IANA in terms of registries to be 594 maintained, as previously defined in RFC 3406 [RFC3406]. This 595 document replaces RFC 3406; it contains a revised description for the 596 management of the "Uniform Resource Names (URN) Namespaces" IANA 597 Registry that uses the policy designation terms from BCP 26, RFC 5226 598 [RFC5226], but does not introduce significant changes to the 599 applicable procedures. 601 All references there to the predecessor, [RFC3406], should be 602 replaced by references to this document. 604 Section 4.4.4 above describes the syntax rules for NIDs to which the 605 registry needs to obey. As pointed out in Section 4.4.4 above and in 606 RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is 607 permanently reserved and MUST NOT be assigned as an NID. 609 In all cases of new namespace registration proposals, the IANA should 610 provisionally assign the appropriate NID (informal or formal), as 611 described throughout the body of this memo, once an IESG-designated 612 expert has confirmed that the requisite registration process steps 613 have been completed. These registrations become permanent and can be 614 made publicly available once the registration document has been 615 approved by the IESG for publications as a Standards Track or 616 Informational RFC. 618 7. Acknowledgements 620 This document is heavily based on RFC 3406, the author of which are 621 cordially acknowledged. 623 This document also been inspired by other recent documents that have 624 updated important IANA registries, and the countless authors and 625 contributors to these efforts are acknowledged anonymously. 627 Your name could go here ... 629 8. References 631 8.1. Normative References 633 [I-D.ietf-urnbis-rfc2141bis-urn] 634 Hoenes, A., "Uniform Resource Name (URN) Syntax", 635 draft-ietf-urnbis-rfc2141bis-urn-00 (work in progress), 636 November 2010. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 642 Internet: Timestamps", RFC 3339, July 2002. 644 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 645 Resource Identifier (URI): Generic Syntax", STD 66, 646 RFC 3986, January 2005. 648 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 649 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 650 May 2008. 652 8.2. Informative References 654 [IANA] IANA, "The Internet Assigned Numbers Authority", 655 . 657 [IANA-URI] 658 IANA, "URI Schemes Registry", 659 . 661 [IANA-URN] 662 IANA, "Uniform Resource Names (URN) Namespace Registry", 663 . 665 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 666 Name Resolution", RFC 2276, January 1998. 668 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 669 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 670 June 1999. 672 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 673 IETF URI Planning Interest Group: Uniform Resource 674 Identifiers (URIs), URLs, and Uniform Resource Names 675 (URNs): Clarifications and Recommendations", RFC 3305, 676 August 2002. 678 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 679 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 681 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 682 Part Five: URI.ARPA Assignment Procedures", BCP 65, 683 RFC 3405, October 2002. 685 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 686 "Uniform Resource Names (URN) Namespace Definition 687 Mechanisms", BCP 66, RFC 3406, October 2002. 689 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 690 Text on Security Considerations", BCP 72, RFC 3552, 691 July 2003. 693 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 694 Standards Track Code Points", BCP 100, RFC 4020, 695 February 2005. 697 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 698 Registration Procedures for New URI Schemes", BCP 35, 699 RFC 4395, February 2006. 701 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 702 Specifications: ABNF", STD 68, RFC 5234, January 2008. 704 Appendix A. URN Namespace Definition Template 706 Definition of a URN namespace is accomplished by completing the 707 following information template. 708 Apart from providing a mechanism for disclosing the structure of the 709 URN namespace, this information is designed to be useful for 711 - entities seeking to have a URN assigned in a namespace (if 712 applicable) and 714 - entities seeking to provide URN resolvers for a namespace (if 715 applicable). 717 This is particularly important for communities evaluating the 718 possibility of using a portion of an existing URN namespace rather 719 than creating their own. 721 Applications for Formal URN namespaces must also document "Namespace 722 Considerations", "Community Considerations", "Security 723 Considerations", and "IANA Considerations", as described in 724 Section 4.4. 726 Information in the template is as follows (text in curly braces is 727 tutorial and should be removed from filled-in templates): 729 Namespace ID: 731 { If request is for an Informal NID, indicate so; the number will 732 be assigned by IANA. In the case of a Formal NID registration, 733 regularly a particular NID string will be requested. } 735 Registration Information: 737 { This is information to identify the particular version of 738 registration information: } 739 - version number: 740 { starting with 1, incrementing by 1 with each new version } 741 - date: 742 { date submitted to the IANA or date of approval of 743 registration document, using the format outlined in "Date and 744 Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD } 746 Declared registrant of the namespace: 748 - Registering organization: 749 Name: { ... } 750 Address: { ... } 751 - Designated contact person: 752 Name: { ... } 753 { Address: ... 754 (at least one of: Email, Phone, Postal address) } 756 Declaration of syntactic structure of NSS part: 758 [[ Editorial Note: In the past, there has been iterated trouble in 759 tentative registration documents with confusion between entire URN 760 syntax and NSS syntax (only). Since the "urn:" prefix is fixed 761 and the NID is fully determined by the "Namespace ID" clause 762 above, in order to avoid error prone duplication, this version of 763 the template tentatively restricts this clause to the NSS 764 (namespace specific string) part of the new URNs. ]] 766 { 767 This section should outline any structural features of identifiers 768 in this namespace. At the very least, this description may be 769 used to introduce terminology used in other sections. This 770 structure may also be used for determining realistic caching/ 771 shortcuts approaches; suitable caveats should be provided. If 772 there are any specific character encoding rules (e.g., which 773 character should always be used for single-quotes), these should 774 be listed here. 776 Answers might include, but are not limited to: 777 - the structure is opaque (no exposition); 778 - a regular expression for parsing the identifier into 779 components, including naming authorities; 780 - formal syntax of the NSS, preferably in ABNF (STD 68 781 [RFC5234]). 782 } 784 Relevant ancillary documentation: 786 { 787 This section should list any RFCs, standards, or other published 788 documentation that defines or explains all or part of the 789 namespace structure. 791 Answers might include, but are not limited to: 792 - RFCs that outline the syntax of the namespace; 793 - other documents of the defining community (e.g., ISO) that 794 outline the syntax of the identifiers in the namespace; 795 - explanatory material that introduces the namespace. 796 } 798 Conformance with URN Syntax: 800 [[ Editorial Note: This clause moved into vicinity of "syntax". ]] 802 { 803 This section should outline any special considerations required 804 for conforming with the URN syntax. This is particularly 805 applicable in the case of legacy naming systems that are used in 806 the context of URNs. 808 For example, if a namespace is used in contexts other than URNs, 809 it may make use of characters that are reserved in the URN syntax. 811 This section should flag any such characters, and outline 812 necessary mappings to conform to URN syntax. Normally, this will 813 be handled by percent-encoding the symbol. 814 } 816 Rules for Lexical Equivalence of NSS part: 818 [[ Editorial Note: This clause moved into vicinity of "syntax". ]] 820 [[ Editorial Note: In the past, there has been iterated trouble in 821 tentative registration documents with regard to what rules can be 822 imposed for lexical equivalence. Since the "urn:" prefix and the 823 NID part both are invariably case-insensitive per RFC 3986 and RFC 824 2141[bis], in order to avoid repeated confusion, this version of 825 the template tentatively restricts this clause to only the NSS 826 part of the new URN namespace definition documents. ]] 828 { 829 If there are particular algorithms for determining equivalence 830 between two identifiers in the underlying namespace (and hence, in 831 the URN string itself), rules can be provided here. 833 Some examples include: 834 - equivalence between hyphenated and non-hyphenated groupings in 835 the identifier string; 836 - equivalence between single-quotes and double-quotes; 837 - namespace-defined equivalences between specific characters, 838 such as "character X with or without diacritic marks". 840 Note that these are not normative statements for any kind of best 841 practice for handling equivalences between characters; they are 842 statements limited to reflecting the namespace's own rules. 843 } 845 Identifier uniqueness considerations: 847 { 848 This section should address the requirement that URN identifiers 849 be assigned uniquely -- they are assigned to at most one resource, 850 and are not reassigned. 852 (Note that the definition of "resource" is fairly broad; for 853 example, information on "Today's Weather" might be considered a 854 single resource, although the content is dynamic.) 856 Possible answers include, but are not limited to: 857 - exposition of the structure of the identifiers, and 858 partitioning of the space of identifiers amongst assignment 859 authorities that are individually responsible for respecting 860 uniqueness rules; 861 - identifiers are assigned sequentially; 862 - information is withheld; that is, the namespace is opaque. 863 } 865 Identifier persistence considerations: 867 { 868 Although non-reassignment of URN identifiers ensures that a URN 869 will persist in identifying a particular resource even after the 870 "lifetime of the resource", some consideration should be given to 871 the persistence of the usability of the URN. This is particularly 872 important in the case of URN namespaces providing global 873 resolution. 875 Possible answers include, but are not limited to: 876 - quality of service considerations. 877 } 879 Process of identifier assignment: 881 { 882 This section should detail the mechanisms and/or authorities for 883 assigning URNs to resources. It should make clear whether 884 assignment is completely open, or if limited, how to become an 885 assigner of identifiers, and/or get one assigned by existing 886 assignment authorities. 888 Answers could include, but are not limited to: 889 - assignment is completely open, following a particular 890 algorithm; 891 - assignment is delegated to authorities recognized by a 892 particular organization (e.g., the Digital Object Identifier 893 Foundation controls the DOI assignment space and its 894 delegation); 895 - assignment is completely closed (e.g., for a private 896 organization). 897 } 899 Process for identifier resolution: 901 { 902 If a namespace is intended to be accessible for global resolution, 903 it must be registered in an RDS (Resolution Discovery System, see 904 RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]). 905 Resolution then proceeds according to standard URI resolution 906 processes, and the mechanisms of the RDS. What this section 907 should outline is the requirements for becoming a recognized 908 resolver of URNs in this namespace (and being so listed in the RDS 909 registry). 911 Answers may include, but are not limited to: 912 - the namespace is not listed with an RDS, this is not relevant; 913 - resolution mirroring is completely open, with a mechanism for 914 updating an appropriate RDS; 915 - resolution is controlled by entities to which assignment has 916 been delegated. 917 } 919 Validation mechanism: 921 { 922 Apart from attempting resolution of a URN, a URN namespace may 923 provide mechanisms for "validating" a URN -- i.e., determining 924 whether a given string is currently a validly-assigned URN. There 925 are 2 issues here: 1) users should not "guess" URNs in a 926 namespace; 2) when the URN namespace is based on an existing 927 identifier system, it may not be the case that all the existing 928 identifiers are assigned on Day 0. The reasonable expectation is 929 that the resource associated with each resulting URN is somehow 930 related to the thing identified by the original identifier system, 931 but those resources may not exist for each original identifier. 932 For example, even if a telephone number-based URN namespace was 933 created, it is not clear that all telephone numbers would 934 immediately become "valid" URNs, that could be resolved using 935 whatever mechanisms are described as part of the namespace 936 registration. 938 Validation mechanisms might be: 939 - a syntax grammar; 940 - an on-line service; 941 - an off-line service. 942 } 944 Scope: 946 { 947 This section should outline the scope of the use of the 948 identifiers in this namespace. Apart from considerations of 949 private vs. public namespaces, this section is critical in 950 evaluating the applicability of a requested NID. For example, a 951 namespace claiming to deal with "social security numbers" should 952 have a global scope and address all social security number 953 structures (unlikely). On the other hand, at a national level, it 954 is reasonable to propose a URN namespace for "this nation's social 955 security numbers". 956 } 958 Appendix B. Illustration 960 B.1. Example Template 962 [[ Editorial Note: Do we really need this any more? 963 Such an almost-concrete example likely contradicts current IESG 964 policy on usage of examples in RFCs. ]] 966 The following example is provided for the purposes of illustrating 967 the URN NID template described in Appendix A. Although it is based 968 on a hypothetical "generic Internet namespace" that has been 969 discussed informally within the URN WG, there are still technical and 970 infrastructural issues that would have to be resolved before such a 971 namespace could be properly and completely described. 973 Namespace ID: 975 To be assigned 977 Registration Information: 979 - version number: 1 980 - date: 982 Declared registrant of the namespace: 984 - Registering organization: 985 Name: Thinking Cat Enterprises Name: Thinking Cat 986 Example Enterprises 987 Postal: 1 ThinkingCat Way 988 Trupville, NewCountry 989 - Designated contact person: 990 Name: L. Daigle 991 Email: leslie@thinkingcat.example 993 Declaration of syntactic structure of NSS part: 995 The namespace specific string structure is as follows: 997 : 999 where FQDN is a fully-qualified domain name, and the assigned 1000 string is conformant to URN syntax requirements. 1002 Relevant ancillary documentation: 1004 Definition of domain names, found in: 1006 P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, 1007 RFC 1034, November 1987. 1009 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 1010 STD 13, RFC 1035, November 1987. 1012 Conformance with URN Syntax: 1014 No special considerations. 1016 Rules for Lexical Equivalence of NSS part: 1018 FQDNs are case-insensitive. Thus, the leading portion of the URN 1019 up to the colon after the FQDN is case-insensitive for matches. 1020 The remainder of the identifier must be considered case-sensitive. 1022 Identifier uniqueness considerations: 1024 Uniqueness is guaranteed as long as the assigned string is never 1025 reassigned for a given FQDN, and that the FQDN is never 1026 reassigned. 1028 N.B.: operationally, there is nothing that prevents a domain name 1029 from being reassigned; indeed, it is not an uncommon occurrence. 1030 This is one of the reasons that this example makes a poor URN 1031 namespace in practice, and is therefore not seriously being 1032 proposed as it stands. 1034 Identifier persistence considerations: 1036 Persistence of identifiers is dependent upon suitable delegation 1037 of resolution at the level of "FQDN"s, and persistence of FQDN 1038 assignment. 1040 Same note as above. 1042 Process of identifier assignment: 1044 Assignment of these URNs is delegated to individual domain name 1045 holders (for FQDNs). The holder of the FQDN registration is 1046 required to maintain an entry (or delegate it) in the DDDS. 1047 Within each of these delegated name partitions, the string may be 1048 assigned per local requirements. 1050 E.g., urn:urn-:thinkingcat.example:001203 1052 Process for identifier resolution: 1054 Domain name holders are responsible for operating or delegating 1055 resolution servers for the FQDN in which they have assigned URNs. 1057 Validation mechanism: 1059 None specified. 1061 Scope: 1063 Global. 1065 B.2. Registration steps in practice 1067 The key steps for registration of informal or formal namespaces 1068 typically play out as follows: 1070 A) Informal NID: 1072 1. Complete the registration template. This may be done as part 1073 of an Internet-Draft. 1075 2. Communicate the registration template to urn-nid@ietf.org for 1076 technical review -- as an email with a pointer to the 1077 submitted I-D or inline text containing the template. 1079 3. Update the registration template (and/or document) as 1080 necessary from comments, and repeat steps 2 and 3 as 1081 necessary. 1083 4. Once comments have been addressed (and the review period has 1084 expired), send a request to IANA with the revised registration 1085 template. 1087 B) Formal NID: 1089 1. Write an Internet-Draft describing the namespace and include 1090 the registration template, duly completed. Be sure to include 1091 "Namespace Considerations", "Community Considerations", 1092 "Security Considerations", and "IANA Considerations" sections, 1093 as described in Section 4.4. 1095 2. Submit the Internet-Draft, and send a pointer to the I-D 1096 (perhaps using a copy of the I-D announcement) to 1097 urn-nid@ietf.org in order to solicit technical review. 1099 3. Update the Internet-Draft as necessary from comments, and 1100 repeat steps 2 and 3 as needed. 1102 4. If the Internet-Draft is the product of a working group in the 1103 IETF, follow the usual WG process to forward the document to 1104 the IESG for publication as an RFC. Otherwise, find a 1105 sponsoring Area Director willing to guide the draft through 1106 the IESG. The IESG (or the IETF at large in case an IETF-wide 1107 last call is deemed necessary) may request further changes 1108 (submitted as I-D revisions) and/or direct discussion to 1109 designated working groups, area experts, etc. 1111 5. The IESG evaluation process includes a review by IANA, and if 1112 the IESG approves the document for publication as an RFC, IANA 1113 processing of the document will follow the regular work-flow 1114 between the RFC Editor and IANA. This way, the NID 1115 registration will be made public by IANA when the RFC is 1116 published. 1118 Appendix C. Changes from RFC 3406 1120 C.1. Essential Changes since RFC 3406 1122 [ RFC Editor: please remove the Appendix C.1 headline and all 1123 subsequent subsections of Appendix C starting with Appendix C.2. ] 1125 T.B.D. (after consolidation of this memo) 1127 C.2. Changes from RFC 3406 to URNbis WG Draft -00 1129 o Abstract: rewritten entirely; 1131 o Section 1 (Introduction): added historical RFC information; 1133 o Section 1.1 (Requirements Language): added; 1135 o Section 3.1: added Note that challenges the utility of 1136 Experimental namespaces and raises question of whether formal 1137 "provisional" registrations would be useful; 1139 o Section 4: text expanded and updated; background material added; 1140 added Note to challenge IANA website practices; 1142 o Section 4.2 ff: changed "home" of URN-NID registration discussion 1143 list (it already had been moved to the IETF Secretariat servers); 1145 o Section 4.2: added Note to challenge the 2-week review period; in 1146 current practice, that is almost always exceeded, and some regard 1147 it as too short; 1149 o Section 4.3: largely clarified procedures as they happen in 1150 practice; adapted language for conformance with RFC 5226; use new 1151 home of URN-NID (as mentioned above); the registration template 1152 (Appendix A) now "SHOULD" be used; 1154 o Section 4.3: split off new Section 4.4 on Registration Documents, 1155 because registrants essentially are encouraged to follow these 1156 guidelines for Informal namespaces as well, as far as practical; 1157 replaced "RFC" by "Registration Document"; Section 4.4 is 1158 subdivided for all mandatory sections; 1160 o Section 4.4.1: made requirements a "MUST"; 1162 o Sections 4.4.1 and 4.4.2: added common Note that challenges the 1163 need to split Namespace and Community Considerations, based on 1164 observed problems in practice to separate the topics, and pointing 1165 to overlap with clauses in the registration template due to 1166 bullets listed that are not so clearly related to the headlines 1167 under which they appear; suggestion is to avoid duplication, place 1168 factual stuff into the template and focus on rationale in these 1169 Considerations, perhaps in a common section; 1171 o Section 4.4.3: added discussion of Security Considerations 1172 section; advice is to focus on namespace-specific considerations 1173 and refer to the SecCons in the "generic" RFCs for the general 1174 issues; 1176 o Section 4.4.4: amended discussion of IANA Considerations section; 1177 this tries to reflect standing practice and codifies that Formal 1178 NIDs are generally proposed by the registrant; added Note that 1179 "urn" is permanently reserved and MUST NOT be assigned as a NID, 1180 to avoid confusion (as also specified in RFC 2141bis draft); wrt 1181 registration maintenance: got rid of wrong reference in RFC 3406 1182 (to RFC 2606); 1184 o Section 6 (IANA Considerations): updated and rephrased description 1185 of the role of this document, including a sketch of the history; 1186 added teat that tries to precisely describe what is expected from 1187 IANA on approval of this draft; added text on procedures and 1188 suggest a provisional assignment practice upon "thumbs-up" of the 1189 IANA Expert to protect prospective registrants from collateral 1190 damage on NID precedence in case the document suffers from delays 1191 unrelated to the registration template before it eventually gets 1192 approved; 1194 o Section 7 (Acknowledgements): added; 1196 o References: Updated and amended references; added pointers to 1197 chartered URNbis work items; removed entirely outdated example 1198 material related to legacy documents; 1200 o Appendix A and B.1: added words on Security Considerations 1201 section; 1203 o Appendix A (Registration Template): clarified role of text 1204 snippets in the Template: hint and commentary now all enclosed in 1205 curly braces, with not that these parts shall be removed when 1206 filling in the tempalte; indicate that Formal NIDs are normally 1207 proposed by registrant; changed date/time ref. from ISO 8601 to 1208 RFC 3339; use inherited term "percent-encoding"; 1210 o Appendix A -- structure: moved formal clauses on Conformance with 1211 URN Syntax and Rules for Lexical Equivalence to vicinity of 1212 namespace specific syntax clause, to which these are closely 1213 related; 1215 o Appendix A -- changes of clauses: the Declaration of syntactic 1216 structure and Rules for Lexical Equivalence clauses now 1217 tentatively have been restricted to the NSS part only; this change 1218 is described in NOTEs and motivated by the observation of repeated 1219 confusion in past and present registration documents, which 1220 hopefully can be avoided (and the job of the Expert and reviewers 1221 made easier) by leaving discussion of the invariate parts that 1222 cannot be re-specified there at the single place where they belong 1223 to: the NID is fully specified in the initial clause, rules for 1224 the NID and the URI scheme name "urn" are inherited from RFC 1225 2141[bis] and RFC 3986, respectively, and hence the new clause 1226 descriptions avoid conflict by taking these components out of 1227 scope of these clauses; 1229 o Appendix B.1 (Example Template): facelifted a bit; concerns with 1230 IESG policy on examples in RFCs raised in a NOTE; 1232 o Appendix B.2 (Registration steps in practice): updated and 1233 clarified description of procedure, in alignment to current 1234 practice; 1236 o Appendix C: removed "Changes from RFC 2611"; added this change 1237 log; 1239 o General: numerous editorial changes and enhancements, following 1240 contemporary RFC style. 1242 Appendix D. Open Issues 1244 Discuss consequences of RFC 2141bis (once consensus is achieved); if 1245 proposal for fragment part is adopted, details need to be described 1246 per namespace that wants to adopt these possibilities, and maybe the 1247 registration template needs a new clause where this will be specified 1248 -- or the information has to be assigned to existing clauses. 1250 More elaboration on Services. Since RFC 2483 is considered outdated, 1251 but RFC 2483bis not yet a URNbis work item, we might need a registry 1252 for URN Services (initially populated from RFC 2483) that can be 1253 referred to in namespace registration documents, thus avoiding 1254 normative dependencies on a future RFC 2483bis. 1256 Also see the Editorial Notes interspersed in the body of this draft. 1258 What else? 1260 Author's Address 1262 Alfred Hoenes 1263 TR-Sys 1264 Gerlinger Str. 12 1265 Ditzingen D-71254 1266 Germany 1268 EMail: ah@TR-Sys.de