idnits 2.17.1 draft-saintandre-iana-urn-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2013) is 4091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational M. Cotton 5 Expires: August 17, 2013 ICANN 6 February 13, 2013 8 A Uniform Resource Name (URN) Namespace for IANA Registries 9 draft-saintandre-iana-urn-01 11 Abstract 13 This document defines a Uniform Resource Name (URN) namespace for 14 uniquely identifying information contained in registries maintained 15 by the Internet Assigned Numbers Authority (IANA). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 17, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Specification Template . . . . . . . . . . . . . . . . . . . 3 53 3. Namespace Considerations . . . . . . . . . . . . . . . . . . 5 54 4. Community Considerations . . . . . . . . . . . . . . . . . . 5 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 7.2. Informative References . . . . . . . . . . . . . . . . . 6 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 The Internet Assigned Numbers Authority (IANA) allocates and 66 maintains unique codes and numbering systems that are used in the 67 context of Internet protocols. Most of the constants and other well- 68 known values maintained by the IANA are contained in registries that 69 are accessible over the Internet, where each registry is hosted at 70 iana.org and identified by a Uniform Resource Identifier (URI) 71 [RFC3986] whose resources are retrieved using the Hypertext Transfer 72 Protocol (HTTP) [RFC2616]. 74 Some Internet protocols need persistent identifiers for the entries 75 contained in IANA registries. However, currently such identifiers do 76 not exist, for several reasons: 78 1. Each IANA registry is located at an HTTP URI (e.g., "http:// 79 www.iana.org/assignments/sdp-security-descriptions/sdp-security- 80 descriptions.xml"), but there are no "pointers" to specific 81 entries in each registry (e.g., the "AES_256_CM_HMAC_SHA1_80" 82 entry in the SRTP Crypto Suite registry located at that URI). 84 2. From time to time, the IANA might change the URIs for its 85 registries (as was done not long ago when the IANA changed all of 86 its registries to use Extensible Markup Language [XML] files 87 instead of plain text files). 89 It is desirable that names for the entries in IANA registries can be 90 persistent and location-independent, which is not necessarily the 91 case with names that are also HTTP URIs. However, Uniform Resource 92 Names (URNs) [RFC2141] are designed to be both persistent and 93 location-independent. For example, a URN for the foregoing registry 94 entry might be: 96 urn:iana:sdp-security-descriptions:AES_256_CM_HMAC_SHA1_80 98 Therefore, in accordance with the process defined in [RFC3406], this 99 document defines a formal namespace identifier (NID) that could be 100 used to assign URNs representing the information contained in IANA 101 registries. 103 2. Specification Template 105 Namespace ID: 107 The Namespace ID "iana" is requested. 109 Registration Information: 111 Version 1 112 Date: [[to be assigned by the RFC Editor]] 114 Declared Registrant of the Namespace: 116 Registering organization 117 Organization: 118 Internet Corporation for Assigned Names and Numbers (ICANN) 119 Address: 120 12025 Waterfront Drive, Suite 300 121 Los Angeles, CA 90094-2536 USA 123 Designated contact 124 Role: IANA Department 125 Email: iana@iana.org 127 Declaration of Syntactic Structure: 129 The Namespace Specific String (NSS) of all URNs that use the 130 "iana" NID shall have the following structure: 132 urn:iana:{RegistryString}:{EntryName} 134 The keywords have the following meaning: 136 (1) the "RegistryName" is a required ASCII string that 137 conforms to the URN syntax (RFC 2141) and defines a 138 particular registry maintained by the IANA. 140 (2) the "EntryName" is a required ASCII string that 141 conforms to the URN syntax (RFC 2141) and defines a 142 particular entry in the relevant registry. 144 The IANA is responsible for managing the assignment of both 145 "RegistryName" and "EntryName" strings. 147 Relevant Ancillary Documentation: 149 Information about IANA registration procedures can be found 150 on the IANA website and in RFC 5226. 152 Identifier Uniqueness Considerations: 154 The IANA ensures the uniqueness of all IANA URNs by checking 155 RegistryNames and EntryNames against existing names for both 156 registries and entries. The IANA directly ensures the 157 uniqueness of the assigned strings and does not assign 158 secondary responsibility for management of any sub-trees. 159 In no case will the resulting URNs be re-assigned. 161 Identifier Persistence Considerations: 163 Through its existing registration procedures, the IANA 164 ensures that registrants provide clear documentation of 165 the entries in IANA registries. 167 Process of Identifier Assignment: 169 The processes and procedures for identifier assignment are 170 documented on the IANA website and in RFC 5226. 172 Process for Identifier Resolution: 174 The namespace is not currently listed with a Resolution 175 Discovery System (RDS). However, nothing about the namespace 176 prohibits the future definition of appropriate resolution 177 methods or listing with an RDS. 179 Rules for Lexical Equivalence: 181 No special considerations; the rules for lexical 182 equivalence specified in RFC 2141 apply. 184 Conformance with URN Syntax: 186 No special considerations. 188 Validation Mechanism: 190 None specified. 192 Scope: 194 Global. 196 3. Namespace Considerations 198 The IANA is one of the Internet's oldest institutions, with its 199 activities dating back to the 1970s. The use of Uniform Resource 200 Names with an appropriate Namespace ID will enable the IANA to assign 201 cleaner, more general, more permanent, more reliable, and more 202 controllable names for the parameters used by Internet protocols and 203 applications. 205 4. Community Considerations 207 The Internet community will benefit from this namespace by having 208 more permanent and reliable names for parameters used in the context 209 of Internet protocols and applications. 211 The registries maintained by the IANA are open to contributions from 212 any interested individual or organization. See the IANA website and 213 documentation of its registration procedures [RFC5226] for detailed 214 descriptions of the registration procedures. 216 5. Security Considerations 218 This document introduces no additional security considerations beyond 219 those associated with the use and resolution of URNs in general. 221 6. IANA Considerations 223 This document defines a URN NID registration of "iana" and thus opens 224 the possibility that the IANA can use that namespace if desired. 225 However, this document does not stipulate that the IANA is to create 226 names for every entry in every registry that it maintains. The 227 IANA's use of the namespace is a matter for IANA policy, which is 228 outside the scope of this document. 230 7. References 232 7.1. Normative References 234 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 236 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 237 "Uniform Resource Names (URN) Namespace Definition 238 Mechanisms", BCP 66, RFC 3406, October 2002. 240 7.2. Informative References 242 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 243 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 244 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 246 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 247 Resource Identifier (URI): Generic Syntax", STD 66, RFC 248 3986, January 2005. 250 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 251 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 252 May 2008. 254 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 255 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 256 Edition)", World Wide Web Consortium Recommendation REC- 257 xml-20081126, November 2008, 258 . 260 Appendix A. Acknowledgements 262 Thanks to Martin Duerst for his feedback. 264 Authors' Addresses 266 Peter Saint-Andre 267 Cisco Systems, Inc. 268 1899 Wynkoop Street, Suite 600 269 Denver, CO 80202 270 USA 272 Phone: +1-303-308-3282 273 Email: psaintan@cisco.com 275 Michelle Cotton 276 Internet Corporation for Assigned Names and Numbers 277 12025 Waterfront Drive, Suite 300 278 Los Angeles, CA 90094-2536 279 USA 281 Phone: +1-310-823-9358 282 Email: michelle.cotton@icann.org