idnits 2.17.1 draft-ietf-urn-rfc2611bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2288], [RFCXXXX], [RFCYYYY], [RFC2141]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC2288, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC2611, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 41 has weird spacing: '...rt from proof...' == Line 245 has weird spacing: '...n-forum discu...' == Line 337 has weird spacing: '... period for c...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 7, 2001) is 8390 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) == Missing Reference: 'RFC2606' is mentioned on line 391, but not defined == Missing Reference: 'RFC2611' is mentioned on line 414, but not defined ** Obsolete undefined reference: RFC 2611 (Obsoleted by RFC 3406) == Unused Reference: 'RFC2026' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC1737' is defined on line 444, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO8601' ** Downref: Normative reference to an Informational RFC: RFC 2288 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCYYYY' ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'STD2' ** Downref: Normative reference to an Informational RFC: RFC 1737 ** Downref: Normative reference to an Informational RFC: RFC 2276 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft L. Daigle 2 URN WG Thinking Cat Enterprises 3 Expires November 7, 2001 D. van Gulik 4 Category: Best Current Practice WebWeaving 5 draft-ietf-urn-rfc2611bis-03.txt R. Iannella 6 IPR Systems 7 P. Faltstrom 8 Cisco 9 May 7, 2001 11 URN Namespace Definition Mechanisms 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The URN WG has defined a syntax for Uniform Resource Names (URNs) 38 [RFC2141], as well as some proposed mechanisms for their resolution 39 and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole 40 rests on the concept of individual "namespaces" within the URN 41 structure. Apart from proof-of-concept namespaces, the use of 42 existing identifiers in URNs has been discussed ([RFC2288]), and this 43 document lays out general definitions of and mechanisms for 44 establishing URN "namespaces". 46 This document obsoletes RFC2611. 48 Discussion of this document should be directed to urn-ietf@ietf.org 50 Table of Contents 52 Abstract ........................................................ 53 Table of Contents ............................................... 54 1.0 Introduction ................................................ 55 2.0 What is a URN Namespace? .................................... 56 3.0 URN Namespace (Registration) Types .......................... 57 3.1 Experimental Namespaces ..................................... 58 3.2 Informal Namespaces ......................................... 59 3.3 Formal Namespaces ........................................... 60 4.0 URN Namespace Registration, Update, and NID Assignment 61 Process ..................................................... 62 4.1 Experimental ................................................ 63 4.2 Informal .................................................... 64 4.3 Formal ...................................................... 65 5.0 Security Considerations ..................................... 66 6.0 IANA Considerations ......................................... 67 7.0 References .................................................. 68 8.0 Authors' Addresses .......................................... 69 9.0 Appendix A -- URN Namespace Definition Template ............. 70 10.0 Appendix B -- Illustration ................................. 71 10.1 Example Template ........................................... 72 10.2 Registration steps in practice ............................. 74 1.0 Introduction 76 Uniform Resource Names (URNs) are resource identifiers with the 77 specific requirements for enabling location independent 78 identification of a resource, as well as longevity of reference. 79 There are 2 assumptions that are key to this document: 81 Assumption #1: 83 Assignment of a URN is a managed process. 85 I.e., not all strings that conform to URN syntax are necessarily 86 valid URNs. A URN is assigned according to the rules of a 87 particular namespace (in terms of syntax, semantics, and process). 89 Assumption #2: 91 The space of URN namespaces is managed. 93 I.e., not all syntactically correct URN namespaces (per the URN 94 syntax definition) are valid URN namespaces. A URN namespace 95 must have a recognized definition in order to be valid. 97 The purpose of this document is to outline a mechanism and provide a 98 template for explicit namespace definition, along with the mechanism 99 for associating an identifier (called a "Namespace ID", or NID) which 100 is registered with the Internet Assigned Numbers Authority, IANA. 102 Note that this document restricts itself to the description of 103 processes for the creation of URN namespaces. If "resolution" of any 104 so-created URN identifiers is desired, a separate process of 105 registration in a global NID directory, such as that provided by the 106 DDDS system [RFCXXXX], is necessary. See [RFCYYYY] for information 107 on obtaining registration in the DDDS global NID directory. 109 2.0 What is a URN Namespace? 111 For the purposes of URNs, a "namespace" is a collection of uniquely- 112 assigned identifiers. That is, the identifiers are not ever assigned 113 to more than 1 resource, nor are they ever re-assigned to a different 114 resource. A single resource, however, may have more than one URN 115 assigned to it for different purposes. A URN namespace itself has an 116 identifier in order to 118 - ensure global uniqueness of URNs 119 - (where desired) provide a cue for the structure of the 120 identifier 122 For example, many identifier systems make use strings of numbers as 123 identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that 124 there might be some numbers that are valid identifiers in two 125 different established identifier systems. Using different 126 designators for the two collections ensures that no two URNs will be 127 the same for different resources (since each collection is required 128 to uniquely assign each identifier). 130 The development of an identifier structure, and thereby a collection 131 of identifiers, is a process that is inherently dependent on the 132 requirements of the community defining the identifier, how they will 133 be assigned, and the uses to which they will be put. All of these 134 issues are specific to the individual community seeking to define a 135 namespace (e.g., publishing community, association of booksellers, 136 protocol developers, etc); they are beyond the scope of the IETF URN 137 work. 139 This document outlines the processes by which a collection of 140 identifiers satisfying certain constraints (uniqueness of assignment, 141 etc) can become a bona fide URN namespace by obtaining a NID. In a 142 nutshell, a template for the definition of the namespace is completed 143 for deposit with IANA, and a NID is assigned. The details of the 144 process and possibilities for NID strings are outlined below. 146 3.0 URN Namespace (Registration) Types 148 There are 3 categories of URN namespaces defined here, distinguished 149 by expected level of service and required procedures for 150 registration. Registration processes for each of these namespace 151 types are given in Section 4.0. 153 3.1 Experimental Namespaces 155 These are not explicitly registered with IANA. They take the form 157 X- 159 No provision is made for avoiding collision of experimental NIDs; 160 they are intended for use within internal or limited experimental 161 contexts. 163 3.2 Informal Namespaces 165 These are fully fledged URN namespaces, with all the rights and 166 requirements associated thereto. Informal namespaces can be 167 registered in global registration services. They are required to 168 uphold the general principles of a well-managed URN namespace -- 169 providing persistent identification of resources, and unique 170 assignment of identifier strings. Informal and formal namespaces 171 (described below) differ in the NID assignment. IANA will assign an 172 alphanumeric NID to registered informal namespaces, per the process 173 outlined in Section 4.0. 175 3.3 Formal Namespaces 177 A formal namespace may be requested, and IETF review sought, in cases 178 where the publication of the NID proposal and the underlying 179 namespace will provide benefit to some subset of users on the 180 Internet. That is, a formal NID proposal, if accepted, must be 181 functional on and with the global Internet, not limited to users in 182 communities or networks not connected to the Internet. For example, a 183 NID is requested that is meant for naming of physics research. If 184 that NID request required that the user use a propietary network or 185 service that was not at all open to the general Internet user then it 186 would make a poor request for a formal NID. The intent is that, while 187 the community of those who may actively use the names assigned within 188 that NID may be small (but no less important), the potential use of 189 names within that NID is open to any user on the Internet. 191 It is expected that Formal NIDs may be applied to namespaces where 192 some aspects are not fully open. For example, a namespace may make 193 use of a fee-based, privately managed, or proprietary registry for 194 assignment of URNs in the namespace, but it may still provide benefit 195 to some Internet users if the services associated have openly- 196 published access protocols. 198 In addition to the basic registration information defined in the 199 registration template (in Appendix A), a formal namespace request 200 must be accompanied by documented considerations of the need for a 201 new namespace and the community benefit of formally establishing the 202 proposed URN namespace. 204 Additionally, since the goal of URNs is to provide persistent 205 identification, some consideration as to the longevity and 206 maintainability of the namespace must be given. The URN WG discussed 207 at length the issue of finding objective measures for predicting (a 208 priori) the continued success of a namespace. No conclusion was 209 reached -- much depends on factors that are completely beyond the 210 technical scope of the namespace. However, the collective experience 211 of the IETF community does contain a wealth of information on 212 technical factors that will prevent longevity of identification. The 213 IESG may elect not to publish a proposed namespace RFC if the IETF 214 community consensus is that it contains technical flaws that will 215 prevent (or seriously impair the possibility of) persistent 216 identification. 218 The kinds of things the URN WG discussed included: 219 - the organization maintaining the URN namespace should 220 demonstrate stability and ability to maintain the URN namespace 221 for a long time, and/or it should be clear how the namespace can 222 continue to be usable/useful if the organization ceases to be 223 able to foster it; 225 - it should demonstrate ability and competency at name assignment 226 in order to facilitate persistence (e.g. to minimize the 227 likelihood of conflicts); 229 - it should commit to not re-assigning existing names and allowing 230 old names to continue to be valid, even if the owners or 231 assignees of those names are no longer members or customers of 232 that organization. This does not mean that there must be 233 resolution of such names, but it does mean that they must not 234 resolve the name to false or stale information, and it means 235 that they must not be reassigned. 237 These aspects, though hard to quantify objectively, should be 238 considered by organizations/people considering the development of a 239 Formal URN namespace, and they will be kept in mind when evaluating 240 the technical merits of any proposed Formal namespace. 242 4.0 URN Namespace Registration, Update, and NID Assignment Process 244 Different levels of disclosure are expected/defined for namespaces. 245 According to the level of open-forum discussion surrounding the 246 disclosure, a URN namespace may be assigned or may request a 247 particular identifier. The "IANA Considerations" document [RFC2434] 248 suggests the need to specify update mechanisms for registrations -- 249 who is given the authority to do so, from time to time, and what are 250 the processes. Since URNs are meant to be persistently useful, few 251 (if any) changes should be made to the structural interpretation of 252 URN strings (e.g., adding or removing rules for lexical equivalence 253 that might affect the interpretation of URN IDs already assigned). 254 However, it may be important to introduce clarifications, expand the 255 list of authorized URN assigners, etc, over the natural course of a 256 namespace's lifetime. Specific processes are outlined below. 258 The official list of registered URN namespaces is maintained by IANA. 259 URN namespace registrations are currently being posted in the 260 anonymous FTP directory 262 ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/ 264 See [STD2] for the current location of IANA registry. 266 The registration and maintenance procedures vary slightly from one 267 namespace type (as defined in Section 3.0) to another. 269 4.1 Experimental 271 These are not explicitly registered with IANA. They take the form 273 X- 275 No provision is made for avoiding collision of experimental NIDs; 276 they are intended for use within internal or limited experimental 277 contexts. 279 As there is no registration, no registration maintenance procedures 280 are needed. 282 4.2 Informal 283 These are registered with IANA and are assigned a number sequence as 284 an identifier, in the format: 286 "urn-" 288 where is chosen by the IANA on a First Come First Served 289 basis (see [RFC2434]). 291 Registrants should send a copy of the registration template (see 292 Appendix A), duly completed, to the 294 urn-nid@apps.ietf.org 296 mailing and allow for a 2 week discussion period for clarifying the 297 expression of the registration information and suggestions for 298 technical improvements to the namespace proposal. 300 After suggestions for clarification of the registration information 301 have been incorporated, the template may be submitted to: 303 iana@iana.org 305 for assignment of a NID. 307 The only restrictions on are that it consist strictly of 308 digits and that it not cause the NID to exceed length limitations 309 outlined in the URN syntax ([RFC2141]). 311 Registrations may be updated by the original registrant, or an entity 312 designated by the registrant, by updating the registration template, 313 submitting it to the discussion list for a further 2 week discussion 314 period, and finally resubmitting it to IANA, as described above. 316 4.3 Formal 318 Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: 320 "IETF Consensus - New values are assigned through the IETF 321 consensus process. Specifically, new assignments are made via 322 RFCs approved by the IESG. Typically, the IESG will seek 323 input on prospective assignments from appropriate persons 324 (e.g., a relevant Working Group if one exists)." 326 Thus, the Formal NID application is made via publication of an RFC 327 through standard IETF processes. The RFC need not be standards- 328 track, but it will be subject to IESG review and acceptance pursuant 329 to the guidelines written here (as well as standard RFC publication 330 guidelines). The template defined in Appendix A may be included as 331 part of an RFC defining some other aspect of the namespace, or it may 332 be put forward as an RFC in its own right. The proposed template 333 should be sent to the 335 urn-nid@apps.ietf.org 337 mailing list to allow for a 2 week discussion period for clarifying 338 the expression of the registration information, before the IESG 339 reviews the document. 341 The RFC must include a "Namespace Considerations" section, which 342 outlines the perceived need for a new namespace (i.e., where existing 343 namespaces fall short of the proposer's requirements). 344 Considerations might include: 346 - URN assignment procedures 347 - URN resolution/delegation 348 - type of resources to be identified 349 - type of services to be supported 351 NOTE: It is expected that more than one namespace may serve the same 352 "functional" purpose; the intent of the "Namespace Considerations" 353 section is to provide a record of the proposer's "due diligence" in 354 exploring existing possibilities, for the IESG's consideration. 356 The RFC must also include a "Community Considerations" section, which 357 indicates the dimensions upon which the proposer expects its 358 community to be able to benefit by publication of this namespace as 359 well as how a general Internet user will be able to use the space if 360 they care to do so. Potential considerations include: 362 - open assignment and use of identifiers within the namespace 363 - open operation of resolution servers for the namespace 364 (server) 365 - creation of software that can meaningfully resolve and 366 access services for the namespace (client) 368 The RFC must include an "IANA Considerations" section, indicating 369 that the document includes a URN NID registration that is to be 370 entered into the IANA registry of URN NIDs. 372 A particular NID string is requested, and is assigned by IETF 373 consensus (as defined in [RFC2434]), with the additional constraints 374 that the NID string must 376 - not be an already-registered NID 377 - not start with "x-" (see Type I above) 378 - not start with "urn-" (see Type II above) 379 - not start with "XY-", where XY is any combination of 2 380 ASCII letters (see NOTE, below) 381 - be more than 2 letters long 383 NOTE: ALL two-letter combinations, and two-letter combinations 384 followed by "-" and any sequence of valid NID characters, are 385 reserved for potential use as countrycode- based NIDs for eventual 386 national registrations of URN namespaces. The definition and 387 scoping of rules for allocation of responsibility for such namespaces 388 is beyond the scope of this document. 390 Registrations may be revised by updating the RFC through standard 391 IETF RFC update processes (see [RFC2606] for a discussion of IETF 392 process). In any case, a revised document, in the form of a new 393 Internet-Draft, must be published, and the proposed updated template 394 must be circulated on the urn-nid discussion list, allowing for a 2 395 week review period before pursuing publication of the new RFC 396 document. 398 5.0 Security Considerations 400 This document largely focuses on providing mechanisms for the 401 declaration of public information. Nominally, these declarations 402 should be of relatively low security profile, however there is always 403 the danger of "spoofing" and providing mis-information. Information 404 in these declarations should be taken as advisory. 406 6.0 IANA Considerations 408 This document outlines the processes for registering URN namespaces, 409 and has implications for the IANA in terms of registries to be 410 maintained. In all cases, the IANA should assign the appropriate NID 411 (informal or formal), as described above, once an IESG-designated 412 expert has confirmed that the requisite registration process steps 413 have been completed. This document defines processes to replace 414 those outlined in [RFC2611]. 416 7.0 References 418 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange 419 formats - Information interchange - Representation of 420 dates and times" 422 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 423 3", RFC 2026, October 1996. 425 [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing 426 Bibliographic Identifiers as Uniform Resource Names", RFC 427 2288, February 1998. 429 [RFCXXXX] Mealling, M., "URI Resolution using the Dynamic 430 Delegation Discovery System", RFCXXXX. 432 [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution 433 Using DNS", RFCYYYY. 435 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 437 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 438 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 439 October 1998. 441 [STD2] Reynolds, J, and J. Postel, "Assigned Numbers", STD 2, 442 October 1994. 444 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 445 Uniform Resource Names", RFC 1737, December 1994. 447 [RFC2276] Sollins, K., "Architectural Principles of Uniform 448 Resource Name Resolution", RFC 2276, January 1998. 450 8.0 Authors' Addresses 452 Leslie L. Daigle 453 Thinking Cat Enterprises 455 EMail: leslie@thinkingcat.com 457 Dirk-Willem van Gulik 458 WebWeaving 459 Plein 1813 - 5a 460 8545 HX Arnhem 461 The Netherlands 463 Phone: +39 0332 78 0014 (Phone and Fax) 464 EMail: Dirkx@webweaving.org 466 Renato Iannella 467 IPR Systems Pty Ltd. 469 EMail: renato@iprsystems.com 471 Patrik Faltstrom 472 Cisco Systems Inc 473 170 W Tasman Drive SJ-13/2 474 San Jose CA 95134 475 USA 477 EMail: paf@cisco.com 478 URL: http://www.cisco.com 480 9.0 Appendix A -- URN Namespace Definition Template 482 Definition of a URN namespace is accomplished by completing the 483 following information template. Apart from providing a mechanism for 484 disclosing structure of the URN namespace, this information is 485 designed to be useful for 487 - entities seeking to have a URN assigned in a namespace (if 488 applicable) 489 - entities seeking to provide URN resolvers for a namespace (if 490 applicable) 492 This is particularly important for communities evaluating the 493 possibility of using a portion of an existing URN namespace rather 494 than creating their own. 496 Applications for Formal URN namespaces must also document "Namespace 497 Considerations", "Community Considerations" and "IANA 498 Considerations", as described in Section 4.3. 500 Information in the template is as follows: 502 Namespace ID: 503 Assigned by IANA. In the case of a Formal NID registration, 504 a particular NID string may be requested. 506 Registration Information: 508 This is information to identify the particular version of 509 registration information: 511 - registration version number: starting with 1, incrementing by 1 512 with each new version 513 - registration date: date submitted to the IANA, using the format 514 YYYY-MM-DD 516 as outlined in [ISO8601]. 518 Declared registrant of the namespace: 519 This includes: 520 Registering organization 521 Name 522 Address 523 Designated contact person 524 Name 525 Coordinates (at least one of: e-mail, phone, postal address) 527 Declaration of syntactic structure: 529 This section should outline any structural features of identifiers 530 in this namespace. At the very least, this description may be 531 used to introduce terminology used in other sections. This 532 structure may also be used for determining realistic 533 caching/shortcuts approaches; suitable caveats should be provided. 534 If there are any specific character encoding rules (e.g., which 535 character should always be used for single-quotes), these should 536 be listed here. 538 Answers might include, but are not limited to: 540 - the structure is opaque (no exposition) - a regular expression 541 for parsing the identifier into components, including naming 542 authorities 544 Relevant ancillary documentation: 546 This section should list any RFCs, standards, or other published 547 documentation that defines or explains all or part of the 548 namespace structure. 550 Answers might include, but are not limited to: 552 - RFCs outlining syntax of the namespace 553 - Other of the defining community's (e.g., ISO) documents 554 outlining syntax of the identifiers in the namespace 555 - Explanatory material introducing the namespace 557 Identifier uniqueness considerations: This section should address the 558 requirement that URN identifiers be assigned uniquely -- they are 559 assigned to at most one resource, and are not reassigned. 561 (Note that the definition of "resource" is fairly broad; for example, 562 information on "Today's Weather" might be considered a single 563 resource, although the content is dynamic.) 565 Possible answers include, but are not limited to: 567 - exposition of the structure of the identifiers, and partitioning 568 of the space of identifiers amongst assignment authorities which 569 are individually responsible for respecting uniqueness rules 570 - identifiers are assigned sequentially 571 - information is withheld; the namespace is opaque 573 Identifier persistence considerations: 575 Although non-reassignment of URN identifiers ensures that a URN 576 will persist in identifying a particular resource even after the 577 "lifetime of the resource", some consideration should be given to 578 the persistence of the usability of the URN. This is particularly 579 important in the case of URN namespaces providing global 580 resolution. 582 Possible answers include, but are not limited to: 584 - quality of service considerations 586 Process of identifier assignment: 588 This section should detail the mechanisms and/or authorities for 589 assigning URNs to resources. It should make clear whether 590 assignment is completely open, or if limited, how to become an 591 assigner of identifiers, and/or get one assigned by existing 592 assignment authorities. Answers could include, but are not 593 limited to: 595 - assignment is completely open, following a particular algorithm 596 - assignment is delegated to authorities recognized by a 597 particular organization (e.g., the Digital Object Identifier 598 Foundation controls the DOI assignment space and its delegation) 599 - assignment is completely closed (e.g., for a private 600 organization) 602 Process for identifier resolution: 604 If a namespace is intended to be accessible for global resolution, 605 it must be registerd in an RDS (Resolution Discovery System, see 606 [RFC2276]) such as DDDS. Resolution then proceeds according to 607 standard URI resolution processes, and the mechanisms of the RDS. 608 What this section should outline is the requirements for becoming 609 a recognized resolver of URNs in this namespace (and being so- 610 listed in the RDS registry). 612 Answers may include, but are not limited to: 614 - the namespace is not listed with an RDS; this is not relevant 615 - resolution mirroring is completely open, with a mechanism for 616 updating an appropriate RDS 617 - resolution is controlled by entities to which assignment has 618 been delegated 620 Rules for Lexical Equivalence: 622 If there are particular algorithms for determining equivalence 623 between two identifiers in the underlying namespace (hence, in the 624 URN string itself), rules can be provided here. 626 Some examples include: 628 - equivalence between hyphenated and non-hyphenated groupings in 629 the identifier string 630 - equivalence between single-quotes and double-quotes 631 - Namespace-defined equivalences between specific characters, such 632 as "character X with or without diacritic marks". 634 Note that these are not normative statements for any kind of best 635 practice for handling equivalences between characters; they are 636 statements limited to reflecting the namespace's own rules. 638 Conformance with URN Syntax: 640 This section should outline any special considerations required 641 for conforming with the URN syntax. This is particularly 642 applicable in the case of legacy naming systems that are used in 643 the context of URNs. 645 For example, if a namespace is used in contexts other than URNs, 646 it may make use of characters that are reserved in the URN syntax. 647 This section should flag any such characters, and outline 648 necessary mappings to conform to URN syntax. Normally, this will 649 be handled by hex encoding the symbol. 651 For example, see the section on SICIs in [RFC2288]. 653 Validation mechanism: 655 Apart from attempting resolution of a URN, a URN namespace may 656 provide mechanism for "validating" a URN -- i.e., determining 657 whether a given string is currently a validly-assigned URN. 658 There are 2 issues here: 1) users should not "guess" URNs in a 659 namespace; 2) when the URN namespace is based on an existing 660 identifier system, it may not be the case that all the existing 661 identifiers are assigned on Day 0. The reasonable expectation is 662 that the 663 resource associated with each resulting URN is somehow related to 664 the 665 thing identified by the original identifier system, but those 666 resources may not exist for each original identifier. For 667 example, even if a telephone number-based URN namespace was 668 created, 669 it is not clear that all telephone numbers would immediately 670 become 671 "valid" URNs, that could be resolved using whatever mechanisms 672 are described as part of the namespace registration. 674 A validation mechanims might be: 676 - a syntax grammar 677 - an on-line service 678 - an off-line service 680 Scope: 682 This section should outline the scope of the use of the 683 identifiers in this namespace. Apart from considerations of 684 private vs. public namespaces, this section is critical in 685 evaluating the applicability of a requested NID. For example, a 686 namespace claiming to deal in "social security numbers" should 687 have a global scope and address all social security number 688 structures (unlikely). On the other hand, at a national level, it 689 is reasonable to propose a URN namespace for "this nation's social 690 security numbers". 692 10.0 Appendix B -- Illustration 694 10.1 Example Template 696 The following example is provided for the purposes of illustration of 697 the URN NID template described in Appendix A. Although it is based 698 on a hypothetical "generic Internet namespace" that has been 699 discussed informally within the URN WG, there are still technical and 700 infrastructural issues that would have to be resolved before such a 701 namespace could be properly and completely described. 703 Namespace ID: 705 To be assigned 707 Registration Information: 709 Version 1 710 Date: 712 Declared registrant of the namespace: 714 Name: Thinking Cat Enterprises 715 Address: 1 ThinkingCat Way 716 Trupville, NewCountry 717 Contact: L. Daigle 718 E-mail: leslie@thinkingcat.com 720 Declaration of structure: 722 The identifier structure is as follows: 724 URN::: 726 where FQDN is a fully-qualified domain name, and the assigned 727 string is conformant to URN syntax requirements. 729 Relevant ancillary documentation: 731 Definition of domain names, found in: 733 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 734 RFC1035, November 1987. 736 Identifier uniqueness considerations: 738 Uniqueness is guaranteed as long as the assigned string is never 739 reassigned for a given FQDN, and that the FQDN is never 740 reassigned. 742 N.B.: operationally, there is nothing that prevents a domain name 743 from being reassigned; indeed, it is not an uncommon occurrence. 744 This is one of the reasons that this example makes a poor URN 745 namespace in practice, and is therefore not seriously being 746 proposed as it stands. 748 Identifier persistence considerations: 750 Persistence of identifiers is dependent upon suitable delegation 751 of resolution at the level of "FQDN"s, and persistence of FQDN 752 assignment. 754 Same note as above. 756 Process of identifier assignment: 758 Assignment of these URNs delegated to individual domain name 759 holders (for FQDNs). The holder of the FQDN registration is 760 required to maintain an entry (or delegate it) in the DDDS. 761 Within each of these delegated name partitions, the string may be 762 assigned per local requirements. 764 e.g. urn::thinkingcat.com:001203 766 Process for identifier resolution: 768 Domain name holders are responsible for operating or delegating 769 resolution servers for the FQDN in which they have assigned URNs. 771 Rules for Lexical Equivalence: 773 FQDNs are case-insensitive. Thus, the portion of the URN 775 urn::: 777 is case-insenstive for matches. The remainder of the identifier 778 must be considered case-sensitve. 780 Conformance with URN Syntax: 782 No special considerations. 784 Validation mechanism: 786 None specified. 788 Scope: 790 Global. 792 10.2 Registration steps in practice 794 The key steps for registration of informal or formal namespaces 795 typically play out as follows: 797 Informal NID: 799 1. Complete the registration template. This may be done as part 800 of an Internet-Draft. 802 2. Communicate the registration template to urn-nid@apps.ietf.org 803 for technical review -- as a published I-D, or text e-mail message 804 containing the template. 806 3. Update the registration template as necessary from comments, and 807 repeat steps 2 and 3 as necessary. 809 4. Once comments have been addressed (and the review period has 810 expired) end a request to IANA with the revised registration 811 template. 813 Formal NID: 815 1. Write an Internet-Draft describing the namespace and including 816 the registration template, duly completed. Be sure to include 817 "Namespace Considerations", "Community Considerations" and "IANA 818 Considerations" sections, as described in Section 4.3. 820 2. Send the Internet-Draft to the I-D editor, and send a copy to 821 urn-nid@apps.ietf.org for technical review. 823 3. Update the Internet-Draft as necessary from comments, and repeat 824 steps 2 and 3 as needed. 826 4. Send a request to the IESG to publish the I-D as an RFC. The 827 IESG may request further changes (published as I-D revisions) 828 and/or direct discussion to designated working groups, area 829 experts, etc. 831 5. If the IESG approves the document for publication as an RFC, 832 send a request to IANA to register the requested NID.