idnits 2.17.1 draft-ietf-urn-rfc2611bis-02.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. 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 40 has weird spacing: '...rt from proof...' == Line 238 has weird spacing: '...n-forum discu...' == Line 329 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 (March 1, 2001) is 8456 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: 'RFC2611' is mentioned on line 404, but not defined ** Obsolete undefined reference: RFC 2611 (Obsoleted by RFC 3406) == Unused Reference: 'RFC1737' is defined on line 431, 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: 11 errors (**), 0 flaws (~~), 5 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 September 1, 2001 D. van Gulik 4 Category: Best Current Practice WebWeaving 5 draft-ietf-urn-rfc2611bis-02.txt R. Iannella 6 IPR Systems 7 P. Faltstrom 8 Cisco 9 March 1, 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." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The URN WG has defined a syntax for Uniform Resource Names (URNs) 37 [RFC2141], as well as some proposed mechanisms for their resolution 38 and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole 39 rests on the concept of individual "namespaces" within the URN 40 structure. Apart from proof-of-concept namespaces, the use of 41 existing identifiers in URNs has been discussed ([RFC2288]), and this 42 document lays out general definitions of and mechanisms for 43 establishing URN "namespaces". 45 This document obsoletes RFC2611. 47 Discussion of this document should be directed to urn-ietf@ietf.org 49 Table of Contents 51 Abstract ........................................................ 52 Table of Contents ............................................... 53 1.0 Introduction ................................................ 54 2.0 What is a URN Namespace? .................................... 55 3.0 URN Namespace (Registration) Types .......................... 56 3.1 Experimental Namespaces ..................................... 57 3.2 Informal Namespaces ......................................... 58 3.3 Formal Namespaces ........................................... 59 4.0 URN Namespace Registration, Update, and NID Assignment 60 Process ..................................................... 61 4.1 Experimental ................................................ 62 4.2 Informal .................................................... 63 4.3 Formal ...................................................... 64 5.0 Security Considerations ..................................... 65 6.0 IANA Considerations ......................................... 66 7.0 References .................................................. 67 8.0 Authors' Addresses .......................................... 68 9.0 Appendix A -- URN Namespace Definition Template ............. 69 10.0 Appendix B -- Illustration ................................. 70 10.1 Example Template ........................................... 71 10.2 Registration steps in practice ............................. 73 1.0 Introduction 75 Uniform Resource Names (URNs) are resource identifiers with the 76 specific requirements for enabling location independent 77 identification of a resource, as well as longevity of reference. 78 There are 2 assumptions that are key to this document: 80 Assumption #1: 82 Assignment of a URN is a managed process. 84 I.e., not all strings that conform to URN syntax are necessarily 85 valid URNs. A URN is assigned according to the rules of a 86 particular namespace (in terms of syntax, semantics, and process). 88 Assumption #2: 90 The space of URN namespaces is managed. 92 I.e., not all syntactically correct URN namespaces (per the URN 93 syntax definition) are valid URN namespaces. A URN namespace 94 must have a recognized definition in order to be valid. 96 The purpose of this document is to outline a mechanism and provide a 97 template for explicit namespace definition, along with the mechanism 98 for associating an identifier (called a "Namespace ID", or NID) which 99 is registered with the Internet Assigned Numbers Authority, IANA. 101 Note that this document restricts itself to the description of 102 processes for the creation of URN namespaces. If "resolution" of any 103 so-created URN identifiers is desired, a separate process of 104 registration in a global NID directory, such as that provided by the 105 DDDS system [RFCXXXX], is necessary. See [RFCYYYY] for information 106 on obtaining registration in the DDDS global NID directory. 108 2.0 What is a URN Namespace? 110 For the purposes of URNs, a "namespace" is a collection of uniquely- 111 assigned identifiers. A URN namespace itself has an identifier in 112 order to 114 - ensure global uniqueness of URNs 115 - (where desired) provide a cue for the structure of the 116 identifier 118 For example, ISBNs and ISSNs are both collections of identifiers used 119 in the traditional publishing world; while there may be some number 120 (or numbers) that is both a valid ISBN identifier and ISSN 121 identifier, using different designators for the two collections 122 ensures that no two URNs will be the same for different resources. 124 The development of an identifier structure, and thereby a collection 125 of identifiers, is a process that is inherently dependent on the 126 requirements of the community defining the identifier, how they will 127 be assigned, and the uses to which they will be put. All of these 128 issues are specific to the individual community seeking to define a 129 namespace (e.g., publishing community, association of booksellers, 130 protocol developers, etc); they are beyond the scope of the IETF URN 131 work. 133 This document outlines the processes by which a collection of 134 identifiers satisfying certain constraints (uniqueness of assignment, 135 etc) can become a bona fide URN namespace by obtaining a NID. In a 136 nutshell, a template for the definition of the namespace is completed 137 for deposit with IANA, and a NID is assigned. The details of the 138 process and possibilities for NID strings are outlined below; first, 139 a template for the definition is provided. 141 3.0 URN Namespace (Registration) Types 142 There are 3 categories of URN namespaces defined here, distinguished 143 by expected level of service and required procedures for 144 registration. Registration processes for each of these namespace 145 types are given in Section 4.0. 147 3.1 Experimental Namespaces 149 These are not explicitly registered with IANA. They take the form 151 X- 153 No provision is made for avoiding collision of experimental NIDs; 154 they are intended for use within internal or limited experimental 155 contexts. 157 3.2 Informal Namespaces 159 These are fully fledged URN namespaces, with all the rights and 160 requirements associated thereto. Informal namespaces can be 161 registered in global registration services. They are required to 162 uphold the general principles of a well-managed URN namespace -- 163 providing persistent, unique identification of resources. Informal 164 and formal namespaces (described below) differ in the NID assignment. 165 IANA will assign an alphanumeric NID to registered informal 166 namespaces, per the process outlined in Section 4.0. 168 3.3 Formal Namespaces 170 A formal namespace may be requested, and IETF review sought, in cases 171 where the publication of the NID proposal and the underlying 172 namespace will provide benefit to some subset of users on the 173 Internet. That is, a formal NID proposal, if accepted, must be 174 functional on and with the global Internet, not limited to users in 175 communities or networks not connected to the Internet. For example, a 176 NID is requested that is meant for naming of physics research. If 177 that NID request required that the user use a propietary network or 178 service that was not at all open to the general Internet user then it 179 would make a poor request for a formal NID. The intent is that, while 180 the community of those who may actively use the names assigned within 181 that NID may be small (but no less important), the potential use of 182 names within that NID is open to any user on the Internet. 184 It is expected that Formal NIDs may be applied to namespaces where 185 some aspects are not fully open. For example, a namespace may make 186 use of an privately managed (proprietary) registry (as, e.g., ISBN 187 does), for assignment of URNs in the namespace, but it may still 188 provide benefit to some Internet users if the services associated 189 have openly-published access protocols. 191 In addition to the basic registration information defined in the 192 registration template (in Appendix A), a formal namespace request 193 must be accompanied by documented considerations of the need for a 194 new namespace and the community benefit of formally establishing the 195 proposed URN namespace. 197 Additionally, since the goal of URNs is to provide persistent 198 identification, some consideration as to the longevity and 199 maintainability of the namespace must be given. The URN WG discussed 200 at length the issue of finding objective measures for predicting (a 201 priori) the continued success of a namespace. No conclusion was 202 reached -- much depends on factors that are completely beyond the 203 technical scope of the namespace. However, the collective experience 204 of the IETF community does contain a wealth of information on 205 technical factors that will prevent longevity of identification. The 206 IESG may elect not to publish a proposed namespace RFC if the IETF 207 community consensus is that it contains technical flaws that will 208 prevent (or seriously impair the possibility of) persistent 209 identification. 211 The kinds of things the URN WG discussed included: 212 - the organization maintaining the URN namespace should 213 demonstrate stability and ability to maintain the URN namespace 214 for a long time, and/or it should be clear how the namespace can 215 continue to be usable/useful if the organization ceases to be 216 able to foster it; 218 - it should demonstrate ability and competency at name assignment 219 in order to facilitate persistence (e.g. to minimize the 220 likelihood of conflicts); 222 - it should commit to not re-assigning existing names and allowing 223 old names to continue to be valid, even if the owners or 224 assignees of those names are no longer members or customers of 225 that organization. This does not mean that there must be 226 resolution of such names, but it does mean that they must not 227 resolve the name to false or stale information, and it means 228 that they must not be reassigned. 230 These aspects, though hard to quantify objectively, should be 231 considered by organizations/people considering the development of a 232 Formal URN namespace, and they will be kept in mind when evaluating 233 the technical merits of any proposed Formal namespace. 235 4.0 URN Namespace Registration, Update, and NID Assignment Process 237 Different levels of disclosure are expected/defined for namespaces. 238 According to the level of open-forum discussion surrounding the 239 disclosure, a URN namespace may be assigned or may request a 240 particular identifier. The "IANA Considerations" document [RFC2434] 241 suggests the need to specify update mechanisms for registrations -- 242 who is given the authority to do so, from time to time, and what are 243 the processes. Since URNs are meant to be persistently useful, few 244 (if any) changes should be made to the structural interpretation of 245 URN strings (e.g., adding or removing rules for lexical equivalence 246 that might affect the interpretation of URN IDs already assigned). 247 However, it may be important to introduce clarifications, expand the 248 list of authorized URN assigners, etc, over the natural course of a 249 namespace's lifetime. Specific processes are outlined below. 251 The official list of registered URN namespaces is maintained by IANA. 252 URN namespace registrations are currently being posted in the 253 anonymous FTP directory "ftp://ftp.isi.edu/in- 254 notes/iana/assignments/URN-namespaces/". See [STD2] for the current 255 location of IANA registry. 257 The registration and maintenance procedures vary slightly from one 258 namespace type (as defined in Section 3.0) to another. 260 4.1 Experimental 262 These are not explicitly registered with IANA. They take the form 264 X- 266 No provision is made for avoiding collision of experimental NIDs; 267 they are intended for use within internal or limited experimental 268 contexts. 270 As there is no registration, no registration maintenance procedures 271 are needed. 273 4.2 Informal 275 These are registered with IANA and are assigned a number sequence as 276 an identifier, in the format: 278 "urn-" 280 where is chosen by the IANA on a First Come First Served 281 basis (see [RFC2434]). 283 Registrants should send a copy of the registration template (see 284 Appendix A), duly completed, to the 286 urn-nid@apps.ietf.org 288 mailing and allow for a 2 week discussion period for clarifying the 289 expression of the registration information and suggestions for 290 improvements to the namespace proposal. 292 After suggestions for clarification of the registration information 293 have been incorporated, the template may be submitted to: 295 iana@iana.org 297 for assignment of a NID. 299 The only restrictions on are that it consist strictly of 300 digits and that it not cause the NID to exceed length limitations 301 outlined in the URN syntax ([RFC2141]). 303 Registrations may be updated by the original registrant, or an entity 304 designated by the registrant, by updating the registration template, 305 submitting it to the discussion list for a further 2 week discussion 306 period, and finally resubmitting it to IANA, as described above. 308 4.3 Formal 310 Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: 312 "IETF Consensus - New values are assigned through the IETF 313 consensus process. Specifically, new assignments are made via 314 RFCs approved by the IESG. Typically, the IESG will seek 315 input on prospective assignments from appropriate persons 316 (e.g., a relevant Working Group if one exists)." 318 Thus, the Formal NID application is made via publication of an RFC 319 through standard IETF processes. The RFC need not be standards- 320 track, but it will be subject to IESG review and acceptance pursuant 321 to the guidelines written here (as well as standard RFC publication 322 guidelines). The template defined in Appendix A may be included as 323 part of an RFC defining some other aspect of the namespace, or it may 324 be put forward as an RFC in its own right. The proposed template 325 should be sent to the 327 urn-nid@apps.ietf.org 329 mailing list to allow for a 2 week discussion period for clarifying 330 the expression of the registration information, before the IESG 331 reviews the document. 333 The RFC must include a "Namespace Considerations" section, which 334 outlines the perceived need for a new namespace (i.e., where existing 335 namespaces fall short of the proposer's requirements). 336 Considerations might include: 338 - URN assignment procedures 339 - URN resolution/delegation 340 - type of resources to be identified 341 - type of services to be supported 343 NOTE: It is expected that more than one namespace may serve the same 344 "functional" purpose; the intent of the "Namespace Considerations" 345 section is to provide a record of the proposer's "due diligence" in 346 exploring existing possibilities, for the IESG's consideration. 348 The RFC must also include a "Community Considerations" section, which 349 indicates the dimensions upon which the proposer expects its 350 community to be able to benefit by publication of this namespace as 351 well as how a general Internet user will be able to use the space if 352 they care to do so. Potential considerations include: 354 - open assignment and use of identifiers within the namespace 355 - open operation of resolution servers for the namespace 356 (server) 357 - creation of software that can meaningfully resolve and 358 access services for the namespace (client) 360 The RFC must include an "IANA Considerations" section, indicating 361 that the document includes a URN NID registration that is to be 362 entered into the IANA registry of URN NIDs. 364 A particular NID string is requested, and is assigned by IETF 365 consensus (as defined in [RFC2434]), with the additional constraints 366 that the NID string must 368 - not be an already-registered NID 369 - not start with "x-" (see Type I above) 370 - not start with "urn-" (see Type II above) 371 - not start with "XY-", where XY is any combination of 2 372 ASCII letters (see NOTE, below) 373 - be more than 2 letters long 375 NOTE: ALL two-letter combinations, and two-letter combinations 376 followed by "-" and any sequence of valid NID characters, are 377 reserved for potential use as countrycode- based NIDs for eventual 378 national registrations of URN namespaces. The definition and 379 scoping of rules for allocation of responsibility for such namespaces 380 is beyond the scope of this document. 382 Registrations may be revised by updating the RFC through standard 383 IETF RFC update mechanisms. Thus, proposals for updates may be made 384 by the original authors, other IETF participants, or the IESG. In 385 any case, the proposed updated template must be circulated on the 386 urn-nid discussion list, allowing for a 2 week review period. 388 5.0 Security Considerations 390 This document largely focuses on providing mechanisms for the 391 declaration of public information. Nominally, these declarations 392 should be of relatively low security profile, however there is always 393 the danger of "spoofing" and providing mis-information. Information 394 in these declarations should be taken as advisory. 396 6.0 IANA Considerations 398 This document outlines the processes for registering URN namespaces, 399 and has implications for the IANA in terms of registries to be 400 maintained. In all cases, the IANA should assign the appropriate NID 401 (informal or formal), as described above, once an IESG-designated 402 expert has confirmed that the requisite registration process steps 403 have been completed. This document replaces the processes outlined 404 in [RFC2611]. 406 7.0 References 408 [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange 409 formats - Information interchange - Representation of 410 dates and times" 412 [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing 413 Bibliographic Identifiers as Uniform Resource Names", RFC 414 2288, February 1998. 416 [RFCXXXX] Mealling, M., "URI Resolution using the Dynamic 417 Delegation Discovery System", RFCXXXX. 419 [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution 420 Using DNS", RFCYYYY. 422 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 424 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 425 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 426 October 1998. 428 [STD2] Reynolds, J, and J. Postel, "Assigned Numbers", STD 2, 429 October 1994. 431 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for 432 Uniform Resource Names", RFC 1737, December 1994. 434 [RFC2276] Sollins, K., "Architectural Principles of Uniform 435 Resource Name Resolution", RFC 2276, January 1998. 437 8.0 Authors' Addresses 439 Leslie L. Daigle 440 Thinking Cat Enterprises 442 EMail: leslie@thinkingcat.com 444 Dirk-Willem van Gulik 445 WebWeaving 446 Plein 1813 - 5a 447 8545 HX Arnhem 448 The Netherlands 450 Phone: +39 0332 78 0014 (Phone and Fax) 451 EMail: Dirkx@webweaving.org 453 Renato Iannella 454 IPR Systems Pty Ltd. 456 EMail: renato@iprsystems.com 458 Patrik Faltstrom 459 Cisco Systems Inc 460 170 W Tasman Drive SJ-13/2 461 San Jose CA 95134 462 USA 463 EMail: paf@cisco.com 464 URL: http://www.cisco.com 466 9.0 Appendix A -- URN Namespace Definition Template 468 Definition of a URN namespace is accomplished by completing the 469 following information template. Apart from providing a mechanism for 470 disclosing structure of the URN namespace, this information is 471 designed to be useful for 473 - entities seeking to have a URN assigned in a namespace (if 474 applicable) 475 - entities seeking to provide URN resolvers for a namespace (if 476 applicable) 478 This is particularly important for communities evaluating the 479 possibility of using a portion of an existing URN namespace rather 480 than creating their own. 482 Information in the template is as follows: 484 Namespace ID: 485 Assigned by IANA. In the case of a Formal NID registration, 486 a particular NID string may be requested. 488 Registration Information: 490 This is information to identify the particular version of 491 registration information: 493 - registration version number: starting with 1, incrementing by 1 494 with each new version 495 - registration date: date submitted to the IANA, using the format 496 YYYY-MM-DD 498 as outlined in [ISO8601]. 500 Declared registrant of the namespace: 501 This includes: 502 Registering organization 503 Name 504 Address 505 Designated contact person 506 Name 507 Coordinates (at least one of: e-mail, phone, postal address) 509 Declaration of syntactic structure: 511 This section should outline any structural features of identifiers 512 in this namespace. At the very least, this description may be 513 used to introduce terminology used in other sections. This 514 structure may also be used for determining realistic 515 caching/shortcuts approaches; suitable caveats should be provided. 516 If there are any specific character encoding rules (e.g., which 517 character should always be used for single-quotes), these should 518 be listed here. 520 Answers might include, but are not limited to: 522 - the structure is opaque (no exposition) - a regular expression 523 for parsing the identifier into components, including naming 524 authorities 526 Relevant ancillary documentation: 528 This section should list any RFCs, standards, or other published 529 documentation that defines or explains all or part of the 530 namespace structure. 532 Answers might include, but are not limited to: 534 - RFCs outlining syntax of the namespace 535 - Other of the defining community's (e.g., ISO) documents 536 outlining syntax of the identifiers in the namespace 537 - Explanatory material introducing the namespace 539 Identifier uniqueness considerations: This section should address the 540 requirement that URN identifiers be assigned uniquely -- they are 541 assigned to at most one resource, and are not reassigned. 543 (Note that the definition of "resource" is fairly broad; for example, 544 information on "Today's Weather" might be considered a single 545 resource, although the content is dynamic.) 547 Possible answers include, but are not limited to: 549 - exposition of the structure of the identifiers, and partitioning 550 of the space of identifiers amongst assignment authorities which 551 are individually responsible for respecting uniqueness rules 552 - identifiers are assigned sequentially 553 - information is withheld; the namespace is opaque 555 Identifier persistence considerations: 557 Although non-reassignment of URN identifiers ensures that a URN 558 will persist in identifying a particular resource even after the 559 "lifetime of the resource", some consideration should be given to 560 the persistence of the usability of the URN. This is particularly 561 important in the case of URN namespaces providing global 562 resolution. 564 Possible answers include, but are not limited to: 566 - quality of service considerations 568 Process of identifier assignment: 570 This section should detail the mechanisms and/or authorities for 571 assigning URNs to resources. It should make clear whether 572 assignment is completely open, or if limited, how to become an 573 assigner of identifiers, and/or get one assigned by existing 574 assignment authorities. Answers could include, but are not 575 limited to: 577 - assignment is completely open, following a particular algorithm 578 - assignment is delegated to authorities recognized by a 579 particular organization (e.g., the Digital Object Identifier 580 Foundation controls the DOI assignment space and its delegation) 581 - assignment is completely closed (e.g., for a private 582 organization) 584 Process for identifier resolution: 586 If a namespace is intended to be accessible for global resolution, 587 it must be registerd in an RDS (Resolution Discovery System, see 588 [RFC2276]) such as DDDS. Resolution then proceeds according to 589 standard URI resolution processes, and the mechanisms of the RDS. 590 What this section should outline is the requirements for becoming 591 a recognized resolver of URNs in this namespace (and being so- 592 listed in the RDS registry). 594 Answers may include, but are not limited to: 596 - the namespace is not listed with an RDS; this is not relevant 597 - resolution mirroring is completely open, with a mechanism for 598 updating an appropriate RDS 599 - resolution is controlled by entities to which assignment has 600 been delegated 602 Rules for Lexical Equivalence: 604 If there are particular algorithms for determining equivalence 605 between two identifiers in the underlying namespace (hence, in the 606 URN string itself), rules can be provided here. 608 Some examples include: 610 - equivalence between hyphenated and non-hyphenated groupings in 611 the identifier string 612 - equivalence between single-quotes and double-quotes 613 - Namespace-defined equivalences between specific characters, such 614 as "character X with or without diacritic marks". 616 Note that these are not normative statements for any kind of best 617 practice for handling equivalences between characters; they are 618 statements limited to reflecting the namespace's own rules. 620 Conformance with URN Syntax: 622 This section should outline any special considerations required 623 for conforming with the URN syntax. This is particularly 624 applicable in the case of legacy naming systems that are used in 625 the context of URNs. 627 For example, if a namespace is used in contexts other than URNs, 628 it may make use of characters that are reserved in the URN syntax. 629 This section should flag any such characters, and outline 630 necessary mappings to conform to URN syntax. Normally, this will 631 be handled by hex encoding the symbol. 633 For example, see the section on SICIs in [RFC2288]. 635 Validation mechanism: 637 Apart from attempting resolution of a URN, a URN namespace may 638 provide mechanism for "validating" a URN -- i.e., determining 639 whether a given string is currently a validly-assigned URN. For 640 example, even if an ISBN URN namespace is created, it is not clear 641 that all ISBNs will translate directly into "assigned URNs". 643 A validation mechanims might be: 645 - a syntax grammar 646 - an on-line service 647 - an off-line service 649 Scope: 651 This section should outline the scope of the use of the 652 identifiers in this namespace. Apart from considerations of 653 private vs. public namespaces, this section is critical in 654 evaluating the applicability of a requested NID. For example, a 655 namespace claiming to deal in "social security numbers" should 656 have a global scope and address all social security number 657 structures (unlikely). On the other hand, at a national level, it 658 is reasonable to propose a URN namespace for "this nation's social 659 security numbers". 661 10.0 Appendix B -- Illustration 663 10.1 Example Template 665 The following example is provided for the purposes of illustration of 666 the URN NID template described in Appendix A. Although it is based 667 on a hypothetical "generic Internet namespace" that has been 668 discussed informally within the URN WG, there are still technical and 669 infrastructural issues that would have to be resolved before such a 670 namespace could be properly and completely described. 672 Namespace ID: 673 To be assigned 675 Registration Information: 677 Version 1 678 Date: 680 Declared registrant of the namespace: 682 Name: Thinking Cat Enterprises 683 Address: 1 ThinkingCat Way 684 Trupville, NewCountry 685 Contact: L. Daigle 686 E-mail: leslie@thinkingcat.com 688 Declaration of structure: 690 The identifier structure is as follows: 692 URN::: 694 where FQDN is a fully-qualified domain name, and the assigned 695 string is conformant to URN syntax requirements. 697 Relevant ancillary documentation: 699 Definition of domain names, found in: 701 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 702 RFC1035, November 1987. 704 Identifier uniqueness considerations: 706 Uniqueness is guaranteed as long as the assigned string is never 707 reassigned for a given FQDN, and that the FQDN is never 708 reassigned. 710 N.B.: operationally, there is nothing that prevents a domain name 711 from being reassigned; indeed, it is not an uncommon occurrence. 712 This is one of the reasons that this example makes a poor URN 713 namespace in practice, and is therefore not seriously being 714 proposed as it stands. 716 Identifier persistence considerations: 718 Persistence of identifiers is dependent upon suitable delegation 719 of resolution at the level of "FQDN"s, and persistence of FQDN 720 assignment. 722 Same note as above. 724 Process of identifier assignment: 726 Assignment of these URNs delegated to individual domain name 727 holders (for FQDNs). The holder of the FQDN registration is 728 required to maintain an entry (or delegate it) in the DDDS. 729 Within each of these delegated name partitions, the string may be 730 assigned per local requirements. 732 e.g. urn::thinkingcat.com:001203 734 Process for identifier resolution: 736 Domain name holders are responsible for operating or delegating 737 resolution servers for the FQDN in which they have assigned URNs. 739 Rules for Lexical Equivalence: 741 FQDNs are case-insensitive. Thus, the portion of the URN 743 urn::: 745 is case-insenstive for matches. The remainder of the identifier 746 must be considered case-sensitve. 748 Conformance with URN Syntax: 750 No special considerations. 752 Validation mechanism: 754 None specified. 756 Scope: 758 Global. 760 10.2 Registration steps in practice 762 The key steps for registration of informal or formal namespaces 763 typically play out as follows: 765 Informal NID: 767 1. Complete the registration template. This may be done as part 768 of an Internet-Draft. 770 2. Communicate the registration template to urn-nid@apps.ietf.org 771 for technical review -- as a published I-D, or text e-mail message 772 containing the template. 774 3. Update the registration template as necessary from comments, and 775 repeat steps 2 and 3 as necessary. 777 4. Once comments have been addressed (and the review period has 778 expired) end a request to IANA with the revised registration 779 template. 781 Formal NID: 783 1. Write an Internet-Draft describing the namespace and including 784 the registration template, duly completed. 786 2. Send the Internet-Draft to the I-D editor, and send a copy to 787 urn-nid@apps.ietf.org for technical review. 789 3. Update the Internet-Draft as necessary from comments, and repeat 790 steps 2 and 3 as needed. 792 4. Send a request to the IESG to publish the I-D as an RFC. The 793 IESG may request further changes (published as I-D revisions) 794 and/or direct discussion to designated working groups, area 795 experts, etc. 797 5. If the IESG approves the document for publication as an RFC, 798 send a request to IANA to register the requested NID.