idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2013) is 4056 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-04 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2611 (Obsoleted by RFC 3406) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 URNBIS P. Saint-Andre, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Obsoletes: 3406 (if approved) L. Daigle 5 Intended status: Best Current Practice Thinking Cat Enterprises 6 Expires: August 23, 2013 D.W. van Gulik 7 R. Iannella 8 Semantic Identity 9 P. Faltstrom 10 Netnod 11 February 19, 2013 13 Uniform Resource Name (URN) Namespace Definition Mechanisms 14 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05 16 Abstract 18 This document supplements the Uniform Resource Name (URN) syntax 19 specification by defining the concept of a URN namespace, as well as 20 mechanisms for defining and registering such namespaces. This 21 document obsoletes RFC 3406. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 23, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 4. What is a URN Namespace? . . . . . . . . . . . . . . . . . . 4 73 5. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5 75 5.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 76 6. Defining a URN Namespace . . . . . . . . . . . . . . . . . . 7 77 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 78 6.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 79 6.1.2. Specification . . . . . . . . . . . . . . . . . . . . 8 80 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 81 7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 9 82 7.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 9 83 7.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 84 8. URN Namespace Definition Template . . . . . . . . . . . . . . 10 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 11.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 A Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is a 96 Uniform Resource Identifier (URI) [RFC3986] that is intended to serve 97 as a persistent, location-independent resource identifier. The 98 general class of URNs is differentiated from all other URIs through 99 the use of the 'urn' URI scheme. 101 This document supplements the Uniform Resource Name (URN) syntax 102 specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining (1) the 103 concept of a URN namespace, (2) a mechanism for defining such 104 namespaces and associating each namespace with a public identifier 105 (called a Namespace ID or "NID"), and (3) procedures for registering 106 namespace identifiers with the Internet Assigned Numbers Authority 107 (IANA). 109 This document rests on two key assumptions: 111 1. Assignment of a URN is a managed process. 113 A string that conforms to the URN syntax is not necessarily a 114 valid URN, because a URN needs to be assigned according to the 115 rules of a particular namespace (in terms of syntax, semantics, 116 and process). 118 2. The space of URN namespaces is itself managed. 120 A string in the namespace identifier slot of the URN syntax is 121 not necessarily a valid URN namespace identifier, because in 122 order to be valid a namespace needs to be defined and registered 123 in accordance with the rules of this document. 125 URN namespaces were originally defined in [RFC2611], which was 126 obsoleted by [RFC3406]. Based on experience with defining and 127 registering URN namespaces since that time, this document specifies 128 URN namespaces with the smallest reasonable set of changes from 129 [RFC3406]. If approved, this document will obsolete RFC 3406. 131 2. Discussion Venue 133 The discussion venue for this document is mailing list of the URNBIS 134 WG; visit https://www.ietf.org/mailman/listinfo/urn for subscription 135 and archive information. 137 3. Terminology 139 Several important terms used in this document are defined in the URN 140 syntax specification [I-D.ietf-urnbis-rfc2141bis-urn]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 [RFC2119]. 147 4. What is a URN Namespace? 149 For the purposes of URNs, a "namespace" is a collection of unique 150 identifiers that are consistently assigned according to a common 151 definition. 153 The uniqueness constraint means that an identifier within the 154 namespace is never assigned to more than one resource and never re- 155 assigned to a different resource (however, a single resource can have 156 more than one URN assigned to it for different purposes). 158 The consistent assignment constraint means that an identifier within 159 the namespace is assigned by an organization or in accordance with a 160 process that is always followed (e.g., in the form of an algorithm). 162 The common definition constraint means that the syntax for 163 identifiers within the namespace and the process for assigning such 164 identifiers are clearly defined in a specification. 166 A URN namespace is identified by a particular designator (which 167 syntactically follows the 'urn' scheme name) in order to: 169 o Ensure the global uniqueness of URNs. 171 o Optionally provide a cue regarding the structure of URNs assigned 172 within a namespace. 174 With regard to global uniqueness, using different designators for 175 different collections of identifiers ensures that no two URNs will be 176 the same for different resources (since each collection is required 177 to uniquely assign each identifier). For instance, some identifier 178 systems use strings of numbers as identifiers (e.g., ISBN, ISSN, 179 phone numbers). It is conceivable that some numbers might be valid 180 identifiers in two different established identifier systems, where 181 the namespace identifier differentiates between the resulting URNs. 183 With regard to the structure of URNs assigned within a namespace, the 184 development of an identifier structure, and thereby a collection of 185 identifiers, is a process that is inherently dependent on the 186 requirements of the community defining the identifiers, how they will 187 be assigned, and the uses to which they will be put. All of these 188 issues are specific to the individual community seeking to define a 189 namespace (e.g., a publishing community, an association of 190 booksellers, developers of particular application protocols, etc.); 191 therefore these issues are beyond the scope of URN syntax and the 192 rules regarding URN namespaces in general. 194 URN namespaces inherit certain rights and responsibilities, 195 including: 197 o They uphold the general principles of a well-managed URN namespace 198 by providing persistent identification of resources and unique 199 assignment of identifier strings. 201 o They can be registered in global registration services. 203 5. URN Namespace Types 205 There are two types of URN namespace: formal and informal. These are 206 distinguished by the expected level of service, the information 207 necessary to define the namespace, and the procedures for 208 registration. To date, the vast majority of the registered 209 namespaces have been formal, so this document concentrates on formal 210 namespaces. 212 Note: [RFC3406] defined a third type of "experimental namespaces:, 213 denoted by prefixing the namespace identifier with the string "X-". 214 Consistent with [RFC6648], this specification removes the 215 experimental category. 217 5.1. Formal Namespaces 219 A formal namespace can be requested, and IETF review sought, in cases 220 where the publication of the NID proposal and the underlying 221 namespace will provide benefit to some subset of users on the 222 Internet. That is, a formal NID proposal, if accepted, needs to be 223 functional on and with the global Internet, not limited to users in 224 communities or networks not connected to the Internet. For example, 225 consider a NID that is meant for naming of physics research; if that 226 NID request effectively forced someone to use a proprietary network 227 or service that was not at all open to the general Internet user, 228 then it would make a poor request for a formal NID. The intent is 229 that, while the community of those who might actively use the names 230 assigned within that NID might be small (but no less important), the 231 potential use of names within that NID is open to any user on the 232 Internet. 234 It is expected that formal NIDs might be applied to namespaces where 235 some aspects are not fully open. For example, a namespace might make 236 use of a fee-based, privately managed, or proprietary registry for 237 assignment of URNs in the namespace. However, it might still provide 238 benefit to some Internet users if the services associated have 239 openly-published access protocols. 241 In addition to the basic information specified in the namespace 242 definition template (see Section 8), a formal namespace request needs 243 to be accompanied by documented considerations of the need for a new 244 namespace and of the community benefit from formally establishing the 245 proposed URN namespace. 247 Additionally, since the goal of URNs is to provide persistent 248 identification, a formal namespace request needs to give some 249 consideration as to the longevity and maintainability of the 250 namespace. Possible factors to consider with regard to an 251 organization that will assign URNs within a namespace include the 252 following: 254 o It ought to demonstrate stability and the ability to maintain the 255 URN namespace for a long time; absent such evidence, it ought to 256 be clear how the namespace can remain viable if the organization 257 can no longer maintain the namespace. 259 o It ought to demonstrate competency in name assignment. This will 260 improve the likelihood of persistence (e.g. to minimize the 261 likelihood of conflicts); 263 o It ought to commit to not re-assigning existing names and to 264 allowing old names to continue to be valid, even if the owners or 265 assignees of those names are no longer members or customers of 266 that organization. With regard to URN resolution, this does not 267 mean that there needs to be resolution of such names, only that 268 the names will not resolve to false or stale information. 270 5.2. Informal Namespaces 272 Informal namespaces are full-fledged URN namespaces, with all the 273 rights and responsibilities associated thereto. Informal namespaces 274 differ from formal namespaces in the process for assigning a NID: 275 IANA will assign an alphanumeric NID (e.g., "urn-7") to informal 276 namespaces, per the process outlined under Section 7. 278 6. Defining a URN Namespace 280 A URN namespace is defined by the following factors: 282 o The syntax of URNs assigned within the namespace, in conformance 283 with the fundamental URN syntax [I-D.ietf-urnbis-rfc2141bis-urn]. 285 o The process for assigning URNs within the namespace. 287 o Optionally, the process for resolving URNs issued within the 288 namepace. 290 Processes for resolution of URNs assigned within a namespace (if any) 291 are out of scope for this document. The following sections provide 292 guidelines for (1) defining the syntax of URNs within a namespace and 293 (2) specifying how URNs will be assigned within a namespace. 295 6.1. Formal Namespaces 297 Formal NIDs are assigned as a result of IETF Review as defined in the 298 "IANA Considerations" document [RFC5226]. Thus an application for a 299 formal NID is made by publishing an RFC in the IETF stream, either as 300 the product of an IETF working group or as an individual submission 301 sponsored by an Area Director. The RFC need not be standards track 302 (indeed, to date most RFCs registering URN namespaces have been 303 informational), but it will be subject to IESG review and approval 304 pursuant to the guidelines provided here (as well as standard RFC 305 publication guidelines). 307 6.1.1. Syntax 309 A formal namespace registration requests a particular NID, subject to 310 the following constraints: 312 o It MUST NOT be an already-registered NID. 314 o It MUST NOT start with "urn-" (which is reserved for informal 315 namespaces). 317 o It MUST be more than 2 letters long. 319 o It MUST NOT start with "XY-", where XY is any combination of two 320 ASCII letters. 322 All two-letter combinations, and all two-letter combinations followed 323 by "-" and any sequence of valid NID characters, are reserved for 324 potential use as countrycode-based NIDs for eventual national 325 registrations of URN namespaces. The definition and scoping of rules 326 for allocation of responsibility for such countrycode-based 327 namespaces is beyond the scope of this document. 329 6.1.2. Specification 331 The specification defining a formal namespace MUST include a 332 completed namespace definition template (see Section 8). 334 The specification also MUST include the following sections. 336 The "Namespace Considerations" section outlines the perceived need 337 for a new namespace (i.e., where existing namespaces fall short of 338 the proposer's requirements). Potential considerations include: 340 o Procedures for assigning URNs within this namespace 342 o Processes for resolving URNs assigned within this namespace, if 343 any 345 o The type of resources to be identified 347 o The type of services to be supported 349 It is expected that more than one namespace might serve the same 350 "functional" purpose; the intent of the "Namespace Considerations" 351 section is to provide a record of the proposer's "due diligence" in 352 exploring existing possibilities, for the IESG's consideration. 354 The "Community Considerations" section explains how the intended 355 community will benefit by assignment of this namespace as well as how 356 a general Internet user will be able to use the space if they care to 357 do so. Potential considerations include: 359 o Open assignment and use of identifiers within the namespace 361 o Open operation of resolution servers for the namespace 363 o Creation of client software that can meaningfully resolve and 364 access services for the namespace 366 The "IANA Considerations" section indicates that the document 367 includes a URN NID registration that is to be entered into the IANA 368 registry of URN NIDs. 370 6.2. Informal Namespaces 372 Informal namespaces are directly requested of IANA and are assigned 373 based on a policy of First Come First Served [RFC5226]. 375 The namespace identifier assigned by IANA has the following syntax: 377 "urn-" 379 The is chosen by IANA. The only restrictions on 380 are that it (1) consist strictly of ASCII digits and (2) not cause 381 the NID to exceed the length limitations defined in the URN syntax 382 specification [I-D.ietf-urnbis-rfc2141bis-urn]. 384 7. Registering a URN Namespace 386 7.1. Formal Namespaces 388 The registration policy for formal namespaces is IETF Review 389 [RFC5226]. The key steps for registration of a formal namespace are: 391 1. Write an Internet-Draft that includes all of the information 392 described under Section 6.1.2 and Section 8 of this document. 394 2. Send the completed namespace definition template, along with a 395 pointer to the Internet-Draft, to the urn-nid@ietf.org discussion 396 list for technical review. 398 3. If necessary to address comments received, update the Internet- 399 Draft and repeat steps 2 and 3. 401 4. Ask the responsible Area Director to process the Internet-Draft 402 for publication as an RFC. Note that the IESG can request 403 further changes or direct discussion to designated working 404 groups, area experts, etc. 406 5. If the IESG approves the document for publication as an RFC, the 407 IANA will register the requested NID. 409 A registration can be revised by updating the RFC through normal IETF 410 processes [RFC2606]. The authors of the revised document need to 411 follow the same steps outlined above for new registrations. 413 7.2. Informal Namespaces 415 The registration policy for formal namespaces is First Come First 416 Served [RFC5226]. The key steps for registration of an informal 417 namespace are: 419 1. Complete the namespace definition template (see Section 8). This 420 can be done as part of an Internet-Draft. 422 2. Send the completed template to the urn-nid@ietf.org discussion 423 list for technical review. 425 3. If necessary to address comments received, update the template 426 and repeat steps 2 and 3. 428 4. Once comments have been addressed and the review period has 429 expired, send a registration request to IANA (via the 430 iana@iana.org email address) with the final template. 432 Informal namespaces can also be revised by updating the template and 433 processing it as outlined above for new registrations. 435 8. URN Namespace Definition Template 437 Definition of a URN namespace is accomplished by completing the 438 following template. In addition to providing a mechanism for 439 defining the structure of URNs assigned within the namespace, this 440 information is designed to be useful for: 442 o entities seeking to have a URN assigned in a namespace (if 443 applicable) 445 o entities seeking to provide URN resolvers for a namespace (if 446 applicable) 448 This is particularly important for communities evaluating the 449 possibility of using a portion of an existing URN namespace rather 450 than creating their own. 452 As described under Section 6.1.2, applications for formal URN 453 namespaces MUST also document "Namespace Considerations", "Community 454 Considerations" and "IANA Considerations". 456 The information to be provided in the template is as follows: 458 Namespace ID: 460 Requested of IANA (formal) or assigned by IANA (informal). 462 Registration Information: 464 The version and date of the registration: 466 - Registration version number: starting with 1, 467 incrementing by 1 with each new version 468 - Registration date: date submitted to the IANA, using the 469 format YYYY-MM-DD 471 Declared registrant of the namespace: 473 This includes: 475 - Registering organization 476 Name 477 Address 478 - Designated contact person 479 Name 480 Contact information 481 (at least one of email address, 482 phone number, postal address) 484 Declaration of syntactic structure: 486 This section ought to outline any structural features of 487 identifiers in this namespace. At the very least, this 488 description can be used to introduce terminology used in 489 other sections. This structure can also be used for 490 determining realistic caching/shortcuts approaches; 491 suitable caveats ought to be provided. If there are any 492 specific character encoding rules (e.g., which character 493 ought to always be used for single-quotes), these ought 494 to be listed here. 496 Answers might include, but are not limited to: 498 - The structure is opaque (no exposition) 499 - A regular expression for parsing the identifier into 500 components, including naming authorities 502 Relevant ancillary documentation: 504 This section ought to list any RFCs, standards, or other 505 published documentation that defines or explains all or 506 part of the namespace structure. 508 Answers might include, but are not limited to: 510 - RFCs outlining syntax of the namespace 511 - Other of the defining community's (e.g., ISO) documents 512 outlining syntax of the identifiers in the namespace 513 - Explanatory material introducing the namespace 515 Identifier uniqueness considerations: 517 This section ought to address the requirement that URNs are 518 assigned uniquely -- i.e., they are assigned to at most one 519 resource, and are not reassigned. 521 (Note that the definition of "resource" is fairly broad; for 522 example, information on "Today's Weather" might be considered 523 a single resource, although the content is dynamic.) 525 Possible answers include, but are not limited to: 527 - Exposition of the structure of the identifiers, and 528 partitioning of the space of identifiers amongst assignment 529 authorities which are individually responsible for 530 respecting uniqueness rules 531 - Identifiers are assigned sequentially 532 - Information is withheld; the namespace is opaque 534 Identifier persistence considerations: 536 Although non-reassignment of URN identifiers ensures that a URN 537 will persist in identifying a particular resource even after 538 the "lifetime of the resource", some consideration ought to be 539 given to the persistence of the usability of the URN. This is 540 particularly important in the case of URN namespaces providing 541 global resolution. 543 Possible answers include, but are not limited to: 545 - Quality of service considerations 547 Process of identifier assignment: 549 This section ought to detail the mechanisms and/or authorities 550 for assigning URNs to resources. It ought to make clear whether 551 assignment is completely open or, if limited, how to become an 552 assigner of identifiers or how to get an identifer assigned by 553 existing assignment authorities. 555 Answers could include, but are not limited to: 557 - Assignment is completely open, following a particular 558 algorithm 559 - Assignment is delegated to authorities recognized by a 560 particular organization (e.g., the Digital Object Identifier 561 Foundation controls the DOI assignment space and its 562 delegation) 563 - Assignment is completely closed (e.g., for a private 564 organization) 566 Process for identifier resolution: 568 If a namespace is intended to be accessible for global 569 resolution, it needs to be registered in an RDS (Resolution 570 Discovery System, see RFC 2276) such as DDDS. Resolution 571 then proceeds according to standard URI resolution processes, 572 and the mechanisms of the RDS. What this section ought to 573 outline is the requirements for becoming a recognized resolver 574 of URNs in this namespace (and being so- listed in the RDS 575 registry). 577 Answers might include, but are not limited to: 579 - The namespace is not listed with an RDS; therefore this 580 section is not applicable 581 - Resolution mirroring is completely open, with a mechanism 582 for updating an appropriate RDS 583 - Resolution is controlled by entities to which assignment 584 has been delegated 586 Rules for Lexical Equivalence: 588 If there are particular algorithms for determining equivalence 589 between two identifiers in the underlying namespace (hence, in 590 the URN string itself), rules can be provided here. 592 Some examples include: 594 - Equivalence between hyphenated and non-hyphenated groupings 595 in the identifier string 596 - Equivalence between single-quotes and double-quotes 597 - Namespace-defined equivalences between specific characters, 598 such as "character X with or without diacritic marks". 600 Note that these are not normative statements for any kind of 601 best practice for handling equivalences between characters; 602 they are statements limited to reflecting the namespace's 603 own rules. 605 Conformance with URN Syntax: 607 This section ought to outline any special considerations 608 necessary for conforming with the URN syntax. This is 609 particularly applicable in the case of legacy naming 610 systems that are used in the context of URNs. 612 For example, if a namespace is used in contexts other than URNs, 613 it might make use of characters that are reserved in the URN 614 syntax. 616 This section ought to flag any such characters, and outline 617 necessary mappings to conform to URN syntax. Normally, this 618 will be handled by hex-encoding the symbol as specified in 619 RFC 3986. 621 Validation mechanism: 623 Apart from attempting resolution of a URN, a URN namespace may 624 provide mechanisms for "validating" a URN -- i.e., determining 625 whether a given string is currently a validly-assigned URN. 626 There are two issues here: 1) users ought not "guess" URNs in 627 a namespace; 2) when the URN namespace is based on an existing 628 identifier system, it might not be the case that all existing 629 identifiers are assigned on Day 0. The reasonable expectation 630 is that the resource associated with each resulting URN is 631 somehow related to the thing identified by the original 632 identifier system, but those resources might not exist for each 633 original identifier. For example, even if a URN namespace were 634 defined based on telephone numbers, it is not clear that all 635 telephone numbers would immediately become "valid" URNs, that 636 could be resolved using whatever mechanisms are described as 637 part of the namespace registration. 639 Validation mechanisms might be: 641 - A syntax grammar 642 - An on-line service 643 - An off-line service 645 Scope: 647 This section ought to outline the scope of the use of the 648 identifiers in this namespace. Apart from considerations of 649 private vs. public namespaces, this section is critical in 650 evaluating the applicability of a requested NID. For example, 651 a namespace claiming to deal in "social security numbers" 652 ought to have a global scope and address all social security 653 number structures (unlikely). On the other hand, at a national 654 level, it is reasonable to propose a URN namespace for "this 655 nation's social security numbers". 657 9. Security Considerations 659 This document largely focuses on providing mechanisms for the 660 declaration of public information. Nominally, these declarations 661 will be of relatively low security profile, however there is always 662 the danger of "spoofing" and providing mis-information. Information 663 in these declarations ought to be taken as advisory. 665 10. IANA Considerations 667 This document outlines the processes for registering URN namespaces, 668 and has implications for the IANA in terms of registries to be 669 maintained. In all cases, the IANA ought to assign the appropriate 670 NID (formal or informal) once the procedures outlined in this 671 document have been completed. 673 11. References 675 11.1. Normative References 677 [I-D.ietf-urnbis-rfc2141bis-urn] 678 Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN) 679 Syntax", draft-ietf-urnbis-rfc2141bis-urn-04 (work in 680 progress), November 2013. 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 686 Resource Identifier (URI): Generic Syntax", STD 66, RFC 687 3986, January 2005. 689 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 690 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 691 May 2008. 693 11.2. Informative References 695 [RFC2606] Eastlake, D.E. and A. Panitz, "Reserved Top Level DNS 696 Names", BCP 32, RFC 2606, June 1999. 698 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 699 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 700 June 1999. 702 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 703 "Uniform Resource Names (URN) Namespace Definition 704 Mechanisms", BCP 66, RFC 3406, October 2002. 706 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 707 "Deprecating the "X-" Prefix and Similar Constructs in 708 Application Protocols", BCP 178, RFC 6648, June 2012. 710 Appendix A. Changes from RFC 3406 712 Although on the surface it might appear that this document is 713 significantly different from [RFC3406], in general it only modifies 714 the order of presentation, with the intent of making it easier for 715 interested parties to define and register URN namespaces. In 716 addition, some of the text was updated to be consistent with the 717 definition of Uniform Resource Identifiers (URIs) [RFC3986] and the 718 processes for registering information with the IANA [RFC5226]. The 719 only major substantive change was removing the category of 720 experimental namespaces, consistent with [RFC6648]. 722 Authors' Addresses 724 Peter Saint-Andre (editor) 725 Cisco Systems, Inc. 726 1899 Wynkoop Street, Suite 600 727 Denver, CO 80202 728 USA 730 Phone: +1-303-308-3282 731 Email: psaintan@cisco.com 733 Leslie Daigle 734 Thinking Cat Enterprises 736 Dirk-Willem van Gulik 738 Renato Iannella 739 Semantic Identity 741 Patrick Faltstrom 742 Netnod