idnits 2.17.1 draft-ietf-urn-rfc2611bis-01.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 236 has weird spacing: '...n-forum discu...' == Line 327 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 (February 11, 2001) is 8447 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) == Unused Reference: 'RFC1737' is defined on line 423, 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: 9 errors (**), 0 flaws (~~), 4 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 August 11, 2001 D. van Gulik 4 Category: Best Current Practice WebWeaving 5 draft-ietf-urn-rfc2611bis-01.txt R. Iannella 6 IPR Systems 7 P. Faltstrom 8 Cisco 9 February 11, 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/ietf/1id-abstracts.txt 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. A URN namespace itself has an identifier in 113 order to 115 - ensure global uniqueness of URNs 116 - (where desired) provide a cue for the structure of the 117 identifier 119 For example, ISBNs and ISSNs are both collections of identifiers used 120 in the traditional publishing world; while there may be some number 121 (or numbers) that is both a valid ISBN identifier and ISSN 122 identifier, using different designators for the two collections 123 ensures that no two URNs will be the same for different resources. 125 The development of an identifier structure, and thereby a collection 126 of identifiers, is a process that is inherently dependent on the 127 requirements of the community defining the identifier, how they will 128 be assigned, and the uses to which they will be put. All of these 129 issues are specific to the individual community seeking to define a 130 namespace (e.g., publishing community, association of booksellers, 131 protocol developers, etc); they are beyond the scope of the IETF URN 132 work. 134 This document outlines the processes by which a collection of 135 identifiers satisfying certain constraints (uniqueness of assignment, 136 etc) can become a bona fide URN namespace by obtaining a NID. In a 137 nutshell, a template for the definition of the namespace is completed 138 for deposit with IANA, and a NID is assigned. The details of the 139 process and possibilities for NID strings are outlined below; first, 140 a template for the definition is provided. 142 3.0 URN Namespace (Registration) Types 143 There are 3 categories of URN namespaces defined here, distinguished 144 by expected level of service and required procedures for 145 registration. Registration processes for each of these namespace 146 types are given in Section 4.0. 148 3.1 Experimental Namespaces 150 These are not explicitly registered with IANA. They take the form 152 X- 154 No provision is made for avoiding collision of experimental NIDs; 155 they are intended for use within internal or limited experimental 156 contexts. 158 3.2 Informal Namespaces 160 These are fully fledged URN namespaces, with all the rights and 161 requirements associated thereto. Informal namespaces can be 162 registered in global registration services. They are required to 163 uphold the general principles of a well-managed URN namespace -- 164 providing persistent, unique identification of resources. Informal 165 and formal namespaces (described below) differ in the NID assignment. 166 IANA will assign an alphanumeric NID to registered informal 167 namespaces, per the process outlined in Section 4.0. 169 3.3 Formal Namespaces 171 A formal namespace may be requested, and IETF review sought, in cases 172 where the publication of the NID proposal and the underlying 173 namespace will provide benefit to an open and broad base of the 174 Internet community. That is, as in any open standards outcome, 175 publication of the NID proposal would allow persons not immediately 176 associated with the proposer to work with the identifiers, or 177 otherwise better carry out their own activities than if the NID 178 publication had not been made. Benefits are expected to be in the 179 form of open accessibility, interoperability, etc. 181 It is expected that Formal NIDs may be applied to namespaces where 182 some aspects are not fully open. For example, a namespace may make 183 use of an externally managed (proprietary) registry (as, e.g., ISBN 184 does), for assignment of URNs in the namespace, but it may still 185 provide broad community benefit if the services associated have 186 openly-published access protocols. 188 In addition to the basic registration information defined in the 189 registration template (in Appendix A), a formal namespace request 190 must be accompanied by documented considerations of the need for a 191 new namespace and the community benefit of formally establishing the 192 proposed URN namespace. 194 Additionally, since the goal of URNs is to provide persistent 195 identification, some consideration as to the longevity and 196 maintainability of the namespace must be given. The URN WG discussed 197 at length the issue of finding objective measures for predicting (a 198 priori) the continued success of a namespace. No conclusion was 199 reached -- much depends on factors that are completely beyond the 200 technical scope of the namespace. However, the collective experience 201 of the IETF community does contain a wealth of information on 202 technical factors that will prevent longevity of identification. The 203 IESG may elect not to publish a proposed namespace RFC if the IETF 204 community consensus is that it contains technical flaws that will 205 prevent (or seriously impair the possibility of) persistent 206 identification. 208 The kinds of things the URN WG discussed included: 209 - the organization maintaining the URN namespace should 210 demonstrate stability and ability to maintain the URN namespace 211 for a long time, and/or it should be clear how the namespace can 212 continue to be usable/useful if the organization ceases to be 213 able to foster it; 215 - it should demonstrate ability and competency at name assignment 216 in order to facilitate persistence (e.g. to minimize the 217 likelihood of conflicts); 219 - it should commit to not re-assigning existing names and allowing 220 old names to continue to be valid, even if the owners or 221 assignees of those names are no longer members or customers of 222 that organization. This does not mean that there must be 223 resolution of such names, but it does mean that they must not 224 resolve the name to false or stale information, and it means 225 that they must not be reassigned. 227 These aspects, though hard to quantify objectively, should be 228 considered by organizations/people considering the development of a 229 Formal URN namespace, and they will be kept in mind when evaluating 230 the technical merits of any proposed Formal namespace. 232 4.0 URN Namespace Registration, Update, and NID Assignment Process 234 Different levels of disclosure are expected/defined for namespaces. 236 According to the level of open-forum discussion surrounding the 237 disclosure, a URN namespace may be assigned or may request a 238 particular identifier. The "IANA Considerations" document [RFC2434] 239 suggests the need to specify update mechanisms for registrations -- 240 who is given the authority to do so, from time to time, and what are 241 the processes. Since URNs are meant to be persistently useful, few 242 (if any) changes should be made to the structural interpretation of 243 URN strings (e.g., adding or removing rules for lexical equivalence 244 that might affect the interpretation of URN IDs already assigned). 245 However, it may be important to introduce clarifications, expand the 246 list of authorized URN assigners, etc, over the natural course of a 247 namespace's lifetime. Specific processes are outlined below. 249 The official list of registered URN namespaces is maintained by IANA. 250 URN namespace registrations are currently being posted in the 251 anonymous FTP directory "ftp://ftp.isi.edu/in- 252 notes/iana/assignments/URN-namespaces/". See [STD2] for the current 253 location of IANA registry. 255 The registration and maintenance procedures vary slightly from one 256 namespace type (as defined in Section 3.0) to another. 258 4.1 Experimental 260 These are not explicitly registered with IANA. They take the form 262 X- 264 No provision is made for avoiding collision of experimental NIDs; 265 they are intended for use within internal or limited experimental 266 contexts. 268 As there is no registration, no registration maintenance procedures 269 are needed. 271 4.2 Informal 273 These are registered with IANA and are assigned a number sequence as 274 an identifier, in the format: 276 "urn-" 278 where is chosen by the IANA on a First Come First Served 279 basis (see [RFC2434]). 281 Registrants should send a copy of the registration template (see 282 Appendix A), duly completed, to the 284 urn-nid@apps.ietf.org 286 mailing and allow for a 2 week discussion period for clarifying the 287 expression of the registration information and suggestions for 288 improvements to the namespace proposal. 290 After suggestions for clarification of the registration information 291 have been incorporated, the template may be submitted to: 293 iana@iana.org 295 for assignment of a NID. 297 The only restrictions on are that it consist strictly of 298 digits and that it not cause the NID to exceed length limitations 299 outlined in the URN syntax ([RFC2141]). 301 Registrations may be updated by the original registrant, or an entity 302 designated by the registrant, by updating the registration template, 303 submitting it to the discussion list for a further 2 week discussion 304 period, and finally resubmitting it to IANA, as described above. 306 4.3 Formal 308 Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: 310 "IETF Consensus - New values are assigned through the IETF 311 consensus process. Specifically, new assignments are made via 312 RFCs approved by the IESG. Typically, the IESG will seek 313 input on prospective assignments from appropriate persons 314 (e.g., a relevant Working Group if one exists)." 316 Thus, the Formal NID application is made via publication of an RFC 317 through standard IETF processes. The RFC need not be standards- 318 track, but it will be subject to IESG review and acceptance pursuant 319 to the guidelines written here (as well as standard RFC publication 320 guidelines). The template defined in Appendix A may be included as 321 part of an RFC defining some other aspect of the namespace, or it may 322 be put forward as an RFC in its own right. The proposed template 323 should be sent to the 325 urn-nid@apps.ietf.org 327 mailing list to allow for a 2 week discussion period for clarifying 328 the expression of the registration information, before the IESG 329 reviews the document. 331 The RFC must include a "Namespace Considerations" section, which 332 outlines the perceived need for a new namespace (i.e., where existing 333 namespaces fall short of the proposer's requirements). 334 Considerations might include: 336 - URN assignment procedures 337 - URN resolution/delegation 338 - type of resources to be identified 339 - type of services to be supported 341 NOTE: It is expected that more than one namespace may serve the same 342 "functional" purpose; the intent of the "Namespace Considerations" 343 section is to provide a record of the proposer's "due diligence" in 344 exploring existing possibilities, for the IESG's consideration. 346 The RFC must also include a "Community Considerations" section, which 347 indicates the dimensions upon which the proposer expects the Internet 348 community to be able to benefit by publication of this namespace. 349 Potential considerations include: 351 - open assignment and use of identifiers within the namespace 352 - open operation of resolution servers for the namespace 353 (server) 354 - creation of software that can meaningfully resolve and 355 access services for the namespace (client) 357 A particular NID string is requested, and is assigned by IETF 358 consensus (as defined in [RFC2434]), with the additional constraints 359 that the NID string must 361 - not be an already-registered NID 362 - not start with "x-" (see Type I above) 363 - not start with "urn-" (see Type II above) 364 - not start with "XY-", where XY is any combination of 2 365 ASCII letters (see NOTE, below) 366 - be more than 2 letters long 368 NOTE: ALL two-letter combinations, and two-letter combinations 369 followed by "-" and any sequence of valid NID characters, are 370 reserved for potential use as countrycode- based NIDs for eventual 371 national registrations of URN namespaces. The definition and 372 scoping of rules for allocation of responsibility for such namespaces 373 is beyond the scope of this document. 375 Registrations may be revised by updating the RFC through standard 376 IETF RFC update mechanisms. Thus, proposals for updates may be made 377 by the original authors, other IETF participants, or the IESG. In 378 any case, the proposed updated template must be circulated on the 379 urn-nid discussion list, allowing for a 2 week review period. 381 5.0 Security Considerations 383 This document largely focuses on providing mechanisms for the 384 declaration of public information. Nominally, these declarations 385 should be of relatively low security profile, however there is always 386 the danger of "spoofing" and providing mis-information. Information 387 in these declarations should be taken as advisory. 389 6.0 IANA Considerations 391 This document outlines the processes for registering URN namespaces, 392 and has implications for the IANA in terms of registries to be 393 maintained. In all cases, the IANA should assign the appropriate NID 394 (informal or formal), as described above, once an IESG-designated 395 expert has confirmed that the requisite registration process steps 396 have been completed. 398 7.0 References 400 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange 401 formats - Information interchange - Representation of 402 dates and times" 404 [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing 405 Bibliographic Identifiers as Uniform Resource Names", RFC 406 2288, February 1998. 408 [RFCXXXX] Mealling, M., "URI Resolution using the Dynamic 409 Delegation Discovery System", RFCXXXX. 411 [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution 412 Using DNS", RFCYYYY. 414 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 416 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 417 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 418 October 1998. 420 [STD2] Reynolds, J, and J. Postel, "Assigned Numbers", STD 2, 421 October 1994. 423 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 424 Uniform Resource Names", RFC 1737, December 1994. 426 [RFC2276] Sollins, K., "Architectural Principles of Uniform 427 Resource Name Resolution", RFC 2276, January 1998. 429 8.0 Authors' Addresses 431 Leslie L. Daigle 432 Thinking Cat Enterprises 434 EMail: leslie@thinkingcat.com 436 Dirk-Willem van Gulik 437 WebWeaving 438 Plein 1813 - 5a 439 8545 HX Arnhem 440 The Netherlands 442 Phone: +39 0332 78 0014 (Phone and Fax) 443 EMail: Dirkx@webweaving.org 445 Renato Iannella 446 IPR Systems Pty Ltd. 448 EMail: renato@iprsystems.com 450 Patrik Faltstrom 451 Cisco Systems Inc 452 170 W Tasman Drive SJ-13/2 453 San Jose CA 95134 454 USA 456 EMail: paf@cisco.com 457 URL: http://www.cisco.com 459 9.0 Appendix A -- URN Namespace Definition Template 460 Definition of a URN namespace is accomplished by completing the 461 following information template. Apart from providing a mechanism for 462 disclosing structure of the URN namespace, this information is 463 designed to be useful for 465 - entities seeking to have a URN assigned in a namespace (if 466 applicable) 467 - entities seeking to provide URN resolvers for a namespace (if 468 applicable) 470 This is particularly important for communities evaluating the 471 possibility of using a portion of an existing URN namespace rather 472 than creating their own. 474 Information in the template is as follows: 476 Namespace ID: 477 Assigned by IANA. In some contexts, a particular one may be 478 requested (see below). 480 Registration Information: 482 This is information to identify the particular version of 483 registration information: 485 - registration version number: starting with 1, incrementing by 1 486 with each new version 487 - registration date: date submitted to the IANA, using the format 488 YYYY-MM-DD 490 as outlined in [ISO8601]. 492 Declared registrant of the namespace: 493 This includes: 494 Registering organization 495 Name 496 Address 497 Designated contact person 498 Name 499 Coordinates (at least one of: e-mail, phone, postal address) 501 Declaration of syntactic structure: 503 This section should outline any structural features of identifiers 504 in this namespace. At the very least, this description may be 505 used to introduce terminology used in other sections. This 506 structure may also be used for determining realistic 507 caching/shortcuts approaches; suitable caveats should be provided. 509 If there are any specific character encoding rules (e.g., which 510 character should always be used for single-quotes), these should 511 be listed here. 513 Answers might include, but are not limited to: 515 - the structure is opaque (no exposition) - a regular expression 516 for parsing the identifier into components, including naming 517 authorities 519 Relevant ancillary documentation: 521 This section should list any RFCs, standards, or other published 522 documentation that defines or explains all or part of the 523 namespace structure. 525 Answers might include, but are not limited to: 527 - RFCs outlining syntax of the namespace 528 - Other of the defining community's (e.g., ISO) documents 529 outlining syntax of the identifiers in the namespace 530 - Explanatory material introducing the namespace 532 Identifier uniqueness considerations: This section should address the 533 requirement that URN identifiers be assigned uniquely -- they are 534 assigned to at most one resource, and are not reassigned. 536 (Note that the definition of "resource" is fairly broad; for example, 537 information on "Today's Weather" might be considered a single 538 resource, although the content is dynamic.) 540 Possible answers include, but are not limited to: 542 - exposition of the structure of the identifiers, and partitioning 543 of the space of identifiers amongst assignment authorities which 544 are individually responsible for respecting uniqueness rules 545 - identifiers are assigned sequentially 546 - information is withheld; the namespace is opaque 548 Identifier persistence considerations: 550 Although non-reassignment of URN identifiers ensures that a URN 551 will persist in identifying a particular resource even after the 552 "lifetime of the resource", some consideration should be given to 553 the persistence of the usability of the URN. This is particularly 554 important in the case of URN namespaces providing global 555 resolution. 557 Possible answers include, but are not limited to: 559 - quality of service considerations 561 Process of identifier assignment: 563 This section should detail the mechanisms and/or authorities for 564 assigning URNs to resources. It should make clear whether 565 assignment is completely open, or if limited, how to become an 566 assigner of identifiers, and/or get one assigned by existing 567 assignment authorities. Answers could include, but are not 568 limited to: 570 - assignment is completely open, following a particular algorithm 571 - assignment is delegated to authorities recognized by a 572 particular organization (e.g., the Digital Object Identifier 573 Foundation controls the DOI assignment space and its delegation) 574 - assignment is completely closed (e.g., for a private 575 organization) 577 Process for identifier resolution: 579 If a namespace is intended to be accessible for global resolution, 580 it must be registerd in an RDS (Resolution Discovery System, see 581 [RFC2276]) such as DDDS. Resolution then proceeds according to 582 standard URI resolution processes, and the mechanisms of the RDS. 583 What this section should outline is the requirements for becoming 584 a recognized resolver of URNs in this namespace (and being so- 585 listed in the RDS registry). 587 Answers may include, but are not limited to: 589 - the namespace is not listed with an RDS; this is not relevant 590 - resolution mirroring is completely open, with a mechanism for 591 updating an appropriate RDS 592 - resolution is controlled by entities to which assignment has 593 been delegated 595 Rules for Lexical Equivalence: 597 If there are particular algorithms for determining equivalence 598 between two identifiers in the underlying namespace (hence, in the 599 URN string itself), rules can be provided here. 601 Some examples include: 603 - equivalence between hyphenated and non-hyphenated groupings in 604 the identifier string 605 - equivalence between single-quotes and double-quotes 606 - Namespace-defined equivalences between specific characters, such 607 as "character X with or without diacritic marks". 609 Note that these are not normative statements for any kind of best 610 practice for handling equivalences between characters; they are 611 statements limited to reflecting the namespace's own rules. 613 Conformance with URN Syntax: 615 This section should outline any special considerations required 616 for conforming with the URN syntax. This is particularly 617 applicable in the case of legacy naming systems that are used in 618 the context of URNs. 620 For example, if a namespace is used in contexts other than URNs, 621 it may make use of characters that are reserved in the URN syntax. 622 This section should flag any such characters, and outline 623 necessary mappings to conform to URN syntax. Normally, this will 624 be handled by hex encoding the symbol. 626 For example, see the section on SICIs in [RFC2288]. 628 Validation mechanism: 630 Apart from attempting resolution of a URN, a URN namespace may 631 provide mechanism for "validating" a URN -- i.e., determining 632 whether a given string is currently a validly-assigned URN. For 633 example, even if an ISBN URN namespace is created, it is not clear 634 that all ISBNs will translate directly into "assigned URNs". 636 A validation mechanims might be: 638 - a syntax grammar 639 - an on-line service 640 - an off-line service 642 Scope: 644 This section should outline the scope of the use of the 645 identifiers in this namespace. Apart from considerations of 646 private vs. public namespaces, this section is critical in 647 evaluating the applicability of a requested NID. For example, a 648 namespace claiming to deal in "social security numbers" should 649 have a global scope and address all social security number 650 structures (unlikely). On the other hand, at a national level, it 651 is reasonable to propose a URN namespace for "this nation's social 652 security numbers". 654 10.0 Appendix B -- Illustration 656 10.1 Example Template 658 The following example is provided for the purposes of illustration of 659 the URN NID template described in Appendix A. Although it is based 660 on a hypothetical "generic Internet namespace" that has been 661 discussed informally within the URN WG, there are still technical and 662 infrastructural issues that would have to be resolved before such a 663 namespace could be properly and completely described. 665 Namespace ID: 666 To be assigned 668 Registration Information: 670 Version 1 671 Date: 673 Declared registrant of the namespace: 675 Name: Thinking Cat Enterprises 676 Address: 1 ThinkingCat Way 677 Trupville, NewCountry 678 Contact: L. Daigle 679 E-mail: leslie@thinkingcat.com 681 Declaration of structure: 683 The identifier structure is as follows: 685 URN::: 687 where FQDN is a fully-qualified domain name, and the assigned 688 string is conformant to URN syntax requirements. 690 Relevant ancillary documentation: 692 Definition of domain names, found in: 694 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 695 RFC1035, November 1987. 697 Identifier uniqueness considerations: 699 Uniqueness is guaranteed as long as the assigned string is never 700 reassigned for a given FQDN, and that the FQDN is never 701 reassigned. 703 N.B.: operationally, there is nothing that prevents a domain name 704 from being reassigned; indeed, it is not an uncommon occurrence. 705 This is one of the reasons that this example makes a poor URN 706 namespace in practice, and is therefore not seriously being 707 proposed as it stands. 709 Identifier persistence considerations: 711 Persistence of identifiers is dependent upon suitable delegation 712 of resolution at the level of "FQDN"s, and persistence of FQDN 713 assignment. 715 Same note as above. 717 Process of identifier assignment: 719 Assignment of these URNs delegated to individual domain name 720 holders (for FQDNs). The holder of the FQDN registration is 721 required to maintain an entry (or delegate it) in the DDDS. 722 Within each of these delegated name partitions, the string may be 723 assigned per local requirements. 725 e.g. urn::thinkingcat.com:001203 727 Process for identifier resolution: 729 Domain name holders are responsible for operating or delegating 730 resolution servers for the FQDN in which they have assigned URNs. 732 Rules for Lexical Equivalence: 734 FQDNs are case-insensitive. Thus, the portion of the URN 736 urn::: 738 is case-insenstive for matches. The remainder of the identifier 739 must be considered case-sensitve. 741 Conformance with URN Syntax: 743 No special considerations. 745 Validation mechanism: 747 None specified. 749 Scope: 751 Global. 753 10.2 Registration steps in practice 755 The key steps for registration of informal or formal namespaces 756 typically play out as follows: 758 Informal NID: 760 1. Complete the registration template. This may be done as part 761 of an Internet-Draft. 763 2. Communicate the registration template to urn-nid@apps.ietf.org 764 for technical review -- as a published I-D, or text e-mail message 765 containing the template. 767 3. Update the registration template as necessary from comments, and 768 repeat steps 2 and 3 as necessary. 770 4. Once comments have been addressed (and the review period has 771 expired) end a request to IANA with the revised registration 772 template. 774 Formal NID: 776 1. Write an Internet-Draft describing the namespace and including 777 the registration template, duly completed. 779 2. Send the Internet-Draft to the I-D editor, and send a copy to 780 urn-nid@apps.ietf.org for technical review. 782 3. Update the Internet-Draft as necessary from comments, and repeat 783 steps 2 and 3 as needed. 785 4. Send a request to the IESG to publish the I-D as an RFC. The 786 IESG may request further changes (published as I-D revisions) 787 and/or direct discussion to designated working groups, area 788 experts, etc. 790 5. If the IESG approves the document for publication as an RFC, 791 send a request to IANA to register the requested NID.