idnits 2.17.1 draft-saintandre-urnbis-3406bis-00.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 (November 10, 2012) is 4178 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 (~~), 1 warning (==), 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 14, 2013 R. Iannella 7 P. Faltstrom 8 November 10, 2012 10 Uniform Resource Name (URN) Namespace Definitions 11 draft-saintandre-urnbis-3406bis-00 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 14, 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 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 4 58 5. URN Namespace Types . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 5 60 5.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6 61 6. Defining a URN Namespace . . . . . . . . . . . . . . . . . . . 7 62 6.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7 63 6.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1.2. Specification . . . . . . . . . . . . . . . . . . . . 8 65 6.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 8 66 7. Registering a URN Namespace . . . . . . . . . . . . . . . . . 9 67 7.1. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 9 68 7.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9 69 8. URN Namespace Definition Template . . . . . . . . . . . . . . 10 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 75 Appendix A. Changes from RFC 3406 . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) 81 that is intended to serve as a persistent, location-independent 82 resource identifier. The general class of URNs is differentiated 83 from all other URIs through the use of the 'urn' URI scheme. 85 This document supplements the Uniform Resource Name (URN) syntax 86 specification by defining (1) the concept of a URN namespace, (2) a 87 mechanism for defining such namespaces and associating each namespace 88 with a public identifier (called a Namespace ID or "NID"), and (3) 89 procedures for registering such namespaces with the Internet Assigned 90 Numbers Authority (IANA). 92 This document rests on two key assumptions: 94 1. Assignment of a URN is a managed process. 96 A string that conforms to the URN syntax is not necessarily a 97 valid URN, because a URN needs to be assigned according to the 98 rules of a particular namespace (in terms of syntax, semantics, 99 and process). 101 2. The space of URN namespaces is itself managed. 103 A string in the namespace identifier slot of the URN syntax is 104 not necessarily a valid URN namespace identifier, because in 105 order to be valid a namespace needs to be defined and registered 106 in accordance with the rules of this document. 108 URN namespaces were originally defined in [RFC2611], which was 109 obsoleted by [RFC3406]. Based on experience with defining and 110 registering URN namespaces since that time, the goal of this document 111 is to specify URN namespaces with the smallest reasonable set of 112 changes from [RFC3406]. 114 Although on the surface it might appear that this document is 115 significantly different from [RFC3406], in general it only modifies 116 the order of presentation, with the intent of making it easier for 117 people to define and register URN namespaces. However, the only 118 major substantive change is removing the category of experimental 119 namespaces, in accorance with [RFC6648]. 121 If approved, this document will obsolete RFC 3406. 123 2. Discussion Venue 125 The discussion venue for this document is mailing list of the URNBIS 126 WG; visit for 127 subscription and archive information. 129 3. Terminology 131 Several important terms used in this document are defined in the URN 132 syntax specification [I-D.saintandre-urnbis-2141bis]. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 4. What is a URN Namespace? 141 For the purposes of URNs, a "namespace" is a collection of unique 142 identifiers that are consistently assigned according to a common 143 definition. 145 The uniqueness constraint means that an identifier within the 146 namespace is never assigned to more than one resource and never re- 147 assigned to a different resource (however, a single resource can have 148 more than one URN assigned to it for different purposes). 150 The consistent assignment constraint means that an identifier within 151 the namespace is assigned by an organization or in accordance with a 152 process that is always followed. 154 The common definition constraint means that the syntax for 155 identifiers within the namespace and the process for assigning such 156 identifiers are clearly defined in a specification. 158 A URN namespace is identified by a particular designator (which 159 syntactically follows the 'urn' scheme name) in order to: 161 o Ensure the global uniqueness of URNs. 162 o Optionally provide a cue regarding the structure of URNs assigned 163 within a namespace. 165 With regard to global uniqueness, using different designators for 166 different collections of identifiers ensures that no two URNs will be 167 the same for different resources (since each collection is required 168 to uniquely assign each identifier). For instance, some identifier 169 systems use strings of numbers as identifiers (e.g., ISBN, ISSN, 170 phone numbers). It is conceivable that there might be some numbers 171 that are valid identifiers in two different established identifier 172 systems, and the namespace identifier differentiates between the 173 resulting URNs. 175 With regard to the structure of URNs assigned within a namespace, the 176 development of an identifier structure, and thereby a collection of 177 identifiers, is a process that is inherently dependent on the 178 requirements of the community defining the identifier, how they will 179 be assigned, and the uses to which they will be put. All of these 180 issues are specific to the individual community seeking to define a 181 namespace (e.g., a publishing community, an association of 182 booksellers, developers of particular application protocols, etc.); 183 therefore these issues are beyond the scope of URN syntax and the 184 rules regarding URN namespaces in general. 186 URN namespaces inherit certain rights and responsibilities, 187 including: 189 o They uphold the general principles of a well-managed URN namespace 190 by providing persistent identification of resources and unique 191 assignment of identifier strings. 192 o They can be registered in global registration services. 194 5. URN Namespace Types 196 There are two types of URN namespace: formal and informal. These are 197 distinguished by the expected level of service, the information 198 required to define the namespace, and the procedures for 199 registration. To date, the vast majority of the registered 200 namespaces have been formal, so this document concentrates on formal 201 namespaces. 203 Note: [RFC3406] defined a third type of "experimental namespaces:, 204 denoted by prefixing the namespace identifier with the string "X-". 205 Consistent with [RFC6648], this specification removes the 206 experimental category. 208 5.1. Formal Namespaces 210 A formal namespace can be requested, and IETF review sought, in cases 211 where the publication of the NID proposal and the underlying 212 namespace will provide benefit to some subset of users on the 213 Internet. That is, a formal NID proposal, if accepted, needs to be 214 functional on and with the global Internet, not limited to users in 215 communities or networks not connected to the Internet. For example, 216 consider a NID that is meant for naming of physics research; if that 217 NID request required that the user use a proprietary network or 218 service that was not at all open to the general Internet user, then 219 it would make a poor request for a formal NID. The intent is that, 220 while the community of those who may actively use the names assigned 221 within that NID may be small (but no less important), the potential 222 use of names within that NID is open to any user on the Internet. 224 It is expected that formal NIDs may be applied to namespaces where 225 some aspects are not fully open. For example, a namespace might make 226 use of a fee-based, privately managed, or proprietary registry for 227 assignment of URNs in the namespace. However, it may still provide 228 benefit to some Internet users if the services associated have 229 openly- published access protocols. 231 In addition to the basic information specified in the namespace 232 definition template (see Section 8), a formal namespace request needs 233 to be accompanied by documented considerations of the need for a new 234 namespace and of the community benefit from formally establishing the 235 proposed URN namespace. 237 Additionally, since the goal of URNs is to provide persistent 238 identification, a formal namespace request needs to give some 239 consideration as to the longevity and maintainability of the 240 namespace. Possible factors to consider with regard to an 241 organization that will assign URNs within a namespace include the 242 following: 244 o It ought to demonstrate stability and the ability to maintain the 245 URN namespace for a long time; absent such evidence, it ought to 246 be clear how the namespace can remain viable if the organization 247 can no longer maintain the namespace. 248 o It ought to demonstrate competency in name assignment. This will 249 improve the likelihood of persistence (e.g. to minimize the 250 likelihood of conflicts); 251 o It ought to commit to not re-assigning existing names and to 252 allowing old names to continue to be valid, even if the owners or 253 assignees of those names are no longer members or customers of 254 that organization. With regard to URN resolution, this does not 255 mean that there needs to be resolution of such names, only that 256 the names will not resolve to false or stale information. 258 5.2. Informal Namespaces 260 Informal namespaces are full-fledged URN namespaces, with all the 261 rights and responsibilities associated thereto. Informal namespaces 262 differ from formal namespaces in the process for assigning a NID: 263 IANA will assign an alphanumeric NID (e.g., "urn-7") to informal 264 namespaces, per the process outlined under Section 7. 266 6. Defining a URN Namespace 268 A URN namespace is defined by the following factors: 270 o The syntax of URNs assigned within the namespace, in conformance 271 with the fundamental URN syntax [I-D.saintandre-urnbis-2141bis]. 272 o The process for assigning URNs within the namespace. 273 o Optionally, the process for resolving URNs issued within the 274 namepace. 276 Processes for resolution of URNs assigned within a namespace (if any) 277 are out of scope for this document. The following sections provide 278 guidelines for (1) defining the syntax of URNs within a namespace and 279 (2) specifying how URNs will be assigned within a namespace. 281 6.1. Formal Namespaces 283 Formal NIDs are assigned as a result of IETF Consensus as defined in 284 the "IANA Considerations" document [RFC5226]. Thus an application 285 for a formal NID is made by publishing an RFC through normal IETF 286 processes. The RFC need not be standards track (indeed, to date most 287 RFCs registering URN namespaces have been informational), but it will 288 be subject to IESG review and acceptance pursuant to the guidelines 289 written here (as well as standard RFC publication guidelines). 291 6.1.1. Syntax 293 A formal namespace registration requests a particular NID, subject to 294 the following constraints: 296 o It MUST NOT be an already-registered NID. 297 o It MUST NOT start with "urn-" (which is reserved for informal 298 namespaces). 299 o It MUST be more than 2 letters long. 300 o It MUST NOT start with "XY-", where XY is any combination of two 301 ASCII letters. 303 All two-letter combinations, and all two-letter combinations followed 304 by "-" and any sequence of valid NID characters, are reserved for 305 potential use as countrycode-based NIDs for eventual national 306 registrations of URN namespaces. The definition and scoping of rules 307 for allocation of responsibility for such countrycode-based 308 namespaces is beyond the scope of this document. 310 6.1.2. Specification 312 The specification defining a formal namespace MUST include a 313 completed namespace definition template (see Section 8). 315 The specification also MUST include the following sections. 317 The "Namespace Considerations" section outlines the perceived need 318 for a new namespace (i.e., where existing namespaces fall short of 319 the proposer's requirements). Potential considerations include: 321 o Procedures for assigning URNs within this namespace 322 o Processes for resolving URNs assigned within this namespace, if 323 any 324 o The type of resources to be identified 325 o The type of services to be supported 327 It is expected that more than one namespace may serve the same 328 "functional" purpose; the intent of the "Namespace Considerations" 329 section is to provide a record of the proposer's "due diligence" in 330 exploring existing possibilities, for the IESG's consideration. 332 The "Community Considerations" section explains how the intended 333 community will benefit by publication of this namespace as well as 334 how a general Internet user will be able to use the space if they 335 care to do so. Potential considerations include: 337 o Open assignment and use of identifiers within the namespace 338 o Open operation of resolution servers for the namespace (server) 339 o Creation of software that can meaningfully resolve and access 340 services for the namespace (client) 342 The "IANA Considerations" section indicating that the document 343 includes a URN NID registration that is to be entered into the IANA 344 registry of URN NIDs. 346 6.2. Informal Namespaces 348 Informal namespaces are directly requested of IANA. 350 The namespace identifier assigned by IANA is a number sequence in the 351 format: 353 "urn-" 355 where is chosen by the IANA on a First Come First Served 356 basis as specified in the "IANA Considerations" deocument [RFC5226]. 358 The only restrictions on are (1) that it consist strictly of 359 digits and (2) that it not cause the NID to exceed the length 360 limitations defined in the URN syntax specification 361 [I-D.saintandre-urnbis-2141bis]. 363 7. Registering a URN Namespace 365 7.1. Formal Namespaces 367 The key steps for registration of a formal namespace are: 369 1. Write an Internet-Draft that includes all of the information 370 described under Section FIXME. 371 2. Send the completed namespace definition template to the 372 urn-nid@ietf.org discussion list for technical review. 373 3. Update the Internet-Draft as needed to address feedback, and 374 repeat steps 2 and 3 as needed. 375 4. Based on comments received, update the Internet-Draft and repeat 376 steps 2 and 3 as necessary. 377 5. Send a request to the IESG to publish the I-D as an RFC. The 378 IESG may request further changes (published as I-D revisions) 379 and/or direct discussion to designated working groups, area 380 experts, etc. 381 6. If the IESG approves the document for publication as an RFC, send 382 a request to IANA to register the requested NID. 384 A registration can be revised by updating the RFC through normal IETF 385 processes [RFC2606]. The authors of the revised document need to 386 follow the same steps outlined above for new registrations. 388 7.2. Informal Namespaces 390 The key steps for registration of an informal namespace are: 392 1. Complete the namespace definition template (see Section 8). This 393 can be done as part of an Internet-Draft. 394 2. Send the completed template to the urn-nid@ietf.org discussion 395 list for technical review. 396 3. Based on comments received, update the template and repeat steps 397 2 and 3 as necessary. 398 4. Once comments have been addressed and the review period has 399 expired, send a registration request to IANA (via the 400 iana@iana.org email address) with the final template. 402 Informal namespaces can also be revised by updating the template and 403 processing it as outlined above for new registrations. 405 8. URN Namespace Definition Template 407 Definition of a URN namespace is accomplished by completing the 408 following template. Apart from providing a mechanism for defining 409 the structure of URNs assigned within the namespace, this information 410 is designed to be useful for: 412 o entities seeking to have a URN assigned in a namespace (if 413 applicable) 414 o entities seeking to provide URN resolvers for a namespace (if 415 applicable) 417 This is particularly important for communities evaluating the 418 possibility of using a portion of an existing URN namespace rather 419 than creating their own. 421 As described under Section 7.1, applications for formal URN 422 namespaces MUST also document "Namespace Considerations", "Community 423 Considerations" and "IANA Considerations". 425 The information to be provided in the template is as follows: 427 Namespace ID: 429 Requested of IANA (formal) or assigned by IANA (informal). 431 Registration Information: 433 This is information to identify the particular version of 434 registration information: 436 - registration version number: starting with 1, 437 incrementing by 1 with each new version 438 - registration date: date submitted to the IANA, using the 439 format YYYY-MM-DD 441 Declared registrant of the namespace: 442 This includes: 443 Registering organization 444 Name 445 Address 446 Designated contact person 447 Name 448 Coordinates (at least one of email address, phone 449 number, postal address) 451 Declaration of syntactic structure: 453 This section ought to outline any structural features of 454 identifiers in this namespace. At the very least, this 455 description may be used to introduce terminology used in 456 other sections. This structure may also be used for 457 determining realistic caching/shortcuts approaches; 458 suitable caveats ought to be provided. If there are any 459 specific character encoding rules (e.g., which character 460 ought to always be used for single-quotes), these ought 461 to be listed here. 463 Answers might include, but are not limited to: 465 - the structure is opaque (no exposition) 466 - a regular expression for parsing the identifier into 467 components, including naming authorities 469 Relevant ancillary documentation: 471 This section ought to list any RFCs, standards, or other 472 published documentation that defines or explains all or 473 part of the namespace structure. 475 Answers might include, but are not limited to: 477 - RFCs outlining syntax of the namespace 478 - Other of the defining community's (e.g., ISO) documents 479 outlining syntax of the identifiers in the namespace 480 - Explanatory material introducing the namespace 482 Identifier uniqueness considerations: 484 This section ought to address the requirement that URNs are 485 assigned uniquely -- i.e., they are assigned to at most one 486 resource, and are not reassigned. 488 (Note that the definition of "resource" is fairly broad; for 489 example, information on "Today's Weather" might be considered 490 a single resource, although the content is dynamic.) 492 Possible answers include, but are not limited to: 494 - exposition of the structure of the identifiers, and 495 partitioning of the space of identifiers amongst assignment 496 authorities which are individually responsible for 497 respecting uniqueness rules 498 - identifiers are assigned sequentially 499 - information is withheld; the namespace is opaque 501 Identifier persistence considerations: 503 Although non-reassignment of URN identifiers ensures that a URN 504 will persist in identifying a particular resource even after 505 the "lifetime of the resource", some consideration ought to be 506 given to the persistence of the usability of the URN. This is 507 particularly important in the case of URN namespaces providing 508 global resolution. 510 Possible answers include, but are not limited to: 512 - quality of service considerations 514 Process of identifier assignment: 516 This section ought to detail the mechanisms and/or authorities 517 for assigning URNs to resources. It ought to make clear whether 518 assignment is completely open, or if limited, how to become an 519 assigner of identifiers, and/or get one assigned by existing 520 assignment authorities. 522 Answers could include, but are not limited to: 524 - assignment is completely open, following a particular 525 algorithm 526 - assignment is delegated to authorities recognized by a 527 particular organization (e.g., the Digital Object Identifier 528 Foundation controls the DOI assignment space and its 529 delegation) 530 - assignment is completely closed (e.g., for a private 531 organization) 533 Process for identifier resolution: 535 If a namespace is intended to be accessible for global 536 resolution, it needs to be registered in an RDS (Resolution 537 Discovery System, see RFC 2276) such as DDDS. Resolution 538 then proceeds according to standard URI resolution processes, 539 and the mechanisms of the RDS. What this section ought to 540 outline is the requirements for becoming a recognized resolver 541 of URNs in this namespace (and being so- listed in the RDS 542 registry). 544 Answers may include, but are not limited to: 546 - the namespace is not listed with an RDS; therefore this 547 section is not applicable 548 - resolution mirroring is completely open, with a mechanism 549 for updating an appropriate RDS 550 - resolution is controlled by entities to which assignment 551 has been delegated 553 Rules for Lexical Equivalence: 555 If there are particular algorithms for determining equivalence 556 between two identifiers in the underlying namespace (hence, in 557 the URN string itself), rules can be provided here. 559 Some examples include: 561 - equivalence between hyphenated and non-hyphenated groupings 562 in the identifier string 563 - equivalence between single-quotes and double-quotes 564 - Namespace-defined equivalences between specific characters, 565 such as "character X with or without diacritic marks". 567 Note that these are not normative statements for any kind of 568 best practice for handling equivalences between characters; 569 they are statements limited to reflecting the namespace's 570 own rules. 572 Conformance with URN Syntax: 574 This section ought to outline any special considerations 575 required for conforming with the URN syntax. This is 576 particularly applicable in the case of legacy naming 577 systems that are used in the context of URNs. 579 For example, if a namespace is used in contexts other than URNs, 580 it may make use of characters that are reserved in the URN 581 syntax. 583 This section ought to flag any such characters, and outline 584 necessary mappings to conform to URN syntax. Normally, this 585 will be handled by hex encoding the symbol. 587 For example, see the section on SICIs in RFC 2288. 589 Validation mechanism: 591 Apart from attempting resolution of a URN, a URN namespace may 592 provide mechanisms for "validating" a URN -- i.e., determining 593 whether a given string is currently a validly-assigned URN. 594 There are two issues here: 1) users ought not "guess" URNs in 595 a namespace; 2) when the URN namespace is based on an existing 596 identifier system, it may not be the case that all the existing 597 identifiers are assigned on Day 0. The reasonable expectation 598 is that the resource associated with each resulting URN is 599 somehow related to the thing identified by the original 600 identifier system, but those resources may not exist for each 601 original identifier. For example, even if a URN namespace were 602 defined based on telephone numbers, it is not clear that all 603 telephone numbers would immediately become "valid" URNs, that 604 could be resolved using whatever mechanisms are described as 605 part of the namespace registration. 607 Validation mechanisms might be: 609 - a syntax grammar 610 - an on-line service 611 - an off-line service 613 Scope: 615 This section ought to outline the scope of the use of the 616 identifiers in this namespace. Apart from considerations of 617 private vs. public namespaces, this section is critical in 618 evaluating the applicability of a requested NID. For example, 619 a namespace claiming to deal in "social security numbers" 620 ought to have a global scope and address all social security 621 number structures (unlikely). On the other hand, at a national 622 level, it is reasonable to propose a URN namespace for "this 623 nation's social security numbers". 625 9. Security Considerations 627 This document largely focuses on providing mechanisms for the 628 declaration of public information. Nominally, these declarations 629 will be of relatively low security profile, however there is always 630 the danger of "spoofing" and providing mis-information. Information 631 in these declarations ought to be taken as advisory. 633 10. IANA Considerations 635 This document outlines the processes for registering URN namespaces, 636 and has implications for the IANA in terms of registries to be 637 maintained. In all cases, the IANA ought to assign the appropriate 638 NID (informal or formal), as described above, once an IESG-designated 639 expert has confirmed that the requisite registration process steps 640 have been completed. 642 11. References 644 11.1. Normative References 646 [I-D.saintandre-urnbis-2141bis] 647 Saint-Andre, P. and R. Moats, "Uniform Resource Name (URN) 648 Syntax", draft-saintandre-urnbis-2141bis-00 (work in 649 progress), October 2012. 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 655 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 656 May 2008. 658 11.2. Informative References 660 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 661 Names", BCP 32, RFC 2606, June 1999. 663 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 664 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, 665 June 1999. 667 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 668 "Uniform Resource Names (URN) Namespace Definition 669 Mechanisms", BCP 66, RFC 3406, October 2002. 671 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 672 "Deprecating the "X-" Prefix and Similar Constructs in 673 Application Protocols", BCP 178, RFC 6648, June 2012. 675 Appendix A. Changes from RFC 3406 677 Although on the surface it might appear that this document is 678 significantly different from [RFC3406], in general it only modifies 679 the order of presentation, with the intent of making it easier for 680 people to define and register URN namespaces. However, the only 681 major substantive change is removing the category of experimental 682 namespaces, in accorance with [RFC6648]. 684 Authors' Addresses 686 Peter Saint-Andre (editor) 687 Cisco Systems, Inc. 688 1899 Wynkoop Street, Suite 600 689 Denver, CO 80202 690 USA 692 Phone: +1-303-308-3282 693 Email: psaintan@cisco.com 695 Leslie Daigle 697 Dirk-Willem van Gulik 699 Renato Iannella 701 Patrick Faltstrom