idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06.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 date (July 12, 2013) is 3941 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: 'RFC 2276' is mentioned on line 557, but not defined == Unused Reference: 'RFC2276' is defined on line 698, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-05 ** 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 (~~), 4 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: BCP Thinking Cat Enterprises 6 Expires: January 13, 2014 D. van Gulik 7 WebWeaving 8 R. Iannella 9 Semantic Identity 10 P. Faltstrom 11 Netnod 12 July 12, 2013 14 Uniform Resource Name (URN) Namespace Definition Mechanisms 15 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-06 17 Abstract 19 This document supplements the Uniform Resource Name (URN) syntax 20 specification by defining the concept of a URN namespace, as well as 21 mechanisms for defining and registering such namespaces. This 22 document obsoletes RFC 3406. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 13, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 4 61 4. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 64 5. Defining a URN Namespace . . . . . . . . . . . . . . . . . . . 6 65 5.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 66 5.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1.2. Specification . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 69 6. Registering a URN Namespace . . . . . . . . . . . . . . . . . 9 70 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 9 71 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 72 7. URN Namespace Definition Template . . . . . . . . . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 A Uniform Resource Name (URN) [I-D.ietf-urnbis-rfc2141bis-urn] is a 84 Uniform Resource Identifier (URI) [RFC3986] that is intended to serve 85 as a persistent, location-independent resource identifier. This 86 document supplements the Uniform Resource Name (URN) syntax 87 specification [I-D.ietf-urnbis-rfc2141bis-urn] by defining the 88 following: 90 o The concept of a URN namespace. 91 o A mechanism for defining URN namespaces and associating each 92 namespace with a public identifier (called a Namespace ID or 93 "NID"). 94 o Procedures for registering namespace identifiers with the Internet 95 Assigned Numbers Authority (IANA). 97 This document rests on two key assumptions: 99 1. Assignment of a URN is a managed process. 101 A string that conforms to the URN syntax is not necessarily a 102 valid URN, because a URN needs to be assigned according to the 103 rules of a particular namespace (in terms of syntax, semantics, 104 and process). 106 2. The space of URN namespaces is itself managed. 108 A string in the namespace identifier slot of the URN syntax is 109 not necessarily a valid URN namespace identifier, because in 110 order to be valid a namespace needs to be defined and registered 111 in accordance with the rules of this document. 113 URN namespaces were originally defined in [RFC2611], which was 114 obsoleted by [RFC3406]. Based on experience with defining and 115 registering URN namespaces since that time, this document specifies 116 URN namespaces with the smallest reasonable set of changes from 117 [RFC3406]. This document obsoletes RFC 3406. 119 2. Terminology 121 Several important terms used in this document are defined in the URN 122 syntax specification [I-D.ietf-urnbis-rfc2141bis-urn]. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119]. 129 3. What is a URN Namespace? 131 For the purposes of URNs, a "namespace" is a collection of unique 132 identifiers that are consistently assigned according to a common 133 definition. 135 The uniqueness constraint means that an identifier within the 136 namespace is never assigned to more than one resource and never re- 137 assigned to a different resource (however, a single resource can have 138 more than one URN assigned to it for different purposes). 140 The consistent assignment constraint means that an identifier within 141 the namespace is assigned by an organization or in accordance with a 142 process that is always followed (e.g., in the form of an algorithm). 144 The common definition constraint means that both the syntax for 145 identifiers within the namespace and the process for assigning such 146 identifiers are clearly defined in a specification. 148 A URN namespace is identified by a particular designator (which 149 syntactically follows the 'urn' scheme name) in order to: 151 o Ensure the global uniqueness of URNs. 152 o Optionally provide a cue regarding the structure of URNs assigned 153 within a namespace. 155 With regard to global uniqueness, using different designators for 156 different collections of identifiers ensures that no two URNs will be 157 the same for different resources (since each collection is required 158 to uniquely assign each identifier). For instance, some identifier 159 systems use strings of numbers as identifiers (e.g., ISBN, ISSN, 160 phone numbers). It is conceivable that some numbers might be valid 161 identifiers in two different established identifier systems, where 162 the namespace identifier differentiates between the resulting URNs. 164 With regard to the structure of URNs assigned within a namespace, the 165 development of an identifier structure, and thereby a collection of 166 identifiers, is a process that is inherently dependent on the 167 requirements of the community defining the identifiers, how they will 168 be assigned, and the uses to which they will be put. All of these 169 issues are specific to the individual community seeking to define a 170 namespace (e.g., a publishing community, an association of 171 booksellers, developers of particular application protocols, etc.); 172 therefore these issues are beyond the scope of URN syntax and the 173 rules regarding URN namespaces in general. 175 URN namespaces inherit certain rights and responsibilities, 176 including: 178 o They uphold the general principles of a well-managed URN namespace 179 by providing persistent identification of resources and unique 180 assignment of identifier strings. 181 o They can be registered in global registration services. 183 4. URN Namespace Types 185 There are two types of URN namespace: formal and informal. These are 186 distinguished by the expected level of service, the information 187 necessary to define the namespace, and the procedures for 188 registration. To date, the vast majority of the registered 189 namespaces have been formal, so this document concentrates on formal 190 namespaces. 192 Note: [RFC3406] defined a third type of "experimental namespaces", 193 denoted by prefixing the namespace identifier with the string "X-". 194 Consistent with [RFC6648], this specification removes the 195 experimental category. 197 4.1. Formal Namespaces 199 A formal namespace can be requested, and IETF review sought, in cases 200 where the publication of the NID proposal and the underlying 201 namespace will provide benefit to some subset of users on the 202 Internet. That is, a formal NID proposal, if accepted, needs to be 203 functional on and with the global Internet, not limited to users in 204 communities or networks not connected to the Internet. For example, 205 consider a NID that is meant for naming of physics research; if that 206 NID request effectively forced someone to use a proprietary network 207 or service that was not at all open to the general Internet user, 208 then it would make a poor request for a formal NID. The intent is 209 that, while the community of those who might actively use the names 210 assigned within that NID might be small (but no less important), the 211 potential use of names within that NID is open to any user on the 212 Internet. 214 It is expected that formal NIDs might be applied to namespaces where 215 some aspects are not fully open. For example, a namespace might make 216 use of a fee-based, privately managed, or proprietary registry for 217 assignment of URNs in the namespace. However, it might still provide 218 benefit to some Internet users if the services associated have 219 openly-published access protocols. 221 In addition to the basic information specified in the namespace 222 definition template (see Section 7), a formal namespace request needs 223 to be accompanied by documented considerations of the need for a new 224 namespace and of the community benefit from formally establishing the 225 proposed URN namespace. 227 Additionally, since the goal of URNs is to provide persistent 228 identification, a formal namespace request needs to give some 229 consideration as to the longevity and maintainability of the 230 namespace. Possible factors to consider with regard to an 231 organization that will assign URNs within a namespace include the 232 following: 234 o It ought to demonstrate stability and the ability to maintain the 235 URN namespace for a long time; absent such evidence, it ought to 236 be clear how the namespace can remain viable if the organization 237 can no longer maintain the namespace. 238 o It ought to demonstrate competency in name assignment. This will 239 improve the likelihood of persistence (e.g. to minimize the 240 likelihood of conflicts). 241 o It ought to commit to not re-assigning existing names and to 242 allowing old names to continue to be valid, even if the owners or 243 assignees of those names are no longer members or customers of 244 that organization. With regard to URN resolution, this does not 245 mean that there needs to be resolution of such names, only that 246 the names will not resolve to false or stale information. 248 4.2. Informal Namespaces 250 Informal namespaces are full-fledged URN namespaces, with all the 251 rights and responsibilities associated thereto. Informal namespaces 252 differ from formal namespaces in the process for assigning a NID: 253 IANA will assign an alphanumeric NID (e.g., "urn-7") to informal 254 namespaces, per the process outlined under Section 6. 256 5. Defining a URN Namespace 258 A URN namespace is defined by the following factors: 260 o The syntax of URNs assigned within the namespace, in conformance 261 with the fundamental URN syntax [I-D.ietf-urnbis-rfc2141bis-urn]. 262 o The process for assigning URNs within the namespace. 263 o Optionally, the process for resolving URNs issued within the 264 namepace. 266 Processes for resolution of URNs assigned within a namespace (if any) 267 are out of scope for this document. The following sections provide 268 guidelines for (1) defining the syntax of URNs within a namespace and 269 (2) specifying how URNs will be assigned within a namespace. 271 5.1. Formal Namespaces 273 Formal NIDs are assigned as a result of IETF Review as defined in the 274 "IANA Considerations" document [RFC5226]. Thus an application for a 275 formal NID is made by publishing an RFC in the IETF stream, either as 276 the product of an IETF working group or as an individual submission 277 sponsored by an Area Director. The RFC need not be standards track 278 (indeed, to date most RFCs registering URN namespaces have been 279 informational), but it will be subject to IESG review and approval 280 pursuant to the guidelines provided here (as well as standard RFC 281 publication guidelines). 283 5.1.1. Syntax 285 A formal namespace registration requests a particular NID, subject to 286 the following constraints (above and beyond the syntax rules 287 specified in [I-D.ietf-urnbis-rfc2141bis-urn]): 289 o It MUST NOT be an already-registered NID. 290 o It MUST NOT start with "urn-" (which is reserved for informal 291 namespaces). 292 o It MUST be more than two characters long. 293 o It MUST NOT start with "XY-", where "XY" is any combination of two 294 ASCII letters. 296 All two-letter combinations, and all two-letter combinations followed 297 by "-" and any sequence of valid NID characters, are reserved for 298 potential use as countrycode-based NIDs for eventual national 299 registrations of URN namespaces. The definition and scoping of rules 300 for allocation of responsibility for such countrycode-based 301 namespaces is beyond the scope of this document. 303 5.1.2. Specification 305 The specification defining a formal namespace MUST include a 306 completed namespace definition template (see Section 7). 308 The specification also MUST include the following sections. 310 First, the "Namespace Considerations" section outlines the perceived 311 need for a new namespace (e.g., by describing where existing 312 namespaces fall short of the proposer's requirements). Potential 313 considerations include: 315 o The type of resources to be identified 316 o The type of services to be supported 317 o Procedures for assigning URNs within this namespace 318 o Processes for resolving URNs assigned within this namespace, if 319 any 321 It is expected that more than one namespace might serve the same 322 "functional" purpose; the intent of the "Namespace Considerations" 323 section is to provide a record of the proposer's "due diligence" in 324 exploring existing possibilities, for the consideration by the 325 Internet community, expert reviewers, and the IESG. 327 Second, the "Community Considerations" section explains how the 328 intended community will benefit by assignment of this namespace, as 329 well as how a general Internet user will be able to use the space if 330 they care to do so. Potential considerations include: 332 o Methods and benefits for using the assigned URNs 333 o Methods and benefits for resolving the assigned URNs (if any) 334 o The kinds of software applications that can use or resolve the 335 assigned URNs (e.g., by differentiating among disparate 336 namespaces, identifying resources in a persistent fashion, or 337 meaningfully resolving and accessing services associated with the 338 namespace) 340 Third, the "Security Considerations" section describes any potential 341 security-related issues with regard to assignment, use, and 342 resolution of identifiers within the namespace. Examples of such 343 issues include the consequences of producing false negatives and 344 false positives during comparison for lexical equivalence (see also 345 [RFC6943]), leakage of private information when identifiers are 346 communicated on the public Internet, the potential for directory 347 harvesting, and the issues discussed in [RFC3552]. 349 Fourth, the "IANA Considerations" section indicates that the document 350 includes a URN NID registration that is to be entered into the IANA 351 registry of URN NIDs. 353 5.2. Informal Namespaces 355 Informal namespaces are directly requested of IANA and are assigned 356 based on a policy of First Come First Served [RFC5226]. 358 The namespace identifier assigned by IANA has the following syntax: 360 "urn-" 362 The is chosen by IANA. The only restrictions on 363 are that it (1) consist strictly of ASCII digits and (2) not cause 364 the NID to exceed the length limitations defined in the URN syntax 365 specification [I-D.ietf-urnbis-rfc2141bis-urn]. 367 6. Registering a URN Namespace 369 6.1. Formal Namespaces 371 The registration policy for formal namespaces is IETF Review 372 [RFC5226]. The key steps for registration of a formal namespace are: 374 1. Submit an Internet-Draft that includes all of the information 375 described under Section 5.1.2 and Section 7 of this document. 376 2. Send the completed namespace definition template, along with a 377 pointer to the Internet-Draft, to the urn-nid@ietf.org discussion 378 list for technical review. 379 3. If necessary to address comments received, repeat steps 1 and 2. 380 4. Ask the responsible Area Director to process the Internet-Draft 381 for publication as an RFC. Note that the IESG can request 382 further changes or direct discussion to designated working 383 groups, area experts, etc. 384 5. If the IESG approves the document for publication as an RFC, the 385 IANA will register the requested NID. 387 A registration can be revised by updating the RFC through normal IETF 388 processes [RFC2606]. The authors of the revised document need to 389 follow the same steps outlined above for new registrations. 391 6.2. Informal Namespaces 393 The registration policy for informal namespaces is First Come First 394 Served [RFC5226]. The key steps for registration of an informal 395 namespace are: 397 1. Write a completed namespace definition template (see Section 7). 398 This can be done as part of an Internet-Draft. 399 2. Send the completed template to the urn-nid@ietf.org discussion 400 list for technical review. 401 3. If necessary to address comments received, repeat steps 1 and 2. 402 4. Once comments have been addressed and the review period has 403 expired, send a registration request to IANA (via the 404 iana@iana.org email address) with the final template. 406 Informal namespaces can also be revised by updating the template and 407 processing it as outlined above for new registrations. 409 7. URN Namespace Definition Template 411 Definition of a URN namespace is accomplished by completing the 412 following template. In addition to providing a mechanism for 413 defining the structure of URNs assigned within the namespace, this 414 information is designed to be useful for: 416 o entities seeking to have a URN assigned in a namespace (if 417 applicable) 418 o entities seeking to provide URN resolvers for a namespace (if 419 applicable) 421 Providing a complete and accurate template is particularly helpful to 422 communities that are evaluating the possibility of using a portion of 423 an existing URN namespace rather than creating a new namespace. 425 As described under Section 5.1.2, applications for formal URN 426 namespaces MUST also document the "Namespace Considerations", 427 "Community Considerations", "Security Considerations", and "IANA 428 Considerations". 430 The information to be provided in the template is as follows: 432 Namespace ID: 434 Requested of IANA (formal) or assigned by IANA (informal). 436 Registration Information: 438 The version and date of the registration: 440 - Registration version number: starting with 1, 441 incrementing by 1 with each new version 442 - Registration date: date submitted to the IANA, using the 443 format YYYY-MM-DD 445 Declared registrant of the namespace: 447 This includes: 449 - Registering organization 450 Name 451 Address 452 - Designated contact person 453 Name 454 Contact information 455 (at least one of email address, 456 phone number, postal address) 458 Declaration of syntactic structure: 460 This section ought to outline any structural features of 461 identifiers in this namespace. At the very least, this 462 description can be used to introduce terminology used in 463 other sections. This structure can also be used for 464 determining realistic caching/shortcuts approaches; 465 suitable caveats ought to be provided. If there are any 466 specific character encoding rules (e.g., which character 467 ought to always be used for single-quotes), these ought 468 to be listed here. If the namespace allows use of the 469 URI query component, URI fragment identifier component, 470 or both, such usage needs to be described here (in 471 addition to any other namespace-specific syntax, such 472 as distinguishers for integral parts of resources 473 identified by URNs within the namespace). 475 At a high level, answers might include, but are not limited to: 477 - A formal definition of the structure, e.g., in terms 478 of Augmented BNF for Syntax Specifications (ABNF) as 479 specified in [RFC5234] 480 - A regular expression for parsing the identifier into 481 components, including naming authorities 482 - An algorithm for generating conformant URNs 483 - An explanation that the structure is opaque 485 Relevant ancillary documentation: 487 This section ought to list any RFCs, specifications, or 488 other published documentation that defines or explains 489 all or part of the namespace structure. 491 At a high level, answers might include, but are not limited to: 493 - Pointers to specifications that define the syntax and 494 semantics of the namespace 495 - Mention of documentation that describes the processes 496 followed by an organization that assigns URNs in the 497 namespace 498 - Explanatory material describing the namespace 500 Identifier uniqueness considerations: 502 This section ought to address the requirement that URNs are 503 assigned uniquely -- i.e., they are assigned to at most one 504 resource, and are not reassigned. 506 (Note that the definition of "resource" is fairly broad; for 507 example, information on "Today's Weather" might be considered 508 a single resource, although the content is dynamic.) 510 At a high level, answers might include, but are not limited to: 512 - Exposition of the structure of the identifiers, and 513 partitioning of the space of identifiers amongst assignment 514 authorities which are individually responsible for 515 respecting uniqueness rules 516 - Description of a method for assignment of identifiers (e.g., 517 identifiers are assigned sequentially) 518 - An explanation that this information is withheld (i.e., 519 the namespace is opaque) 521 Identifier persistence considerations: 523 Although non-reassignment of URN identifiers ensures that a URN 524 will persist in identifying a particular resource even after 525 the "lifetime of the resource", some consideration ought to be 526 given to the persistence of the usability of the URN. This is 527 particularly important in the case of URN namespaces providing 528 global resolution. 530 At a high level, answers could include, but are not limited to: 532 - Quality of service considerations 534 Process of identifier assignment: 536 This section ought to detail the mechanisms and/or authorities 537 for assigning URNs to resources. It ought to make clear whether 538 assignment is completely open or, if limited, how to become an 539 assigner of identifiers or how to get an identifer assigned by 540 existing assignment authorities. 542 At a high level, answers could include, but are not limited to: 544 - Assignment is completely open, following a particular 545 algorithm 546 - Assignment is delegated to authorities recognized by a 547 particular organization (e.g., the Digital Object Identifier 548 Foundation controls the DOI assignment space and its 549 delegation) 550 - Assignment is completely closed (e.g., for a private 551 organization) 553 Process for identifier resolution: 555 If a namespace is intended to be accessible for global 556 resolution, it needs to be registered in an RDS (Resolution 557 Discovery System, see [RFC 2276]) such as DDDS. Resolution 558 then proceeds according to standard URI resolution processes, 559 and the mechanisms of the RDS. What this section ought to 560 outline is the requirements for becoming a recognized resolver 561 of URNs in this namespace (and being so listed in the RDS 562 registry). 564 At a high level, answers might include, but are not limited to: 566 - The namespace is not listed with an RDS; therefore this 567 section is not applicable 568 - Resolution mirroring is completely open, with a mechanism 569 for updating an appropriate RDS 570 - Resolution is controlled by entities to which assignment has 571 been delegated 573 Rules for lexical equivalence: 575 If there are particular algorithms for determining equivalence 576 between two identifiers in the underlying namespace (hence, in 577 the URN string itself), rules can be provided here. Such rules 578 ought to always have the effect of eliminating false negatives 579 that might otherwise result from comparison. 581 If it is appropriate and helpful to do so, reference can be 582 made to the equivalence rules defined in the URI specification 583 [RFC3986]. 585 Some examples include: 587 - Equivalence between uppercase and lowercase characters in 588 the Namespace Specific String 589 - Equivalence between hyphenated and non-hyphenated groupings 590 in the identifier string 591 - Equivalence between single-quotes and double-quotes 592 - Namespace-defined equivalences between specific characters, 593 such as "character X with or without diacritic marks". 595 Note that these are not normative statements for any kind of 596 best practice related to handling of equivalences between 597 characters in general; they are statements limited in scope to 598 reflecting the rules for this specific namespace only. 600 Conformance with URN syntax: 602 This section ought to outline any special considerations 603 necessary for conforming with the URN syntax. This is 604 particularly applicable in the case of legacy naming 605 systems that are used in the context of URNs. 607 For example, if a namespace is used in contexts other than URNs, 608 it might make use of characters that are reserved in the URN 609 syntax. 611 This section ought to flag any such characters, and outline 612 necessary mappings to conform to URN syntax. Normally, this 613 will be handled by percent-encoding the character as specified 614 in the URI specification [RFC3986]. 616 Validation mechanism: 618 Apart from attempting resolution of a URN, a URN namespace may 619 provide mechanisms for "validating" a URN -- i.e., determining 620 whether a given string is currently a validly-assigned URN. 621 There are two issues here: 1) users ought not "guess" URNs in 622 a namespace; 2) when the URN namespace is based on an existing 623 identifier system, it might not be the case that all existing 624 identifiers are assigned on Day 0. The reasonable expectation 625 is that the resource associated with each resulting URN is 626 somehow related to the thing identified by the original 627 identifier system, but those resources might not exist for each 628 original identifier. For example, even if a URN namespace were 629 defined based on telephone numbers, it is not clear that all 630 telephone numbers would immediately become "valid" URNs 631 resolvable using whatever mechanisms are described as part of 632 the namespace registration. 634 Validation mechanisms might be: 636 - A syntax grammar 637 - An online service 638 - An offline service 640 Scope: 642 This section ought to outline the scope of the use of the 643 identifiers in this namespace. Apart from considerations of 644 private vs. public namespaces, this section is critical in 645 evaluating the applicability of a requested NID. For example, 646 a namespace claiming to deal in "social security numbers" 647 ought to have a global scope and address all social security 648 number structures (unlikely). On the other hand, at a national 649 level, it is reasonable to propose a URN namespace for "this 650 nation's social security numbers". 652 8. Security Considerations 654 This document largely focuses on providing mechanisms for the 655 declaration of public information. Nominally, these declarations 656 will be of relatively low security profile, however there is always 657 the danger of "spoofing" and providing misinformation. Information 658 in these declarations ought to be taken as advisory. 660 The definition of a URN namespace needs to account for potential 661 security issues related to assignment, use, and resolution of 662 identifiers within the namespace; see Section 5.1.2 for further 663 discussion. 665 9. 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 10. References 675 10.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-05 (work in 680 progress), July 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, 687 RFC 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 10.2. Informative References 695 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 696 Names", BCP 32, RFC 2606, June 1999. 698 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 699 Name Resolution", RFC 2276, January 1998. 701 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 702 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 703 June 1999. 705 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 706 "Uniform Resource Names (URN) Namespace Definition 707 Mechanisms", BCP 66, RFC 3406, October 2002. 709 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 710 Text on Security Considerations", BCP 72, RFC 3552, 711 July 2003. 713 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 714 Specifications: ABNF", STD 68, RFC 5234, January 2008. 716 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 717 "Deprecating the "X-" Prefix and Similar Constructs in 718 Application Protocols", BCP 178, RFC 6648, June 2012. 720 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 721 Purposes", RFC 6943, May 2013. 723 Appendix A. Changes from RFC 3406 725 Although on the surface it might appear that this document is 726 significantly different from [RFC3406], in general it only modifies 727 the order of presentation, with the intent of making it easier for 728 interested parties to define and register URN namespaces. In 729 addition, some of the text was updated to be consistent with the 730 definition of Uniform Resource Identifiers (URIs) [RFC3986] and the 731 processes for registering information with the IANA [RFC5226], as 732 well as more modern guidance with regard to security issues [RFC3552] 733 and identifier comparison [RFC6943]. The only major substantive 734 change was removing the category of experimental namespaces, 735 consistent with [RFC6648]. 737 Authors' Addresses 739 Peter Saint-Andre (editor) 740 Cisco Systems, Inc. 741 1899 Wynkoop Street, Suite 600 742 Denver, CO 80202 743 USA 745 Phone: +1-303-308-3282 746 Email: psaintan@cisco.com 748 Leslie Daigle 749 Thinking Cat Enterprises 751 Dirk-Willem van Gulik 752 WebWeaving 754 Renato Iannella 755 Semantic Identity 757 Patrick Faltstrom 758 Netnod