idnits 2.17.1 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04.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 (November 27, 2012) is 4167 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) ** 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 (~~), 2 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 D. van Gulik 6 Expires: May 31, 2013 R. Iannella 7 P. Faltstrom 8 November 27, 2012 10 Uniform Resource Name (URN) Namespace Definitions 11 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04 13 Abstract 15 This document supplements the Uniform Resource Name (URN) syntax 16 specification by defining the concept of a URN namespace, as well as 17 mechanisms for defining and registering such namespaces. This 18 document obsoletes RFC 3406. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 31, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 4 70 5. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5 71 5.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5 72 5.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 73 6. Defining a URN Namespace . . . . . . . . . . . . . . . . . . . 7 74 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 75 6.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1.2. Specification . . . . . . . . . . . . . . . . . . . . 8 77 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 78 7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 9 79 7.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 9 80 7.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 81 8. URN Namespace Definition Template . . . . . . . . . . . . . . 10 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 93 that is intended to serve as a persistent, location-independent 94 resource identifier. The general class of URNs is differentiated 95 from all other URIs through the use of the 'urn' URI scheme. 97 This document supplements the Uniform Resource Name (URN) syntax 98 specification by defining (1) the concept of a URN namespace, (2) a 99 mechanism for defining such namespaces and associating each namespace 100 with a public identifier (called a Namespace ID or "NID"), and (3) 101 procedures for registering such namespaces with the Internet Assigned 102 Numbers Authority (IANA). 104 This document rests on two key assumptions: 106 1. Assignment of a URN is a managed process. 108 A string that conforms to the URN syntax is not necessarily a 109 valid URN, because a URN needs to be assigned according to the 110 rules of a particular namespace (in terms of syntax, semantics, 111 and process). 113 2. The space of URN namespaces is itself managed. 115 A string in the namespace identifier slot of the URN syntax is 116 not necessarily a valid URN namespace identifier, because in 117 order to be valid a namespace needs to be defined and registered 118 in accordance with the rules of this document. 120 URN namespaces were originally defined in [RFC2611], which was 121 obsoleted by [RFC3406]. Based on experience with defining and 122 registering URN namespaces since that time, the goal of this document 123 is to specify URN namespaces with the smallest reasonable set of 124 changes from [RFC3406]. 126 Although on the surface it might appear that this document is 127 significantly different from [RFC3406], in general it only modifies 128 the order of presentation, with the intent of making it easier for 129 people to define and register URN namespaces. However, the only 130 major substantive change is removing the category of experimental 131 namespaces, in accorance with [RFC6648]. 133 If approved, this document will obsolete RFC 3406. 135 2. Discussion Venue 137 The discussion venue for this document is mailing list of the URNBIS 138 WG; visit for 139 subscription and archive information. 141 3. Terminology 143 Several important terms used in this document are defined in the URN 144 syntax specification [I-D.saintandre-urnbis-2141bis]. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in 149 [RFC2119]. 151 4. What is a URN Namespace? 153 For the purposes of URNs, a "namespace" is a collection of unique 154 identifiers that are consistently assigned according to a common 155 definition. 157 The uniqueness constraint means that an identifier within the 158 namespace is never assigned to more than one resource and never re- 159 assigned to a different resource (however, a single resource can have 160 more than one URN assigned to it for different purposes). 162 The consistent assignment constraint means that an identifier within 163 the namespace is assigned by an organization or in accordance with a 164 process that is always followed. 166 The common definition constraint means that the syntax for 167 identifiers within the namespace and the process for assigning such 168 identifiers are clearly defined in a specification. 170 A URN namespace is identified by a particular designator (which 171 syntactically follows the 'urn' scheme name) in order to: 173 o Ensure the global uniqueness of URNs. 174 o Optionally provide a cue regarding the structure of URNs assigned 175 within a namespace. 177 With regard to global uniqueness, using different designators for 178 different collections of identifiers ensures that no two URNs will be 179 the same for different resources (since each collection is required 180 to uniquely assign each identifier). For instance, some identifier 181 systems use strings of numbers as identifiers (e.g., ISBN, ISSN, 182 phone numbers). It is conceivable that there might be some numbers 183 that are valid identifiers in two different established identifier 184 systems, and the namespace identifier differentiates between the 185 resulting URNs. 187 With regard to the structure of URNs assigned within a namespace, the 188 development of an identifier structure, and thereby a collection of 189 identifiers, is a process that is inherently dependent on the 190 requirements of the community defining the identifier, how they will 191 be assigned, and the uses to which they will be put. All of these 192 issues are specific to the individual community seeking to define a 193 namespace (e.g., a publishing community, an association of 194 booksellers, developers of particular application protocols, etc.); 195 therefore these issues are beyond the scope of URN syntax and the 196 rules regarding URN namespaces in general. 198 URN namespaces inherit certain rights and responsibilities, 199 including: 201 o They uphold the general principles of a well-managed URN namespace 202 by providing persistent identification of resources and unique 203 assignment of identifier strings. 204 o They can be registered in global registration services. 206 5. URN Namespace Types 208 There are two types of URN namespace: formal and informal. These are 209 distinguished by the expected level of service, the information 210 required to define the namespace, and the procedures for 211 registration. To date, the vast majority of the registered 212 namespaces have been formal, so this document concentrates on formal 213 namespaces. 215 Note: [RFC3406] defined a third type of "experimental namespaces:, 216 denoted by prefixing the namespace identifier with the string "X-". 217 Consistent with [RFC6648], this specification removes the 218 experimental category. 220 5.1. Formal Namespaces 222 A formal namespace can be requested, and IETF review sought, in cases 223 where the publication of the NID proposal and the underlying 224 namespace will provide benefit to some subset of users on the 225 Internet. That is, a formal NID proposal, if accepted, needs to be 226 functional on and with the global Internet, not limited to users in 227 communities or networks not connected to the Internet. For example, 228 consider a NID that is meant for naming of physics research; if that 229 NID request required that the user use a proprietary network or 230 service that was not at all open to the general Internet user, then 231 it would make a poor request for a formal NID. The intent is that, 232 while the community of those who may actively use the names assigned 233 within that NID may be small (but no less important), the potential 234 use of names within that NID is open to any user on the Internet. 236 It is expected that formal NIDs may be applied to namespaces where 237 some aspects are not fully open. For example, a namespace might make 238 use of a fee-based, privately managed, or proprietary registry for 239 assignment of URNs in the namespace. However, it may still provide 240 benefit to some Internet users if the services associated have 241 openly- published access protocols. 243 In addition to the basic information specified in the namespace 244 definition template (see Section 8), a formal namespace request needs 245 to be accompanied by documented considerations of the need for a new 246 namespace and of the community benefit from formally establishing the 247 proposed URN namespace. 249 Additionally, since the goal of URNs is to provide persistent 250 identification, a formal namespace request needs to give some 251 consideration as to the longevity and maintainability of the 252 namespace. Possible factors to consider with regard to an 253 organization that will assign URNs within a namespace include the 254 following: 256 o It ought to demonstrate stability and the ability to maintain the 257 URN namespace for a long time; absent such evidence, it ought to 258 be clear how the namespace can remain viable if the organization 259 can no longer maintain the namespace. 260 o It ought to demonstrate competency in name assignment. This will 261 improve the likelihood of persistence (e.g. to minimize the 262 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.saintandre-urnbis-2141bis]. 284 o The process for assigning URNs within the namespace. 285 o Optionally, the process for resolving URNs issued within the 286 namepace. 288 Processes for resolution of URNs assigned within a namespace (if any) 289 are out of scope for this document. The following sections provide 290 guidelines for (1) defining the syntax of URNs within a namespace and 291 (2) specifying how URNs will be assigned within a namespace. 293 6.1. Formal Namespaces 295 Formal NIDs are assigned as a result of IETF Consensus as defined in 296 the "IANA Considerations" document [RFC5226]. Thus an application 297 for a formal NID is made by publishing an RFC through normal IETF 298 processes. The RFC need not be standards track (indeed, to date most 299 RFCs registering URN namespaces have been informational), but it will 300 be subject to IESG review and acceptance pursuant to the guidelines 301 written here (as well as standard RFC publication guidelines). 303 6.1.1. Syntax 305 A formal namespace registration requests a particular NID, subject to 306 the following constraints: 308 o It MUST NOT be an already-registered NID. 309 o It MUST NOT start with "urn-" (which is reserved for informal 310 namespaces). 311 o It MUST be more than 2 letters long. 312 o It MUST NOT start with "XY-", where XY is any combination of two 313 ASCII letters. 315 All two-letter combinations, and all two-letter combinations followed 316 by "-" and any sequence of valid NID characters, are reserved for 317 potential use as countrycode-based NIDs for eventual national 318 registrations of URN namespaces. The definition and scoping of rules 319 for allocation of responsibility for such countrycode-based 320 namespaces is beyond the scope of this document. 322 6.1.2. Specification 324 The specification defining a formal namespace MUST include a 325 completed namespace definition template (see Section 8). 327 The specification also MUST include the following sections. 329 The "Namespace Considerations" section outlines the perceived need 330 for a new namespace (i.e., where existing namespaces fall short of 331 the proposer's requirements). Potential considerations include: 333 o Procedures for assigning URNs within this namespace 334 o Processes for resolving URNs assigned within this namespace, if 335 any 336 o The type of resources to be identified 337 o The type of services to be supported 339 It is expected that more than one namespace may serve the same 340 "functional" purpose; the intent of the "Namespace Considerations" 341 section is to provide a record of the proposer's "due diligence" in 342 exploring existing possibilities, for the IESG's consideration. 344 The "Community Considerations" section explains how the intended 345 community will benefit by publication of this namespace as well as 346 how a general Internet user will be able to use the space if they 347 care to do so. Potential considerations include: 349 o Open assignment and use of identifiers within the namespace 350 o Open operation of resolution servers for the namespace (server) 351 o Creation of software that can meaningfully resolve and access 352 services for the namespace (client) 354 The "IANA Considerations" section indicating that the document 355 includes a URN NID registration that is to be entered into the IANA 356 registry of URN NIDs. 358 6.2. Informal Namespaces 360 Informal namespaces are directly requested of IANA. 362 The namespace identifier assigned by IANA is a number sequence in the 363 format: 365 "urn-" 367 where is chosen by the IANA on a First Come First Served 368 basis as specified in the "IANA Considerations" deocument [RFC5226]. 370 The only restrictions on are (1) that it consist strictly of 371 digits and (2) that it not cause the NID to exceed the length 372 limitations defined in the URN syntax specification 373 [I-D.saintandre-urnbis-2141bis]. 375 7. Registering a URN Namespace 377 7.1. Formal Namespaces 379 The key steps for registration of a formal namespace are: 381 1. Write an Internet-Draft that includes all of the information 382 described under Section FIXME. 383 2. Send the completed namespace definition template to the 384 urn-nid@ietf.org discussion list for technical review. 385 3. Update the Internet-Draft as needed to address feedback, and 386 repeat steps 2 and 3 as needed. 387 4. Based on comments received, update the Internet-Draft and repeat 388 steps 2 and 3 as necessary. 389 5. Send a request to the IESG to publish the I-D as an RFC. The 390 IESG may request further changes (published as I-D revisions) 391 and/or direct discussion to designated working groups, area 392 experts, etc. 393 6. If the IESG approves the document for publication as an RFC, send 394 a request to IANA to register the requested NID. 396 A registration can be revised by updating the RFC through normal IETF 397 processes [RFC2606]. The authors of the revised document need to 398 follow the same steps outlined above for new registrations. 400 7.2. Informal Namespaces 402 The key steps for registration of an informal namespace are: 404 1. Complete the namespace definition template (see Section 8). This 405 can be done as part of an Internet-Draft. 406 2. Send the completed template to the urn-nid@ietf.org discussion 407 list for technical review. 408 3. Based on comments received, update the template and repeat steps 409 2 and 3 as necessary. 410 4. Once comments have been addressed and the review period has 411 expired, send a registration request to IANA (via the 412 iana@iana.org email address) with the final template. 414 Informal namespaces can also be revised by updating the template and 415 processing it as outlined above for new registrations. 417 8. URN Namespace Definition Template 419 Definition of a URN namespace is accomplished by completing the 420 following template. Apart from providing a mechanism for defining 421 the structure of URNs assigned within the namespace, this information 422 is designed to be useful for: 424 o entities seeking to have a URN assigned in a namespace (if 425 applicable) 426 o entities seeking to provide URN resolvers for a namespace (if 427 applicable) 429 This is particularly important for communities evaluating the 430 possibility of using a portion of an existing URN namespace rather 431 than creating their own. 433 As described under Section 7.1, applications for formal URN 434 namespaces MUST also document "Namespace Considerations", "Community 435 Considerations" and "IANA Considerations". 437 The information to be provided in the template is as follows: 439 Namespace ID: 441 Requested of IANA (formal) or assigned by IANA (informal). 443 Registration Information: 445 This is information to identify the particular version of 446 registration information: 448 - registration version number: starting with 1, 449 incrementing by 1 with each new version 450 - registration date: date submitted to the IANA, using the 451 format YYYY-MM-DD 453 Declared registrant of the namespace: 454 This includes: 455 Registering organization 456 Name 457 Address 458 Designated contact person 459 Name 460 Coordinates (at least one of email address, phone 461 number, postal address) 463 Declaration of syntactic structure: 465 This section ought to outline any structural features of 466 identifiers in this namespace. At the very least, this 467 description may be used to introduce terminology used in 468 other sections. This structure may also be used for 469 determining realistic caching/shortcuts approaches; 470 suitable caveats ought to be provided. If there are any 471 specific character encoding rules (e.g., which character 472 ought to always be used for single-quotes), these ought 473 to be listed here. 475 Answers might include, but are not limited to: 477 - the structure is opaque (no exposition) 478 - a regular expression for parsing the identifier into 479 components, including naming authorities 481 Relevant ancillary documentation: 483 This section ought to list any RFCs, standards, or other 484 published documentation that defines or explains all or 485 part of the namespace structure. 487 Answers might include, but are not limited to: 489 - RFCs outlining syntax of the namespace 490 - Other of the defining community's (e.g., ISO) documents 491 outlining syntax of the identifiers in the namespace 492 - Explanatory material introducing the namespace 494 Identifier uniqueness considerations: 496 This section ought to address the requirement that URNs are 497 assigned uniquely -- i.e., they are assigned to at most one 498 resource, and are not reassigned. 500 (Note that the definition of "resource" is fairly broad; for 501 example, information on "Today's Weather" might be considered 502 a single resource, although the content is dynamic.) 504 Possible answers include, but are not limited to: 506 - exposition of the structure of the identifiers, and 507 partitioning of the space of identifiers amongst assignment 508 authorities which are individually responsible for 509 respecting uniqueness rules 510 - identifiers are assigned sequentially 511 - information is withheld; the namespace is opaque 513 Identifier persistence considerations: 515 Although non-reassignment of URN identifiers ensures that a URN 516 will persist in identifying a particular resource even after 517 the "lifetime of the resource", some consideration ought to be 518 given to the persistence of the usability of the URN. This is 519 particularly important in the case of URN namespaces providing 520 global resolution. 522 Possible answers include, but are not limited to: 524 - quality of service considerations 526 Process of identifier assignment: 528 This section ought to detail the mechanisms and/or authorities 529 for assigning URNs to resources. It ought to make clear whether 530 assignment is completely open, or if limited, how to become an 531 assigner of identifiers, and/or get one assigned by existing 532 assignment authorities. 534 Answers could include, but are not limited to: 536 - assignment is completely open, following a particular 537 algorithm 538 - assignment is delegated to authorities recognized by a 539 particular organization (e.g., the Digital Object Identifier 540 Foundation controls the DOI assignment space and its 541 delegation) 542 - assignment is completely closed (e.g., for a private 543 organization) 545 Process for identifier resolution: 547 If a namespace is intended to be accessible for global 548 resolution, it needs to be registered in an RDS (Resolution 549 Discovery System, see RFC 2276) such as DDDS. Resolution 550 then proceeds according to standard URI resolution processes, 551 and the mechanisms of the RDS. What this section ought to 552 outline is the requirements for becoming a recognized resolver 553 of URNs in this namespace (and being so- listed in the RDS 554 registry). 556 Answers may include, but are not limited to: 558 - the namespace is not listed with an RDS; therefore this 559 section is not applicable 560 - resolution mirroring is completely open, with a mechanism 561 for updating an appropriate RDS 562 - resolution is controlled by entities to which assignment 563 has been delegated 565 Rules for Lexical Equivalence: 567 If there are particular algorithms for determining equivalence 568 between two identifiers in the underlying namespace (hence, in 569 the URN string itself), rules can be provided here. 571 Some examples include: 573 - equivalence between hyphenated and non-hyphenated groupings 574 in the identifier string 575 - equivalence between single-quotes and double-quotes 576 - Namespace-defined equivalences between specific characters, 577 such as "character X with or without diacritic marks". 579 Note that these are not normative statements for any kind of 580 best practice for handling equivalences between characters; 581 they are statements limited to reflecting the namespace's 582 own rules. 584 Conformance with URN Syntax: 586 This section ought to outline any special considerations 587 required for conforming with the URN syntax. This is 588 particularly applicable in the case of legacy naming 589 systems that are used in the context of URNs. 591 For example, if a namespace is used in contexts other than URNs, 592 it may make use of characters that are reserved in the URN 593 syntax. 595 This section ought to flag any such characters, and outline 596 necessary mappings to conform to URN syntax. Normally, this 597 will be handled by hex encoding the symbol. 599 For example, see the section on SICIs in RFC 2288. 601 Validation mechanism: 603 Apart from attempting resolution of a URN, a URN namespace may 604 provide mechanisms for "validating" a URN -- i.e., determining 605 whether a given string is currently a validly-assigned URN. 606 There are two issues here: 1) users ought not "guess" URNs in 607 a namespace; 2) when the URN namespace is based on an existing 608 identifier system, it may not be the case that all the existing 609 identifiers are assigned on Day 0. The reasonable expectation 610 is that the resource associated with each resulting URN is 611 somehow related to the thing identified by the original 612 identifier system, but those resources may not exist for each 613 original identifier. For example, even if a URN namespace were 614 defined based on telephone numbers, it is not clear that all 615 telephone numbers would immediately become "valid" URNs, that 616 could be resolved using whatever mechanisms are described as 617 part of the namespace registration. 619 Validation mechanisms might be: 621 - a syntax grammar 622 - an on-line service 623 - an off-line service 625 Scope: 627 This section ought to outline the scope of the use of the 628 identifiers in this namespace. Apart from considerations of 629 private vs. public namespaces, this section is critical in 630 evaluating the applicability of a requested NID. For example, 631 a namespace claiming to deal in "social security numbers" 632 ought to have a global scope and address all social security 633 number structures (unlikely). On the other hand, at a national 634 level, it is reasonable to propose a URN namespace for "this 635 nation's social security numbers". 637 9. Security Considerations 639 This document largely focuses on providing mechanisms for the 640 declaration of public information. Nominally, these declarations 641 will be of relatively low security profile, however there is always 642 the danger of "spoofing" and providing mis-information. Information 643 in these declarations ought to be taken as advisory. 645 10. IANA Considerations 647 This document outlines the processes for registering URN namespaces, 648 and has implications for the IANA in terms of registries to be 649 maintained. In all cases, the IANA ought to assign the appropriate 650 NID (informal or formal), as described above, once an IESG-designated 651 expert has confirmed that the requisite registration process steps 652 have been completed. 654 11. References 656 11.1. Normative References 658 [I-D.saintandre-urnbis-2141bis] 659 Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN) 660 Syntax", draft-saintandre-urnbis-2141bis-00 (work in 661 progress), October 2012. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 667 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 668 May 2008. 670 11.2. Informative References 672 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 673 Names", BCP 32, RFC 2606, June 1999. 675 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 676 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 677 June 1999. 679 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 680 "Uniform Resource Names (URN) Namespace Definition 681 Mechanisms", BCP 66, RFC 3406, October 2002. 683 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 684 "Deprecating the "X-" Prefix and Similar Constructs in 685 Application Protocols", BCP 178, RFC 6648, June 2012. 687 Appendix A. Changes from RFC 3406 689 Although on the surface it might appear that this document is 690 significantly different from [RFC3406], in general it only modifies 691 the order of presentation, with the intent of making it easier for 692 people to define and register URN namespaces. However, the only 693 major substantive change is removing the category of experimental 694 namespaces, in accorance with [RFC6648]. 696 Authors' Addresses 698 Peter Saint-Andre (editor) 699 Cisco Systems, Inc. 700 1899 Wynkoop Street, Suite 600 701 Denver, CO 80202 702 USA 704 Phone: +1-303-308-3282 705 Email: psaintan@cisco.com 707 Leslie Daigle 709 Dirk-Willem van Gulik 711 Renato Iannella 713 Patrick Faltstrom