idnits 2.17.1 draft-rosen-urn-nena-03.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 (October 12, 2010) is 4942 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3406' is defined on line 278, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Informational October 12, 2010 5 Expires: April 15, 2011 7 Universal Resource Name (URN) Namespace for National Emergency Number 8 Association (NENA) 9 draft-rosen-urn-nena-03 11 Abstract 13 This document describes the Namespace Identifier (NID) 'nena' for 14 Uniform Resource Names (URN) resources published by National 15 Emergency Number Association (NENA). NENA defines and manages 16 resources that utilize this URN model. Management activities for 17 these and other resource types are provided by the NENA Registry 18 System (NRS). 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 April 15, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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. URN Specification for "nena" NID . . . . . . . . . . . . . . . 3 56 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Namespace Considerations . . . . . . . . . . . . . . . . . . . 5 58 5. Community Considerations . . . . . . . . . . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The National Emergency Number Association (NENA) is currently in the 70 process of setting standards, processes and procedures for the use of 71 an IP-based Emergency Services IP Network (ESInet) for all public 72 safety entities in North America. Some of the solutions being 73 developed by NENA require XML namespaces that are managed so that 74 they are unique and persistent. To assure that the uniqueness is 75 absolute, the registration of a specific Uniform Resource Name (URN) 76 [RFC2141] Namespace ID (NID) for use by NENA is required. This 77 document defines and registers such a namespace. 79 2. URN Specification for "nena" NID 81 Namespace ID: nena 83 Registration Information: 84 registration version number: 1 85 registration date: YYYY-MM-DD [RFC Editor, please replace with the 86 date of approval of this document for publication as an RFC] 88 Declared registrant of the namespace: 89 Registering organization 90 Name: National Emergency Number Association (NENA) 91 Address: 4350 North Fairfax Drive, Suite 750 92 Arlington, VA 22203-1695 94 Designated contact: 95 Role: NENA Registry Services Administrator 96 Email: nrs-admin@nena.org 98 Declaration of syntactic structure: 99 The Namespace Specific String (NSS) of all URNs that use the "nena" 100 NID will have the following structure: 101 {NENAclass}:{ClassSpecificString} 103 The "NENAclass" conforms to the URN syntax requirements [RFC2141] and 104 defines a specific class of resource type. Each class will have a 105 specific labeling scheme that is covered by "ClassSpecificString", 106 which also conforms to the naming requirements of [RFC2141]. 108 NENA maintains a naming authority, the National Emergency Number 109 Association (NENA) Registration System (NRS) that will manage the 110 assignment of "NENAclass" and the specific registration values 111 assigned for each class. Other NENA Standards documents will define 112 the "ClassSpecificStrings" for a given "NENAclass". 114 Relevant ancillary documentation: 115 The National Emergency Number Association Registration System (NRS) 116 provides information on the registered resources and the 117 registrations for each. More information about NRS and the 118 registration activities and procedures to be followed are defined in 119 "NENA Registry System Standard", NENA 70-001 [NENA70-001], which is 120 available at: http://www.nena.org/standard/nena-registry-system. 122 Identifier uniqueness considerations: 123 The NRS will manage resources using the "nena" NID and will be the 124 authority for managing the resources and subsequent strings 125 associated. The NRS shall ensure the uniqueness of all nena URNs by 126 checking such names against the list of existing namespace names, as 127 documented in NENA 70-001 [NENA70-001]. 129 Identifier persistence considerations: 130 NRS will provide clear documentation of the registered uses of the 131 "nena" NID. NRS will establish a registry for NENAclass as defined 132 in NENA08-003 [NENA08-003]. Each NENAclass will have a separate 133 description in the registry and may have its own sub-registry. In 134 particular new NENAclass registry entries will require a full NENA 135 technical standard document. 137 NRS will maintain a website at a stable address which provides XML 138 and text renderings of the urn:nena registry. 140 Process of identifier assignment: 141 The NRS processes and procedures for identifier assignment is 142 documented in NENA 07-001 [NENA70-001]. The registry that will 143 control the urn:nena namespace is defined in NENA 08-003 144 [NENA08-003]. In particular, assignments to the NENAclass registry 145 will require a NENA Technical Standard document. Subregistries for 146 particular NENAclasses may be established by such technical 147 standards. Subregistries may be defined to have more liberal 148 management policies as defined in NENA 70-001 [NENA70-001], but must 149 be NRS managed and will not be permitted to be delegated to any other 150 organization or registry. Thus NRS will manage the entire urn:nena 151 tree. 153 Process for identifier resolution: 154 The namespace is not currently listed with a Resolution Discovery 155 System (RDS), but nothing about the namespace prohibits the future 156 definition of appropriate resolution methods or listing with an RDS. 158 Rules for Lexical Equivalence: 159 No special considerations; the rules for lexical equivalence of 160 [RFC2141] apply. 162 Conformance with URN Syntax: 163 No special considerations. 165 Validation mechanism: 166 None specified. URN assignment will be handled by procedures 167 implemented in support of NENA activities. 169 Scope: 170 Global 172 3. Examples 174 The following examples are representative URNs that could be assigned 175 by NRS. They may not be the actual strings that would be assigned. 177 NENAresource "psaproute" 178 Syntax: "urn:nena:emergencyresponders:" 179 ResourceSpecificString: simple string with name of responder, 180 defined in a sub-registry 181 Use: Defines the URN to be used for queries to an NG9-1-1 Emergency 182 Call Routing Function that provides URIs for responding agencies. 184 Examples: 185 urn:nena:emergencyresponders:ambulance 186 urn:nena:emergencyresponders:fire 187 urn:nena:emergencyresponders:police 188 urn:nena:emergencyresponders:poison 189 urn:nena:emergencyresponders:coastguard 190 urn:nena:emergencyresponders:marine 192 4. Namespace Considerations 194 The National Emergency Number Association has developed standards for 195 emergency calling in North America for several decades. NENA is 196 developing a variety of applications and services using Internet 197 protocols built upon on IETF standards. Some of these services 198 require that supporting information (e.g., data descriptions, 199 attributes, etc.) be fully specified. For proper operation, 200 descriptions of the needed supporting information must exist and be 201 available in a unique, reliable, and persistent manner. These 202 dependencies provide the basis of need for namespaces, in one form or 203 another and will enable NENA to define URNs that are to assign 204 cleaner, more general, more permanent, more reliable, and more 205 controllable namespace names related to NENA standards, while keeping 206 urns defined by NENA properly separate from the IETF defined URNs. 208 As the National Emergency Number Association work is ongoing and 209 covers many technical areas, the possibility of binding to various 210 other namespace repositories has been deemed impractical. Each 211 object or description, as defined in NENA, could possibly be related 212 to multiple different other namespaces, so further conflicts of 213 association could occur. Thus the intent is to utilize the National 214 Emergency Number Association Registration System, operated by NENA, 215 as the naming authority for NENA-defined objects and descriptions. 217 5. Community Considerations 219 The North American public safety organizations will benefit from 220 publication of this namespace by having permanent and reliable URNs 221 to be used with protocols defined by NENA. The objects and 222 descriptions required for services defined by NENA are generally 223 available for use by other organizations. The National Emergency 224 Number Association will provide access and support for name requests 225 by these organizations within the constraints of the defined NRS 226 processes and the specific urn:nena registry and subregistries. This 227 support can be enabled in a timely and responsive fashion as new 228 objects and descriptions are produced. These will be enabled in a 229 fashion similar to current IANA processes as documented in NENA70-001 230 [NENA70-001]. 232 NRS establishes registries when called for in a NENA Technical 233 Standard. Such standards must provide NRS with clear and concise 234 instructions on creating and maintaining such registries. Defined 235 management policies include "NENA Technical Standard Required", "NENA 236 Document Required", "Expert Review" and "First Come First Served", 237 which correspond to similar IANA management policies. NENA is 238 establishing a website which provides controlled entry of new 239 registries and entries in registries, and automatically produces html 240 and xml descriptions of registry contents that are used by vendors 241 and other consumers of the content. 243 6. Security Considerations 245 There are no additional security considerations other than those 246 normally associated with the use and resolution of URNs in general. 248 7. IANA Considerations 250 This document adds a new entry in the urn-namespaces registry. The 251 namespace should be "nena". The defining document is this RFC. The 252 entry can be found at: http://www.iana.org/assignments/urn-namespaces 253 and any associated mirrors. 255 8. Acknowledgements 257 The author thanks Alfred Hoenes (TR-Sys) for his careful reading and 258 extensive comments and suggestions. The author also acknowledges 259 that the text from [RFC4358] formed the basis of this document. 261 9. References 263 9.1. Normative References 265 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 267 9.2. Informative References 269 [NENA08-003] 270 NENA, "Detailed Functional and Interface Specification for 271 the NENA i3 Solution - Stage 3", NENA Standard 08-003, 272 September 2010. 274 [NENA70-001] 275 NENA, "NENA Registry System Standard", NENA Standard 70- 276 001, September 2009. 278 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 279 "Uniform Resource Names (URN) Namespace Definition 280 Mechanisms", BCP 66, RFC 3406, October 2002. 282 [RFC4358] Smith, D., "A Uniform Resource Name (URN) Namespace for 283 the Open Mobile Alliance (OMA)", RFC 4358, January 2006. 285 Author's Address 287 Brian Rosen 288 NeuStar, Inc. 289 470 Conrad Dr 290 Mars, PA 16046 291 US 293 Email: br@brianrosen.net