idnits 2.17.1 draft-rosen-ecrit-emergency-registries-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 (22 December 2021) is 849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'GIS' is defined on line 2380, but no explicit reference was found in the text == Unused Reference: 'RFC4240' is defined on line 2414, but no explicit reference was found in the text == Unused Reference: 'RFC4730' is defined on line 2419, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 2434, but no explicit reference was found in the text == Unused Reference: 'RFC6665' is defined on line 2455, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: 'RFC8141' is defined on line 2469, but no explicit reference was found in the text == Unused Reference: 'StatusCodes' is defined on line 2477, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B.R. Rosen 3 Internet-Draft Unaffiliated 4 Intended status: Informational B.A. Abley, Ed. 5 Expires: 25 June 2022 NENA 6 22 December 2021 8 Emergency Registries 9 draft-rosen-ecrit-emergency-registries-00 11 Abstract 13 Multiple emergency services standards organizations are developing 14 standards based on IETF emergency call standards and other IETF 15 protocols. There is a desire among these organizations to use common 16 registries not tied to a particular country or national SDO, in the 17 long term pursuit of a single worldwide standard. This document asks 18 IANA to create a set of registries and provides processes for 19 expanding the set and populating them. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 25 June 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 8 56 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 57 3. Conventions used in this document . . . . . . . . . . . . . . 8 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. "emergency" URN namespace . . . . . . . . . . . . . . . . 9 60 4.1.1. Namespace Identifier . . . . . . . . . . . . . . . . 9 61 4.1.2. Version . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1.3. Date . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1.4. Registrant . . . . . . . . . . . . . . . . . . . . . 9 64 4.1.5. Purpose . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1.7. Assignment . . . . . . . . . . . . . . . . . . . . . 10 67 4.1.8. Security and Privacy . . . . . . . . . . . . . . . . 10 68 4.1.9. Interoperability . . . . . . . . . . . . . . . . . . 11 69 4.1.10. Resolution . . . . . . . . . . . . . . . . . . . . . 11 70 4.2. "Emergency" Area . . . . . . . . . . . . . . . . . . . . 11 71 4.3. Emergency Call Additional Data Registry . . . . . . . . . 12 72 4.4. "urn:emergency" registry . . . . . . . . . . . . . . . . 12 73 4.4.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.4.2. Information Needed to Create a New Value . . . . . . 12 75 4.4.3. Registration policy . . . . . . . . . . . . . . . . . 12 76 4.4.4. Content . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.4.5. Subregistries for top level classes of 78 urn:emergency . . . . . . . . . . . . . . . . . . . . 13 79 4.4.5.1. "urn:emergency:service" Subregistry . . . . . . . 13 80 4.4.5.1.1. Name . . . . . . . . . . . . . . . . . . . . 13 81 4.4.5.1.2. Information Needed to Create a New Value . . 13 82 4.4.5.1.3. Registration policy . . . . . . . . . . . . . 14 83 4.4.5.1.4. Content . . . . . . . . . . . . . . . . . . . 14 84 4.4.5.2. "urn:emergency:service:sos" Subregistry . . . . . 14 85 4.4.5.2.1. Name . . . . . . . . . . . . . . . . . . . . 14 86 4.4.5.2.2. Information Needed to Create a New Value . . 14 87 4.4.5.2.3. Registration policy . . . . . . . . . . . . . 15 88 4.4.5.2.4. Content . . . . . . . . . . . . . . . . . . . 15 89 4.4.5.3. "urn:emergency:service:test" Registry . . . . . . 15 90 4.4.5.3.1. Name . . . . . . . . . . . . . . . . . . . . 15 91 4.4.5.3.2. Information Needed to Create a New Value . . 16 92 4.4.5.3.3. Registration policy . . . . . . . . . . . . . 16 93 4.4.5.3.4. Content . . . . . . . . . . . . . . . . . . . 16 94 4.4.5.4. "urn:emergency:service:responder" Registry . . . 16 95 4.4.5.4.1. Name . . . . . . . . . . . . . . . . . . . . 17 96 4.4.5.4.2. Information Needed to Create a New Value . . 17 97 4.4.5.4.3. Registration policy . . . . . . . . . . . . . 17 98 4.4.5.4.4. Content . . . . . . . . . . . . . . . . . . . 17 99 4.4.5.5. "urn:emergency:service:responder.police" 100 Subregistry . . . . . . . . . . . . . . . . . . . . 17 101 4.4.5.5.1. Name . . . . . . . . . . . . . . . . . . . . 17 102 4.4.5.5.2. Information Needed to Create a New Value . . 17 103 4.4.5.5.3. Registration policy . . . . . . . . . . . . . 18 104 4.4.5.5.4. Content . . . . . . . . . . . . . . . . . . . 18 105 4.4.5.6. "police.federal" Subregistry . . . . . . . . . . 18 106 4.4.5.6.1. Name . . . . . . . . . . . . . . . . . . . . 18 107 4.4.5.6.2. Information Needed to Create a New Value . . 18 108 4.4.5.6.3. Registration policy . . . . . . . . . . . . . 19 109 4.4.5.6.4. Content . . . . . . . . . . . . . . . . . . . 19 110 4.4.5.7. "urn:emergency:service:responder.fire" 111 Subregistry . . . . . . . . . . . . . . . . . . . . 19 112 4.4.5.7.1. Name . . . . . . . . . . . . . . . . . . . . 19 113 4.4.5.7.2. Information Needed to Create a New Value . . 19 114 4.4.5.7.3. Registration policy . . . . . . . . . . . . . 19 115 4.4.5.7.4. Content . . . . . . . . . . . . . . . . . . . 20 116 4.4.5.8. "urn:emergency:service:responder.ems" 117 Subregistry . . . . . . . . . . . . . . . . . . . . 20 118 4.4.5.8.1. Name . . . . . . . . . . . . . . . . . . . . 20 119 4.4.5.8.2. Information Needed to Create a New Value . . 20 120 4.4.5.8.3. Registration policy . . . . . . . . . . . . . 20 121 4.4.5.8.4. Content . . . . . . . . . . . . . . . . . . . 20 122 4.4.5.9. "urn:emergency:service:serviceAgencyLocator" 123 Subregistry . . . . . . . . . . . . . . . . . . . . 21 124 4.4.5.9.1. Name . . . . . . . . . . . . . . . . . . . . 21 125 4.4.5.9.2. Information Needed to Create a New Value . . 21 126 4.4.5.9.3. Registration policy . . . . . . . . . . . . . 21 127 4.4.5.9.4. Content . . . . . . . . . . . . . . . . . . . 21 128 4.4.5.10. "urn:emergency:uid" Registry . . . . . . . . . . 22 129 4.4.5.10.1. Name . . . . . . . . . . . . . . . . . . . . 22 130 4.4.5.10.2. Information Needed to Create a New Value . . 22 131 4.4.5.10.3. Registration policy . . . . . . . . . . . . 22 132 4.4.5.10.4. Content . . . . . . . . . . . . . . . . . . 22 133 4.4.5.11. "urn:emergency:media-feature" Registry . . . . . 23 134 4.4.5.11.1. Name . . . . . . . . . . . . . . . . . . . . 23 135 4.4.5.11.2. Information Needed to Create a New Value . . 23 136 4.4.5.11.3. Registration policy . . . . . . . . . . . . 23 137 4.4.5.11.4. Content . . . . . . . . . . . . . . . . . . 23 138 4.5. Internal Services Registries . . . . . . . . . . . . . . 23 139 4.5.1. "serviceNames" Registry . . . . . . . . . . . . . . . 24 140 4.5.1.1. Name . . . . . . . . . . . . . . . . . . . . . . 24 141 4.5.1.2. Information Needed to Create a New Value . . . . 24 142 4.5.1.3. Registration policy . . . . . . . . . . . . . . . 24 143 4.5.1.4. Content . . . . . . . . . . . . . . . . . . . . . 24 144 4.5.2. "serviceState" Registry . . . . . . . . . . . . . . . 24 145 4.5.2.1. Name . . . . . . . . . . . . . . . . . . . . . . 24 146 4.5.2.2. Information Needed to Create a New Value . . . . 24 147 4.5.2.3. Registration policy . . . . . . . . . . . . . . . 25 148 4.5.2.4. Content . . . . . . . . . . . . . . . . . . . . . 25 149 4.5.3. "elementState" Registry . . . . . . . . . . . . . . . 25 150 4.5.3.1. Name . . . . . . . . . . . . . . . . . . . . . . 25 151 4.5.3.2. Information Needed to Create a New Value . . . . 25 152 4.5.3.3. Registration policy . . . . . . . . . . . . . . . 25 153 4.5.3.4. Content . . . . . . . . . . . . . . . . . . . . . 25 154 4.5.4. "SIPHeaderIsOperatorConditions" Registry . . . . . . 26 155 4.5.4.1. Name . . . . . . . . . . . . . . . . . . . . . . 26 156 4.5.4.2. Information Needed to Create a New Value . . . . 26 157 4.5.4.3. Registration policy . . . . . . . . . . . . . . . 26 158 4.5.4.4. Content . . . . . . . . . . . . . . . . . . . . . 26 159 4.5.5. "queueState" Registry . . . . . . . . . . . . . . . . 27 160 4.5.5.1. Name . . . . . . . . . . . . . . . . . . . . . . 27 161 4.5.5.2. Information Needed to Create a New Value . . . . 27 162 4.5.5.3. Registration policy . . . . . . . . . . . . . . . 27 163 4.5.5.4. Content . . . . . . . . . . . . . . . . . . . . . 27 164 4.5.6. "securityPosture" Registry . . . . . . . . . . . . . 27 165 4.5.6.1. Name . . . . . . . . . . . . . . . . . . . . . . 27 166 4.5.6.2. Information Needed to Create a New Value . . . . 28 167 4.5.6.3. Registration policy . . . . . . . . . . . . . . . 28 168 4.5.6.4. Content . . . . . . . . . . . . . . . . . . . . . 28 169 4.5.7. "ESRP Notify Event Code" Registry . . . . . . . . . . 28 170 4.5.7.1. Name . . . . . . . . . . . . . . . . . . . . . . 28 171 4.5.7.2. Information Needed to Create a New Value . . . . 28 172 4.5.7.3. Registration policy . . . . . . . . . . . . . . . 28 173 4.5.7.4. Content . . . . . . . . . . . . . . . . . . . . . 29 174 4.5.8. "Route Cause" Registry . . . . . . . . . . . . . . . 29 175 4.5.8.1. Name . . . . . . . . . . . . . . . . . . . . . . 29 176 4.5.8.2. Information Needed to Create a New Value . . . . 29 177 4.5.8.3. Registration policy . . . . . . . . . . . . . . . 29 178 4.5.8.4. Content . . . . . . . . . . . . . . . . . . . . . 29 179 4.5.9. "LogEvent" Registry . . . . . . . . . . . . . . . . . 30 180 4.5.9.1. Name . . . . . . . . . . . . . . . . . . . . . . 30 181 4.5.9.2. Information Needed to Create a New Value . . . . 30 182 4.5.9.3. Registration policy . . . . . . . . . . . . . . . 30 183 4.5.9.4. Content . . . . . . . . . . . . . . . . . . . . . 30 184 4.5.10. "LogEvent Protocol" Registry . . . . . . . . . . . . 30 185 4.5.10.1. Name . . . . . . . . . . . . . . . . . . . . . . 30 186 4.5.10.2. Information Needed to Create a New Value . . . . 31 187 4.5.10.3. Registration policy . . . . . . . . . . . . . . 31 188 4.5.10.4. Content . . . . . . . . . . . . . . . . . . . . 31 189 4.5.11. "LogEvent CallTypes" Registry . . . . . . . . . . . . 31 190 4.5.11.1. Name . . . . . . . . . . . . . . . . . . . . . . 31 191 4.5.11.2. Information Needed to Create a New Value . . . . 31 192 4.5.11.3. Registration policy . . . . . . . . . . . . . . 31 193 4.5.11.4. Content . . . . . . . . . . . . . . . . . . . . 31 194 4.5.12. "Call States" Registry . . . . . . . . . . . . . . . 32 195 4.5.12.1. Name . . . . . . . . . . . . . . . . . . . . . . 32 196 4.5.12.2. Information Needed to Create a New Value . . . . 32 197 4.5.12.3. Registration policy . . . . . . . . . . . . . . 32 198 4.5.12.4. Content . . . . . . . . . . . . . . . . . . . . 32 199 4.5.13. "LogEvent Announcement Types" Registry . . . . . . . 32 200 4.5.13.1. Name . . . . . . . . . . . . . . . . . . . . . . 33 201 4.5.13.2. Information Needed to Create a New Value . . . . 33 202 4.5.13.3. Registration policy . . . . . . . . . . . . . . 33 203 4.5.13.4. Content . . . . . . . . . . . . . . . . . . . . 33 204 4.5.14. "non-RTP Media Types" Registry . . . . . . . . . . . 33 205 4.5.14.1. Name . . . . . . . . . . . . . . . . . . . . . . 33 206 4.5.14.2. Information Needed to Create a New Value . . . . 33 207 4.5.14.3. Registration policy . . . . . . . . . . . . . . 33 208 4.5.14.4. Content . . . . . . . . . . . . . . . . . . . . 34 209 4.5.15. "Agency Roles" Registry . . . . . . . . . . . . . . . 34 210 4.5.15.1. Name . . . . . . . . . . . . . . . . . . . . . . 34 211 4.5.15.2. Information Needed to Create a New Value . . . . 34 212 4.5.15.3. Registration policy . . . . . . . . . . . . . . 34 213 4.5.15.4. Content . . . . . . . . . . . . . . . . . . . . 34 214 4.5.16. "Agent Roles" Registry . . . . . . . . . . . . . . . 34 215 4.5.16.1. Name . . . . . . . . . . . . . . . . . . . . . . 35 216 4.5.16.2. Information Needed to Create a New Value . . . . 35 217 4.5.16.3. Registration policy . . . . . . . . . . . . . . 35 218 4.5.16.4. Content . . . . . . . . . . . . . . . . . . . . 35 219 4.5.17. "Status Codes" Registry . . . . . . . . . . . . . . . 35 220 4.5.17.1. Name . . . . . . . . . . . . . . . . . . . . . . 35 221 4.5.17.2. Information Needed to Create a New Value . . . . 35 222 4.5.17.3. Registration policy . . . . . . . . . . . . . . 35 223 4.5.17.4. Content . . . . . . . . . . . . . . . . . . . . 36 224 4.5.18. "Interface Names" Registry . . . . . . . . . . . . . 36 225 4.5.18.1. Name . . . . . . . . . . . . . . . . . . . . . . 36 226 4.5.18.2. Information Needed to Create a New Value . . . . 36 227 4.5.18.3. Registration policy . . . . . . . . . . . . . . 36 228 4.5.18.4. Content . . . . . . . . . . . . . . . . . . . . 36 229 4.5.19. "Match Type" Registry . . . . . . . . . . . . . . . . 36 230 4.5.19.1. Name . . . . . . . . . . . . . . . . . . . . . . 37 231 4.5.19.2. Information Needed to Create a New Value . . . . 37 232 4.5.19.3. Registration policy . . . . . . . . . . . . . . 37 233 4.5.19.4. Content . . . . . . . . . . . . . . . . . . . . 37 234 4.5.20. "GIS Layers" Registry . . . . . . . . . . . . . . . . 37 235 4.5.20.1. Name . . . . . . . . . . . . . . . . . . . . . . 37 236 4.5.20.2. Information Needed to Create a New Value . . . . 37 237 4.5.20.3. Registration policy . . . . . . . . . . . . . . 37 238 4.5.20.4. Content . . . . . . . . . . . . . . . . . . . . 38 239 4.5.21. "Policy Type" Registry . . . . . . . . . . . . . . . 38 240 4.5.21.1. Name . . . . . . . . . . . . . . . . . . . . . . 38 241 4.5.21.2. Information Needed to Create a New Value . . . . 38 242 4.5.21.3. Registration policy . . . . . . . . . . . . . . 38 243 4.5.21.4. Content . . . . . . . . . . . . . . . . . . . . 38 244 4.5.22. "Discrepancy Report Status Token" Registry . . . . . 39 245 4.5.22.1. Name . . . . . . . . . . . . . . . . . . . . . . 39 246 4.5.22.2. Information Needed to Create a New Value . . . . 39 247 4.5.22.3. Registration policy . . . . . . . . . . . . . . 39 248 4.5.22.4. Content . . . . . . . . . . . . . . . . . . . . 39 249 4.5.23. "Event Package" Registry . . . . . . . . . . . . . . 40 250 4.5.23.1. Name . . . . . . . . . . . . . . . . . . . . . . 40 251 4.5.23.2. Information Needed to Create a New Value . . . . 40 252 4.5.23.3. Registration policy . . . . . . . . . . . . . . 40 253 4.5.23.4. Content . . . . . . . . . . . . . . . . . . . . 40 254 4.5.24. "LoggingServiceMediaErrorReasonCodes" Registry . . . 40 255 4.5.24.1. Name . . . . . . . . . . . . . . . . . . . . . . 40 256 4.5.24.2. Information Needed to Create a New Value . . . . 40 257 4.5.24.3. Registration policy . . . . . . . . . . . . . . 41 258 4.5.24.4. Content . . . . . . . . . . . . . . . . . . . . 41 259 4.5.24.5. Initial Values . . . . . . . . . . . . . . . . . 41 260 4.6. EIDO Registries . . . . . . . . . . . . . . . . . . . . . 41 261 4.6.1. "EIDO-AgencyRole" Registry . . . . . . . . . . . . . 41 262 4.6.1.1. Name . . . . . . . . . . . . . . . . . . . . . . 41 263 4.6.1.2. Information Needed to Create a New Value . . . . 42 264 4.6.1.3. Registration policy . . . . . . . . . . . . . . . 42 265 4.6.1.4. Content . . . . . . . . . . . . . . . . . . . . . 42 266 4.6.2. "EIDO-IncidentType-Common" Registry . . . . . . . . . 42 267 4.6.2.1. Name . . . . . . . . . . . . . . . . . . . . . . 42 268 4.6.2.2. Information Needed to Create a New Value . . . . 42 269 4.6.2.3. Registration policy . . . . . . . . . . . . . . . 42 270 4.6.2.4. Content . . . . . . . . . . . . . . . . . . . . . 43 271 4.6.3. "EIDO-IncidentStatus-Common" Registry . . . . . . . . 43 272 4.6.3.1. Name . . . . . . . . . . . . . . . . . . . . . . 43 273 4.6.3.2. Information Needed to Create a New Value . . . . 43 274 4.6.3.3. Registration policy . . . . . . . . . . . . . . . 43 275 4.6.3.4. Content . . . . . . . . . . . . . . . . . . . . . 43 276 4.6.4. "EIDO-ReportNumberType" Registry . . . . . . . . . . 43 277 4.6.4.1. Name . . . . . . . . . . . . . . . . . . . . . . 44 278 4.6.4.2. Information Needed to Create a New Value . . . . 44 279 4.6.4.3. Registration policy . . . . . . . . . . . . . . . 44 280 4.6.4.4. Content . . . . . . . . . . . . . . . . . . . . . 44 281 4.6.5. "EIDO-CommonDispositionCode" Registry . . . . . . . . 44 282 4.6.5.1. Name . . . . . . . . . . . . . . . . . . . . . . 44 283 4.6.5.2. Information Needed to Create a New Value . . . . 44 284 4.6.5.3. Registration policy . . . . . . . . . . . . . . . 45 285 4.6.5.4. Content . . . . . . . . . . . . . . . . . . . . . 45 286 4.6.6. "EIDO-PersonRole" Registry . . . . . . . . . . . . . 45 287 4.6.6.1. Name . . . . . . . . . . . . . . . . . . . . . . 45 288 4.6.6.2. Information Needed to Create a New Value . . . . 45 289 4.6.6.3. Registration policy . . . . . . . . . . . . . . . 45 290 4.6.6.4. Content . . . . . . . . . . . . . . . . . . . . . 45 291 4.6.7. "EIDO-VehicleRelationshipType" Registry . . . . . . . 46 292 4.6.7.1. Name . . . . . . . . . . . . . . . . . . . . . . 46 293 4.6.7.2. Information Needed to Create a New Value . . . . 46 294 4.6.7.3. Registration policy . . . . . . . . . . . . . . . 46 295 4.6.7.4. Content . . . . . . . . . . . . . . . . . . . . . 46 296 4.6.8. "EIDO-LocationType" Registry . . . . . . . . . . . . 46 297 4.6.8.1. Name . . . . . . . . . . . . . . . . . . . . . . 46 298 4.6.8.2. Information Needed to Create a New Value . . . . 46 299 4.6.8.3. Registration policy . . . . . . . . . . . . . . . 47 300 4.6.8.4. Content . . . . . . . . . . . . . . . . . . . . . 47 301 4.6.9. "EIDO-PrimaryUnitStatus-Common" Registry . . . . . . 47 302 4.6.9.1. Name . . . . . . . . . . . . . . . . . . . . . . 47 303 4.6.9.2. Information Needed to Create a New Value . . . . 47 304 4.6.9.3. Registration policy . . . . . . . . . . . . . . . 47 305 4.6.9.4. Content . . . . . . . . . . . . . . . . . . . . . 47 306 4.6.10. "EIDO-SecondaryUnitStatus-Common" Registry . . . . . 48 307 4.6.10.1. Name . . . . . . . . . . . . . . . . . . . . . . 48 308 4.6.10.2. Information Needed to Create a New Value . . . . 48 309 4.6.10.3. Registration policy . . . . . . . . . . . . . . 48 310 4.6.10.4. Content . . . . . . . . . . . . . . . . . . . . 48 311 4.6.11. "EIDO-EmergencyResourceType-Common" Registry . . . . 48 312 4.6.11.1. Name . . . . . . . . . . . . . . . . . . . . . . 48 313 4.6.11.2. Information Needed to Create a New Value . . . . 48 314 4.6.11.3. Registration policy . . . . . . . . . . . . . . 49 315 4.6.11.4. Content . . . . . . . . . . . . . . . . . . . . 49 316 4.6.12. "EIDO-ResourceAttribute" Registry . . . . . . . . . . 49 317 4.6.12.1. Name . . . . . . . . . . . . . . . . . . . . . . 49 318 4.6.12.2. Information Needed to Create a New Value . . . . 49 319 4.6.12.3. Registration policy . . . . . . . . . . . . . . 49 320 4.6.12.4. Content . . . . . . . . . . . . . . . . . . . . 49 321 4.6.13. "eidoExtensionId" Registry . . . . . . . . . . . . . 50 322 4.6.13.1. Name . . . . . . . . . . . . . . . . . . . . . . 50 323 4.6.13.2. Information Needed to Create a New Value . . . . 50 324 4.6.13.3. Registration policy . . . . . . . . . . . . . . 50 325 4.6.13.4. Content . . . . . . . . . . . . . . . . . . . . 50 326 5. Security Considerations . . . . . . . . . . . . . . . . . . . 50 327 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 328 6.1. Normative References . . . . . . . . . . . . . . . . . . 51 329 6.2. Informative References . . . . . . . . . . . . . . . . . 51 330 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 53 331 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 333 1. Introduction 335 [RFC6443] establishes a framework for carrying emergency calls over 336 the Internet using the SIP ( [RFC3261] ) protocol. Various regional 337 organizations are developing standards for how calls conforming to 338 this framework are handled within the Emergency Services IP Networks 339 (ESInets) established by local, regional or national authorities to 340 handle such calls and deliver them to the appropriate Public Safety 341 Answering Point (PSAP). Many of these standards have needed 342 registries of values used in the protocols and services the services 343 define. Prior to this document, such registries were managed by the 344 regional SDOs themselves. There is a desire among many of the 345 regional emergency services SDOs to have a single world-wide standard 346 for handling emergency calls and as part of that effort, a single set 347 of registries managed by a neutral party. This document requests 348 IANA to establish a new registry area called "Emergency" and to 349 create a set of registries within that area. This document does not 350 describe initial contents of the registries. That will be 351 accomplished by requests from the regional SDOs, including The NENA 352 i3 Standard [NENAi3]. 354 1.1. Requirements Language 356 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 357 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 358 document are to be interpreted as described in RFC 2119 [RFC2119] . 360 2. Acknowledgements 362 Thanks to the workgroups and committees at NENA: The 9-1-1 363 Association, especially the Core Services Agency Systems Committees, 364 as well as ETSI and EENA for their contributions to unify 365 international emergency calling standards. 367 3. Conventions used in this document 369 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 370 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 371 document are to be interpreted as described in [RFC2119]. 373 In this document, "NG9-1-1" is use to describe next-generation 374 emergency calling services generally and is meant to include NG112 375 initiatives ongoing in Europe ([NG112]). 377 4. IANA Considerations 379 This document creates a number of registries. The initial values for 380 these registries are not defined and will be submitted by regional 381 and international SDOs such as NENA and ETSI. 383 4.1. "emergency" URN namespace 385 IANA is requested to register a new URN namespace for "emergency". 387 4.1.1. Namespace Identifier 389 emergency 391 4.1.2. Version 393 1 395 4.1.3. Date 397 RFC Editor: please insert the date this RFC was published 399 4.1.4. Registrant 401 IETF and the ecrit Working Group. Should the working group cease to 402 exist, discussion should be directed to the Applications and Real- 403 Time Area or general IETF discussion forums, or the IESG. 405 4.1.5. Purpose 407 This namespace is used for unique identifiers for use in emergency 408 services, including emergency calls. Most uses for this identifiers 409 will be used within private "Emergency Services IP Networks" 410 (ESInets), some use in the public Internet is expected. These 411 identifiers will be used in several countries, and hopefully, 412 eventually, worldwide for handling of emergency calls and incidents. 413 Prior to this document, North American emergency services used the 414 "nena" nid, defined in [RFC6061]. Most identifiers in urn:nena will 415 be replaced by identifiers in urn:emergency in pursuit of a single 416 worldwide standard set for emergency services which are not 417 controlled by a single public safety organization like NENA. 418 Identifiers with this nid do not require resolution. Identifiers in 419 this nid will primarily specified in public safety standards SDOs, 420 but some IETF standards may use or define them. 422 4.1.6. Syntax 424 The basic syntax for identifiers in the emergency nid is: 426 urn:emergency::<:extended> 428 where 430 is a member of the urn:emergency namespace 431 registry, see Section 4.4 433 is a class-specific value defined by the document 434 describing the registry entry. In many cases, the extension includes 435 sub classes. For example: 436 urn:emergency:service:responder:police.local 438 There are no special encoding rules for identifiers in urn:emergency. 439 URN equivalence is non-case sensitive. Hyphens are not expected in 440 these identifiers, but if used, they are significant in comparisons. 441 Quotes are not allowed in this nid. There are no special 442 considerations for conforming to URN syntax. Percent encoding is 443 permitted. There are no uses for q-components or f-components in 444 this namespace. 446 4.1.7. Assignment 448 Assignment of top level classes is by standards documents, both 449 standards-track RFCs and standards documents in other SDOs. See 450 Section 4.4. Assignments within top level classes are defined in the 451 document that defines the class. Such documents MUST specify how 452 uniqueness within the class is achieved. 454 4.1.8. Security and Privacy 456 Each top level class, in its defining document MUST describe the 457 security and privacy considerations of that class. In general, there 458 are no special security consierations for these identifiers. Several 459 top level classes are defined in this document. In some 460 circumstances, these identifiers may indicate what kind of agency is 461 involved with a public safety incident, and some may identify a 462 specific agency. Encryption of the communications that contain the 463 identifier in classes defined in this document is REQUIRED and MUST 464 be TLS or an equally secure protocol. 466 4.1.9. Interoperability 468 Many of the identifiers in urn:emergency are similar in construction 469 and use as identifiers originally defined in urn:nena. Backwards 470 compatibility with those identifiers MUST be specified in the 471 documents that use them. NENA STA-010.3-2021 is the primary document 472 that has this backwards compatibility requirement, as it defined most 473 of the identifiers in urn:nena. There are no other interoperability 474 issues. 476 4.1.10. Resolution 478 No resolution of these identifiers is defined. 480 4.2. "Emergency" Area 482 IANA is requested to establish the registries within this section 483 under the "Emergency" area. These registries contain enumerated 484 values used for emergency calling. New registries or subregistrues 485 in the "Emergency" area require a standards document, which MAY be a 486 standards track RFC, but also MAY be a defined in a document from a 487 recognized standards organization that promulgates emergency services 488 standards. Where a new registry or subregistry is defined in an 489 external standards organization, an expert SHALL review the document 490 to ascertain that it is relevant to the "Emergency" area, that the 491 organization defining the registry is a recognized standards 492 organization, that the document clearly articulates the management 493 method for the regisry, which MUST be substantially similar to one or 494 more of the management methods in [RFC8216], and if expert review is 495 specified, that experts acceptable to the IESG for the registry are 496 available. The expert reviewing the new registry shall also request 497 IANA to review the relevant documents using the same criteria as it 498 would for a standards track RFC. The expert SHALL NOT approve the 499 new registry unless IANA is satisfied it can maintain the registry 500 with the same or similar level of effort it expends for similar 501 registries created by RFCs. If the management of the registry is 502 specified as First Come First Served, which, per RFC8126 does not 503 require an expert, an expert acceptable to the IESG must be available 504 to answer questions about registrations and advise IANA of any issues 505 in registrations in that registry. 507 These registries are required to implement The NENA i3 Standard for 508 Next-Generation 9-1-1 [NENAi3] as well as the NENA Standard for 509 Emergency Incident Data Object [EIDO]. These standards, unless 510 otherwise specified, will initially populate the registries created 511 by this document. Some registries previously existed in the NENA 512 Registry System [NRS], but the intent of international SDOs is to 513 maintain next-generation emergency calling registries under IANA in 514 the future. [NRS] will be maintained only for backwards 515 compatibility, and for registries required only for North America. 517 4.3. Emergency Call Additional Data Registry 519 IANA is requested to move the Emergency Call Additional Data registry 520 and its sub-registries to the Emergency Area 522 4.4. "urn:emergency" registry 524 IANA is requested to create a registry for the emergency nid top 525 level classes in the emergency area. 527 4.4.1. Name 529 urn:emergency 531 4.4.2. Information Needed to Create a New Value 533 Name of the top level class, a short description and a reference to a 534 document that defines it. 536 4.4.3. Registration policy 538 Specification Required [RFC8126], which requires expert review. The 539 specification MUST be from the IETF or a recognized standards 540 organization that creates standards for emergency services. The 541 expert must confirm the requested class is appropriate for emergency 542 services, if the registering organization is not the IETF, that it is 543 an appropriate organization to define the class, that the purpose 544 adequately describes the new class and the reference leads to a 545 document that clearly describes the use of the class. Also see 546 Section 4.4.5 548 4.4.4. Content 550 This registry contains: 552 * The ASCII "Name" of the "top level" class (a short string) 554 * The ASCII "Purpose" of the label (explanatory text) 555 * A "Reference" (URI) to the standard that defines the label 557 4.4.5. Subregistries for top level classes of urn:emergency 559 In most cases, top level classes of urn:emergency will define 560 subregistries. Several levels of subregistries may be needed. The 561 document that defines the class MUST define the subregistry if 562 needed. IETF and emergency service standards organizations MAY 563 define subregistries of urn:nena. Instructions to IANA for the 564 subregistry MUST conform to [RFC8126]. The expert reviewer for the 565 top level class works with IANA to assure that they do if the 566 standards organization creating the subregistry is not the IETF. 568 4.4.5.1. "urn:emergency:service" Subregistry 570 IANA is requested to create a subregistry for "urn:emergency:service" 571 under "urn:emergency". 573 When calls are routed within an Emergency Services IP Network 574 (ESInet), the routing element queries a LoST [RFC5222] server for the 575 (nominal) route. It does so with a service URN. Esternal routing is 576 accomplished with "urn:service:sos", as defined by [RFC5031]. Within 577 an ESInet, values under this registry are used. 579 Service URNs as defined here begin with "urn:emergency:service". The 580 sub-namespace defined by this registry MAY be further subdivided 581 (potentially several times), by sub-registries under this sub- 582 registry. The separator between urn:emergency:service and the entry 583 in the subregistry is a colon (":"). A new entry starting with 584 "urn:emergency:service" SHOULD denote a new type of route, which MUST 585 be distinguished by the LoST server from other uses. For example, 586 emergency calls being routed within the ESInet use 587 "urn:emergency:service:sos" (or a subspace of it). Calls routed by a 588 PSAP to a responder use "urn:emergency:service:responder" (the type 589 of responder is also included, e.g., 590 "urn:emergency:service:responder.police"). A client specifies the 591 URN in a LoST query, and the LoST Server uses it to choose a 592 (nominal) route. 594 4.4.5.1.1. Name 596 urn:emergency:service 598 4.4.5.1.2. Information Needed to Create a New Value 600 Name of the entry, a short description and a reference to a document 601 that defines it. 603 4.4.5.1.3. Registration policy 605 Specification Required [RFC8126], which requires expert review. The 606 specification MUST be from the IETF or a recognized standards 607 organization that creates standards for emergency services. The 608 expert must confirm the requested entry is appropriate for emergency 609 services, if the registering organization is not the IETF, that it is 610 an appropriate organization to define the entry, that the purpose 611 adequately describes the new entry and the reference leads to a 612 document that clearly describes the use of the entry. Also see 613 Section 4.4.5 615 4.4.5.1.4. Content 617 This registry contains: 619 * The ASCII "Name" of the value (a short string) 621 * The ASCII "Purpose" of the value (explanatory text) 623 * A "Reference" (URI) to the document that defines the value 625 4.4.5.2. "urn:emergency:service:sos" Subregistry 627 IANA is requested to creates a subregistry for 628 "urn:emergency:service:sos" under "urn:emergency:service". 630 Routing of emergency calls within the ESInet is a primary function of 631 systems that process such calls. When routing entities must route 632 calls within the ESInet, they query the LoST Server for the route. 633 Routing for emergency calls may involve multiple levels of routing 634 entities. Each level may need a different URN to be distinguishable. 635 Routing of emergency calls, including instant messages and non- 636 interactive calls within an ESInet, is accomplished with a URN 637 beginning with "urn:emergency:service:sos". The 638 "urn:emergency:service:sos" registry contains values appropriate for 639 the various levels of routing within the ESInet. The separator 640 between urn:emergency:service:sos and entry in the subregistry is a 641 colon (":"). 643 4.4.5.2.1. Name 645 urn:emergency:service:sos 647 4.4.5.2.2. Information Needed to Create a New Value 649 Name of the entry, a short description and a reference to a document 650 that defines it. 652 4.4.5.2.3. Registration policy 654 Specification Required [RFC8126], which requires expert review. The 655 specification MUST be from the IETF or a recognized standards 656 organization that creates standards for emergency services. The 657 expert must confirm the requested class is appropriate for emergency 658 services, if the registering organization is not the IETF, that it is 659 an appropriate organization to define the class, that the purpose 660 adequately describes the new class and the reference leads to a 661 document that clearly describes the use of the class. Also see 662 Section 4.4.5 664 4.4.5.2.4. Content 666 This registry contains: 668 * The ASCII "Name" of the service value (a short string) 670 * The ASCII "Purpose" of the value (explanatory text) 672 * A "Reference" (URI) to the document that defines the value 674 4.4.5.3. "urn:emergency:service:test" Registry 676 IANA is requested to creates a subregistry for 677 "urn:emergency:service:test" under "urn:emergency:service". 679 Test calls are directed to "urn:service:test.sos". To route such 680 test calls where the routing infrastructure uses multiple levels of 681 routing, and thus uses URNs in the "urn:emergency:service:sos" 682 registry, service URNs are needed for test calls with similar levels. 683 IANA is requested to create an entry in the "urn:emergency:service" 684 registry with the name "test" and with the purpose noted as "routing 685 test calls within the ESInet toward a primary PSAP". The reference 686 will be to the registry created by this section, 687 "urn:emergency:service:test". The separator between the "test" label 688 and the service ("urn:emergency:service:test" registry entry) is a 689 period ".". The "urn:emergency:service:test" registry contains label 690 values corresponding to the levels in the "urn:emergency:service:sos" 691 registry. These registries are normally kept in sync, an entry added 692 to "urn:emergency:service:sos" should also add a corresponding entry 693 to urn:emergency:service:test. 695 4.4.5.3.1. Name 697 urn:emergency:service:test 699 4.4.5.3.2. Information Needed to Create a New Value 701 Name of the entry, a short description and a reference to a document 702 that defines it. 704 4.4.5.3.3. Registration policy 706 Specification Required [RFC8126], which requires expert review. 707 Normally, entries in urn:emergency:service:test mirror those in 708 urn:emergency:service:sos. If there are any discrepancies the expert 709 shall determine if the requested entry meets the use defined above 710 and the specification document adequately describes how the entry is 711 used. 713 4.4.5.3.4. Content 715 The content of this registry should mirror the content of 716 urn:service:test:sos except with the "test" label as described above. 718 4.4.5.4. "urn:emergency:service:responder" Registry 720 IANA is requested to create the "urn:emergency:service:responder" 721 subregistry under "urn:emergency:service" 723 Once a PSAP gets a call, they may have to transfer the call to a 724 secondary PSAP. The secondary PSAP is chosen based on the type of 725 responder, and the location of the caller. Routing of emergency 726 calls from a PSAP towards a responder is accomplished with a URN 727 beginning with "urn:emergency:service:responder". IANA is requested 728 to create an entry in the "urn:emergency:service" registry with the 729 name "responder" and with the purpose noted as "routing emergency 730 calls within the ESInet towards a responder". The reference will be 731 to the registry created by this section, 732 "urn:emergency:service:responder". 734 The "urn:emergency:service:responder" registry contains label values 735 appropriate for the types of responders within the ESInet. The 736 separator between the "responder" label and the type of responder 737 ("urn:emergency:service:responder" registry value) is a period ".". 738 This registry is also used in other contexts where an agency type is 739 useful. For those purposes, a 'psap' entry is provided. 740 "urn:emergency:service:responder.psap" must not be used to route 741 emergency calls. It is not equivalent to, or a substitute for 742 "urn:service:sos" or "urn:emergency:service:sos". 744 Some of the entries in this registry will require further 745 subdivision. Subregistries for such divisions are REQUIRED. 747 4.4.5.4.1. Name 749 urn:emergency:service:responder 751 4.4.5.4.2. Information Needed to Create a New Value 753 Name of the entry, a short description and a reference to a document 754 that defines it. 756 4.4.5.4.3. Registration policy 758 Specification Required [RFC8126], which requires expert review. The 759 expert should confirm that entry represents a kind of responder, 760 considered broadly. For example, a tow truck operator may be 761 considered a responder. 763 4.4.5.4.4. Content 765 This registry contains: 767 * The ASCII "Name" of the responder (a short string) 769 * The ASCII "Purpose" of the responder (explanatory text) 771 * A "Reference" (URI) to a document that defines the label 773 4.4.5.5. "urn:emergency:service:responder.police" Subregistry 775 There are many different kinds of law enforcement agencies that have 776 distinct differences in jurisdiction and formation (for example, 777 police department organized under a municipal government as opposed 778 to the sheriff's office organized under an elected sheriff). This 779 subregistry delineates different types of police agenices under the 780 urn:emergency:service:responder:police registry. The separator 781 between urn:emergency:responder.police and the entry in this 782 subregistry is a period ("."). 784 4.4.5.5.1. Name 786 urn:emergency:service:responder.police 788 4.4.5.5.2. Information Needed to Create a New Value 790 Name of the entry, a short description and a reference to a document 791 that defines it. 793 4.4.5.5.3. Registration policy 795 Specification Required [RFC8126], which requires expert review. The 796 expert should confirm that entry represents a kind of police 797 department, considered broadly. The names used for various kinds of 798 police departments varies from country to country. The expert is 799 requested to try to minimize the number of entries in the registry, 800 but is not expected to have to learn the details of how police forces 801 are organized in any country. An English name is preferred, to match 802 the existing entries 804 4.4.5.5.4. Content 806 This registry contains: 808 * The UTF-8 "Name" of the agency type 810 * The ASCII "Description" of the agency type 812 * A "Reference" with a URI either to the document that defines the 813 entry. 815 Note that the Name is defined as UTF-8, to permit names that have no 816 English equivalent 818 4.4.5.6. "police.federal" Subregistry 820 There are several federal police agencies. This registry is a 821 subregistry of "urn:emergency:service:responder.police." and lists 822 each police agency operating at the federal/national level. The 823 "federal.police" registry contains label values appropriate for the 824 types of national police responders within the ESInet. This is 825 distinct from the parent subregistry, "police.federal", is the 826 police.federal subregistry includes the names for specific federal 827 agencies, as opposed to the "responder.police" subregistry which 828 indicated the agency TYPE (police). The separator between the 829 "police.federal" label and the type of responder 830 ("urn:emergency:service:responder.police.federal" registry value) is 831 a period ".". 833 4.4.5.6.1. Name 835 urn:emergency:service:responder.police.federal 837 4.4.5.6.2. Information Needed to Create a New Value 839 Short and long forms of the entry and a reference to a document that 840 defines it or a person that requested the enty. 842 4.4.5.6.3. Registration policy 844 Expert Review. No standards document required. The expert should 845 confirm that entry represents a kind of federal police department, 846 considered broadly. As this is a specific agency, entries for 847 different countries may be different. 849 4.4.5.6.4. Content 851 This registry contains: 853 * The UTF-8 short "Name" of the agency, usually an abbreviation 854 (e.g., "FBI") 856 * The UTF-8 "Full Name" of the agency (e.g., "Federal Bureau of 857 Investigation") 859 * A "Reference" with a URI either to the document requested the 860 registry entry or contact contact information for the individual 861 who contributed the value. 863 Note that the Name is defined as UTF-8, and locally significant names 864 are expressly permitted. 866 4.4.5.7. "urn:emergency:service:responder.fire" Subregistry 868 This registry has similar purposes as the "responder.police" 869 subregistry, except for types of fire response agencies (for example, 870 "forest" or "private"). 872 4.4.5.7.1. Name 874 urn:emergency:service:responder.fire 876 4.4.5.7.2. Information Needed to Create a New Value 878 Name of the entry, a short description and a reference to a document 879 that specifies the entry. 881 4.4.5.7.3. Registration policy 883 Specification Required [RFC8126], which requires expert review. The 884 expert should confirm that entry represents a kind of fire 885 department, considered broadly. The names used for various kinds of 886 fire departments varies from country to country. The expert is 887 requested to try to minimize the number of entries in the registry, 888 but is not expected to have to learn the details of how fire 889 departments are organized in any country. An English name is 890 preferred, to match the existing entries 892 4.4.5.7.4. Content 894 This registry contains: 896 * The UTF-8 "Name" of the agency type 898 * The ASCII "Description" of the agency type 900 * A "Reference" with a URI to the document that specifies the entry. 902 Note that the Name is defined as UTF-8, to permit names that have no 903 English equivalent 905 4.4.5.8. "urn:emergency:service:responder.ems" Subregistry 907 This registry has similar purposes as the "responder.police" 908 subregistry, except for types of Emergency Medical Service response 909 agencies (for example, "Local" or "countyParish"). 911 4.4.5.8.1. Name 913 urn:emergency:service:responder.ems 915 4.4.5.8.2. Information Needed to Create a New Value 917 Name of the entry, a short description and a reference to a document 918 that specifies the entry. 920 4.4.5.8.3. Registration policy 922 Specification Required [RFC8126], which requires expert review. The 923 expert should confirm that entry represents a kind of emergency 924 medical service, considered broadly. The names used for various 925 kinds of emergency medical services varies from country to country. 926 The expert is requested to try to minimize the number of entries in 927 the registry, but is not expected to have to learn the details of how 928 emergency medical services are organized in any country. An English 929 name is preferred, to match the existing entries 931 4.4.5.8.4. Content 933 This registry contains: 935 * The UTF-8 "Name" of the agency type 937 * The ASCII "Description" of the agency type 938 * A "Reference" with a URI to the document that specifies the entry. 940 Note that the Name is defined as UTF-8, to permit names that have no 941 English equivalent 943 4.4.5.9. "urn:emergency:service:serviceAgencyLocator" Subregistry 945 The ESInet will connect to many services and public safety agencies. 946 A directory ("white pages" and "yellow pages") of agencies, together 947 with key information about the service or agency, is the function of 948 the Service/Agency Locator. The Service/Agency Locator is a 949 distributed database. There are several mechanisms by which the 950 Service/Agency Locator can be searched to locate a specific service 951 or agency. When searching for a service by location, the LoST 952 protocol ([RFC5222] is used, which accepts a URN that specifies the 953 service being searched by location. This registry provides urns to 954 be used witha LoST query to find that service at a particular 955 location. 957 4.4.5.9.1. Name 959 urn:emergency:service:serviceAgencyLocator 961 4.4.5.9.2. Information Needed to Create a New Value 963 Short and long versions of the service and a reference to a document 964 that specifies it. 966 4.4.5.9.3. Registration policy 968 Specification Required [RFC8126], which requires expert review. The 969 expert should confirm that entry represents a kind of service the 970 Service/Agency Locator holds information for. 972 4.4.5.9.4. Content 974 This subregistry contains: 976 * The "Service Identifier" of the service (e.g."ESRP") 978 * The long "Service" name of the service (e.g., "Emergency Services 979 Routing Proxy") 981 * A "Reference" with a URI to the document that requested the 982 service. 984 4.4.5.10. "urn:emergency:uid" Registry 986 Various entities need to create globally unique identifiers. A 987 simple way to do that is to combine a locally unique identifier and a 988 domain name (which is globally unique). However, many entities need 989 to create more than one type of globally unique identifier and 990 knowing what type of identifier is helpful in diagnosing problems. 991 For this purpose, the uid URN subregistry creates unique strings used 992 to prepend identifiers that indicate the type of identifier it is. 994 This document does not describe the structure of the identifier 995 beyond the urn:emergency:uid prefix and the value in this registry. 996 The defining specification MUST describe the structure of the 997 identifier. 999 4.4.5.10.1. Name 1001 urn:emergency:uid 1003 4.4.5.10.2. Information Needed to Create a New Value 1005 Name of the entry, a short description and a reference to a document 1006 that specifies the entry. 1008 4.4.5.10.3. Registration policy 1010 Specification Required [RFC8126], which requires expert review. The 1011 expert should confirm that entry represents a new type of identifier, 1012 and specifies the structure of that identifier. 1014 4.4.5.10.4. Content 1016 this registry contains: 1018 * The UTF-8 "Name" of the identifier prefix 1020 * The UTF-8 "Purpose" of the identifier prefix 1022 * A "Reference" with a URI to the document that requested the 1023 registry entry. 1025 4.4.5.11. "urn:emergency:media-feature" Registry 1027 SIP Media Feature tags as defined in [RFC3840] are used to indicate 1028 user agent capabilities. SIP elements inside ESInets use this 1029 mechanism to indicate availablity of certain emergency call specific 1030 functionality. Since these media feature tags are specific to 1031 emergency calling, are primarily defined in non-IETF documents and 1032 not used outside an ESInet, they are not appropriate for registration 1033 in the SIP Media Feature Tag Registry. This registry provides a 1034 similar function to the registry defined in RFC3840. The separator 1035 between the "urn:emergency:media-feature" and the content of this 1036 registry is a colon (":"). 1038 4.4.5.11.1. Name 1040 urn:emergency:media-feature 1042 4.4.5.11.2. Information Needed to Create a New Value 1044 A short tag, purpose description and a reference to a document that 1045 specifies the entry. 1047 4.4.5.11.3. Registration policy 1049 Specification Required [RFC8126], which requires expert review. The 1050 expert should confirm that entry represents a new type of SIP media 1051 feature tag and specifies how it is used. 1053 4.4.5.11.4. Content 1055 This registry contains: 1057 * A short ASCII "Tag" 1059 * A long ASCII "Purpose" 1061 * A "Reference" with a URI to the document that requested the 1062 registry entry. 1064 4.5. Internal Services Registries 1066 The following are additional registries used internally in an ESInet 1067 /> 1069 4.5.1. "serviceNames" Registry 1071 Processing of emergency calls uses a variety of services which are 1072 queried either using SIP or HTTP. These services are discoverable 1073 through the ESInet that has deployed an instance of these services. 1074 In order to faciliate interoperability there is need to codify their 1075 names in a registry. IANA is requested creates the ServiceNames 1076 registry in the Emergency area. 1078 4.5.1.1. Name 1080 serviceNames 1082 4.5.1.2. Information Needed to Create a New Value 1084 Short and long names of the service and a reference to a document 1085 that specifies the service. 1087 4.5.1.3. Registration policy 1089 Specification Required [RFC8126], which requires expert review. The 1090 expert should confirm that entry represents a new type of service. 1092 4.5.1.4. Content 1094 This registry contains: 1096 * An ASCII short "Service Name" of the service (e.g., "ADR") 1098 * An ASCII long "Service" name of the service (e.g., "Additional 1099 Data Repository") 1101 * A "Reference", a URI to the document that defines the service. 1103 4.5.2. "serviceState" Registry 1105 All services have a common notion of "state" which comes from this 1106 registry. 1108 4.5.2.1. Name 1110 serviceNames 1112 4.5.2.2. Information Needed to Create a New Value 1114 Name and description of the state and a reference to a document that 1115 specifies it. 1117 4.5.2.3. Registration policy 1119 Specification Required [RFC8126], which requires expert review. The 1120 expert should confirm that entry represents a new type of identifier, 1121 and specifies the structure of that identifier. 1123 4.5.2.4. Content 1125 This registry contains: 1127 * The short "Name" of the service state (e.g., "Normal" or 1128 "ScheduledMaintenanceDown") 1130 * The long "Description" of the service state (e.g., "The service is 1131 operating normally. Calls can be sent to this destination 1132 normally.") 1134 * A "Reference" with a URI to the document that defines the state. 1136 4.5.3. "elementState" Registry 1138 Services are instantiated in physical servers or other equipment, 1139 each of which is called an "element". Typically, multiple elements 1140 are configured for a service for redundancy, and an instance of 1141 multiple services can be instantiated in one element. Elements have 1142 a common notion of state which comes from this registry. 1144 4.5.3.1. Name 1146 elementState 1148 4.5.3.2. Information Needed to Create a New Value 1150 Name and description of the state and a reference to a document that 1151 specifies it. 1153 4.5.3.3. Registration policy 1155 Specification Required [RFC8126], which requires expert review. The 1156 expert should confirm that entry represents a new state and the 1157 specification adequately describes it. 1159 4.5.3.4. Content 1161 This registry contains: 1163 * The short "Name" of the element state (e.g., "Normal" or 1164 "ScheduledMaintenanceDown") 1166 * The long "Description" of the element state (e.g., "The service is 1167 operating normally. Calls can be sent to this element normally.") 1169 * A "Reference" with a URI to the document that defines the state. 1171 4.5.4. "SIPHeaderIsOperatorConditions" Registry 1173 Some emergency standards use a policy based routing mechanism where a 1174 policy rule has a series of testable conditions. One such condition 1175 is "SIPHeaderCondition" which tests a SIP header field in the INVITE 1176 or MESSAGE of a call (such as "From", "To", "Contact", etc.). 1177 SIPHeaderCondition has an "operator" member has three potential 1178 values: 1180 * "EQ" for an equality match 1182 * "SS" for a substring match 1184 * "IS" for a registry-defined match 1186 The latter condition includes a value from this registry and tests 1187 the header with the criteria defined for the value 1189 4.5.4.1. Name 1191 SIPHeaderIsOperatorConditions 1193 4.5.4.2. Information Needed to Create a New Value 1195 Name and description of the test and a reference to a document that 1196 specifies it. 1198 4.5.4.3. Registration policy 1200 Specification Required [RFC8126], which requires expert review. The 1201 expert should confirm that entry represents a new test and the 1202 specification adequately describes it. 1204 4.5.4.4. Content 1206 This registry contains: 1208 * A short UTF-8 "Name" 1210 * The long UTF-8 "Description" 1212 * A "Reference" with a URI to the document that requested the 1213 registry entry. 1215 4.5.5. "queueState" Registry 1217 In some emergency services standards emergency calls are delivered to 1218 queues. The state of a queue is standardized, and this registry 1219 defines the allowed states of a queue. 1221 4.5.5.1. Name 1223 queueState 1225 4.5.5.2. Information Needed to Create a New Value 1227 Short name and description of the state and a reference to a document 1228 that specifies it. 1230 4.5.5.3. Registration policy 1232 Specification Required [RFC8126], which requires expert review. The 1233 expert should confirm that entry represents a new state and the 1234 specification adequately describes it. 1236 4.5.5.4. Content 1238 This registry contains: 1240 * A short ASCII "Name" 1242 * The long ASCII "Description" 1244 * A "Reference" with a URI to the document that requested the 1245 registry entry. 1247 4.5.6. "securityPosture" Registry 1249 Emergency Services agencies may be attacked in an effort to disrupt 1250 their services. Some emergency services standards allow for various 1251 elements, services and other entities to communicate their current 1252 security status, ranging on a color scale from Green to Red. This 1253 allows downstram and upstream entities to evaluate the current 1254 security conditions of a given entity, such as other parts of the 1255 system or a Security Operations Center. 1257 4.5.6.1. Name 1259 securityPosture 1261 4.5.6.2. Information Needed to Create a New Value 1263 Name and purpose of the state and a reference to a document that 1264 specifies it. 1266 4.5.6.3. Registration policy 1268 Specification Required [RFC8126], which requires expert review. The 1269 expert should confirm that entry represents a new security posture, 1270 the value is consistent with the existing values and the 1271 specification adequately describes it. 1273 4.5.6.4. Content 1275 This registry contains: 1277 * A short ASCII "Value" 1279 * The long ASCII "Purpose" 1281 * A "Reference" with a URI to the document that requested the 1282 registry entry. 1284 4.5.7. "ESRP Notify Event Code" Registry 1286 An Emergency Services Routing Proxy routes emergency calls using a 1287 policy based routing mechanism. The policy mechanism includes a 1288 function that can notify an entity when it encounters a defined 1289 condition. This registry defines a common set of codes that tell the 1290 recipient why it received the notification. 1292 4.5.7.1. Name 1294 ESRP Notify Event Code 1296 4.5.7.2. Information Needed to Create a New Value 1298 Name and description of the code and a reference to a document that 1299 specifies it. 1301 4.5.7.3. Registration policy 1303 Specification Required [RFC8126], which requires expert review. The 1304 expert should confirm that entry represents a new code and the 1305 specification adequately describes it. 1307 4.5.7.4. Content 1309 This registry contains: 1311 * A short ASCII "Name" 1313 * The long ASCII "Description" 1315 * A "Reference" with a URI to the document that requested the 1316 registry entry. 1318 4.5.8. "Route Cause" Registry 1320 The Emergency Services Routing Proxy routes calls using its Policy 1321 Routing Function. The result of evaluating a rule set is a Route 1322 action that routes the call towards a PSAP or responder. The Route 1323 action includes a Cause value, which is placed in a SIP Reason header 1324 associated with a History-Info header that informs the recipient why 1325 it got the call. A registry is provided for the values in the cause. 1326 The Route action cause is an enumeration, but the Reason header has a 1327 numeric cause value and a text string. IANA is requested to create a 1328 registry to enumerate allowable Route Cause values. 1330 4.5.8.1. Name 1332 Route Cause 1334 4.5.8.2. Information Needed to Create a New Value 1336 Short value, integer code, description of the cause and a reference 1337 to a document that specifies it. 1339 4.5.8.3. Registration policy 1341 Specification Required [RFC8126], which requires expert review. The 1342 expert should confirm that entry represents a new cause, the code is 1343 unique and appropriate, and the specification adequately describes 1344 it. 1346 4.5.8.4. Content 1348 This registry contains: 1350 * The ASCII "Value" (a short string) 1352 * The "Code" value (a 3-digit integer) 1354 * The ASCII "Text" description (explanatory text, a string) 1355 * A "Reference" (URI) to a document that requests the entry 1357 4.5.9. "LogEvent" Registry 1359 In emergency services, logging is used extensively. Some emergency 1360 services standards define the interface to the loging service and the 1361 format of the data logged. Each event that occurs has a separately 1362 logged "event", and the name and parameters of each type of event are 1363 standardized. The "logEvent" registry enumerates the types of log 1364 records that can be logged. 1366 4.5.9.1. Name 1368 logEvent 1370 4.5.9.2. Information Needed to Create a New Value 1372 Name and purpose of the log event and a reference to a document that 1373 specifies it. 1375 4.5.9.3. Registration policy 1377 Specification Required [RFC8126], which requires expert review. The 1378 expert should confirm that entry represents a new log event and the 1379 specification adequately describes it. 1381 4.5.9.4. Content 1383 This registry contains: 1385 * The ASCII "Name" (a short string) 1387 * The ASCII "Purpose" (explanatory text, a string) 1389 * A "Reference" (URI) to a document that requests the entry 1391 4.5.10. "LogEvent Protocol" Registry 1393 In the CallSignalingMessage log event, the protocol of the message 1394 must be logged. This registry provides a registry for the protocol 1395 used for the logging event. 1397 4.5.10.1. Name 1399 LogEvent Protocol 1401 4.5.10.2. Information Needed to Create a New Value 1403 Name a reference to a document that specifies the protocol. 1405 4.5.10.3. Registration policy 1407 Specification Required [RFC8126], which requires expert review. The 1408 expert should confirm that entry represents a new protocol and the 1409 specification is an appropriate definition for the protocol. 1411 4.5.10.4. Content 1413 This registry contains: 1415 * The ASCII "Name" of the protocol used (a short string) 1417 * A "Reference" to a document that requests the entry, such as an 1418 RFC 1420 4.5.11. "LogEvent CallTypes" Registry 1422 The type of Call is logegd with the StartCall and EndCall LogEvents. 1423 The StartCall log event includes a "callType" parameter. These call 1424 types are enumerated in this registry. The logEvent allows a call to 1425 have primary and secondary call types. The registry denotes which 1426 call types may be primary call types and which may be secondary 1428 4.5.11.1. Name 1430 LogEvent CallType 1432 4.5.11.2. Information Needed to Create a New Value 1434 Name and description of the call type and a reference to a document 1435 that specifies it and the classification (primary or secondary) of 1436 the call type. 1438 4.5.11.3. Registration policy 1440 Specification Required [RFC8126], which requires expert review. The 1441 expert should confirm that entry represents a new call type, the 1442 specification adequately describes it and the classification is 1443 appropriate. 1445 4.5.11.4. Content 1447 This registry contains: 1449 * The ASCII "Name" (e.g., "emergency") (a short string) 1451 * The ASCII "Description" (e.g., "Call is deemed urgent call and 1452 treated as such") (explanatory text, a string) 1454 * The ASCII "Classification" (e.g., "Primary") (a string) 1456 * A "Reference" (URI) to a document that requests the entry 1458 4.5.12. "Call States" Registry 1460 The state of an emergncy call is logged when it changes (e.g., 1461 "callBegin" or "callAnswered"). Each change in state is associated 1462 with a log event for that change in state. Many of these log events 1463 correlate with transactions in SIP. 1465 4.5.12.1. Name 1467 Call States 1469 4.5.12.2. Information Needed to Create a New Value 1471 Name and purpose of the state and a reference to a document that 1472 specifies it. 1474 4.5.12.3. Registration policy 1476 Specification Required [RFC8126], which requires expert review. The 1477 expert should confirm that entry represents a new state and the 1478 specification adequately describes it. 1480 4.5.12.4. Content 1482 This registry contains: 1484 * The ASCII "Name" (a short string) 1486 * The ASCII "Purpose" (explanatory text, a string) 1488 * A "Reference" (URI) to a document that requests the entry 1490 4.5.13. "LogEvent Announcement Types" Registry 1492 In some circumstances where a call taker is not available 1493 immediately, an automated system may play a (potentially multimedia) 1494 announcement to the caller. A log event records the playback. This 1495 registry defines the generic type of announcement that was played to 1496 the caller. 1498 4.5.13.1. Name 1500 LogEvent Announcement Type 1502 4.5.13.2. Information Needed to Create a New Value 1504 Name and purpose of the announcement type and a reference to a 1505 document that specifies it. 1507 4.5.13.3. Registration policy 1509 Specification Required [RFC8126], which requires expert review. The 1510 expert should confirm that entry represents a new announcement type 1511 and the specification adequately describes it. 1513 4.5.13.4. Content 1515 This registry contains: 1517 * The ASCII "Name" (a short string) 1519 * The ASCII "Purpose" (explanatory text, a string) 1521 * A "Reference" (URI) to a document that requests the entry 1523 4.5.14. "non-RTP Media Types" Registry 1525 Most media in an emergency calls uses Real Time Transport Protocol 1526 (RTP), [RFC3550]. LogEvents for RTP transported media record what 1527 kind of media was used in the call. To record what kind of media was 1528 used when RTP is not the transport protocol (such as, for example, 1529 instant messaging), values in this registry are used in the log 1530 event. 1532 4.5.14.1. Name 1534 non-RTP Media Types 1536 4.5.14.2. Information Needed to Create a New Value 1538 Name and description of the media 1540 4.5.14.3. Registration policy 1542 Specification Required [RFC8126], which requires expert review. The 1543 expert should confirm that entry represents a new type of media not 1544 carried in RTP. 1546 4.5.14.4. Content 1548 This registry contains: 1550 * The ASCII "Name" (a short string) 1552 * The ASCII "Description" (explanatory text, a string) 1554 4.5.15. "Agency Roles" Registry 1556 In handling emergency calls Agencies are classified by a specified 1557 Agency Role (e.g., "Dispatch). The role of the agency should not be 1558 confused with the type of agency (such as "Fire"). Agency types are 1559 enumerated in this registry. 1561 4.5.15.1. Name 1563 Agency Roles 1565 4.5.15.2. Information Needed to Create a New Value 1567 Name and description of the role 1569 4.5.15.3. Registration policy 1571 Specification Required [RFC8126], which requires expert review. The 1572 expert should confirm that entry represents a new type of role. 1574 4.5.15.4. Content 1576 This registry contains: 1578 * The ASCII "Role" (a short string) 1580 * The ASCII "Description" (explanatory text, a string) 1582 * A "Reference" (URI) with either contact information for the entity 1583 that or a URI to the document that requests the entry. 1585 4.5.16. "Agent Roles" Registry 1587 Agents are people or automata that are associated with an agency. 1588 Agents have roles (e.g., "Dispatching", "Calltaking"). Agency types 1589 are enumerated in this registry. 1591 4.5.16.1. Name 1593 Agent Roles 1595 4.5.16.2. Information Needed to Create a New Value 1597 Name and description of the role 1599 4.5.16.3. Registration policy 1601 Specification Required [RFC8126], which requires expert review. The 1602 expert should confirm that entry represents a new type of role. 1604 4.5.16.4. Content 1606 This registry contains: 1608 * The ASCII "Role" (a short string) 1610 * The ASCII "Description" (explanatory text, a string) 1612 * A "Reference" (URI) with either contact information for the entity 1613 that or a URI to the document that requests the entry. 1615 4.5.17. "Status Codes" Registry 1617 Interfaces in the standards used by this registry use standard status 1618 codes where appropriate. However there are many circumstances where 1619 a more specific error code is used within an ESInet. This registry 1620 enumerates the codes. 1622 4.5.17.1. Name 1624 Status Codes 1626 4.5.17.2. Information Needed to Create a New Value 1628 Status code and text used in the response 1630 4.5.17.3. Registration policy 1632 Specification Required [RFC8126], which requires expert review. The 1633 expert should confirm that entry represents a new status code, the 1634 numeric value is appropriate and the specification adequately 1635 describes its use. 1637 4.5.17.4. Content 1639 This registry contains: 1641 * The "Status Code" (a 3 digit integer) 1643 * The ASCII "Description" (explanatory text, a string) 1645 * A "Reference" (URI) to the document that requests the entry. 1647 4.5.18. "Interface Names" Registry 1649 Emergency standards define interfaces that are used by other services 1650 and elements within an ESInet. Policy based access control 1651 mechanisms are used to control use of the interfaces. The policy 1652 uses the entries in this registry to name the interface the policy 1653 applies to. 1655 4.5.18.1. Name 1657 Interface Names 1659 4.5.18.2. Information Needed to Create a New Value 1661 Name of the interface 1663 4.5.18.3. Registration policy 1665 Specification Required [RFC8126], which requires expert review. The 1666 expert should confirm that entry represents a new interface. 1668 4.5.18.4. Content 1670 This registry contains: 1672 * The ASCII "Name" (a short string) 1674 * A "Reference" (URI) to a document that requests the entry 1676 4.5.19. "Match Type" Registry 1678 When using the LoST protocol [RFC5222] to validate a location prior 1679 to using it in an emergency call, a match against a civic address 1680 record in the LoST server may not be the most specific record 1681 intended by the Location Information Server. This arises because 1682 authorities may not have incomplete records. The emergency standards 1683 define an extension to LoST that returns the type of record that 1684 matched the location information in the LoST request. This registry 1685 enumerates the match types that can be returned. 1687 4.5.19.1. Name 1689 Match Type 1691 4.5.19.2. Information Needed to Create a New Value 1693 Name of the interface 1695 4.5.19.3. Registration policy 1697 Specification Required [RFC8126], which requires expert review. The 1698 expert should confirm that entry represents a new interface. 1700 4.5.19.4. Content 1702 This registry contains: 1704 * The UTF-8 "Token" (a short string) (e.g., "Road Centerline" or 1705 "Hybrid"). 1707 * The ASCII "Description" (explanatory text, a string) 1709 * A "Reference" (URI) to a document that requests the entry 1711 4.5.20. "GIS Layers" Registry 1713 A Geospatial Information System (GIS) contains features (points, 1714 lines, polygons, etc.) each with a set of attributes, organized in 1715 "layers". Layers (such as discipline-specific service regions, road 1716 centerlines, address points, etc. are common in GIS systems used by 1717 emergency services. This registry enumerates the names of layers 1718 that are used for emergency services alongf with a shorter version 1719 that may be used in databases or interfaces. 1721 4.5.20.1. Name 1723 GIS Layers 1725 4.5.20.2. Information Needed to Create a New Value 1727 Full name of the layer and a short version of the name 1729 4.5.20.3. Registration policy 1731 Specification Required [RFC8126], which requires expert review. The 1732 expert should confirm that entry represents a new GIS layer. 1734 4.5.20.4. Content 1736 This registry contains: 1738 * The UTF-8 Full "Name" 1740 * The UTF-8 "Layer Indicator" 1742 * A "Reference" (URI) to a document that requests the entry 1744 4.5.21. "Policy Type" Registry 1746 Policy is widely used in emergency services standards to allow 1747 agencies to control the use of their information, control how routing 1748 is accomplished within an ESInet, and several other instances. 1749 Policies are housed in a standardized "Policy Store". Policies have 1750 a type, which identifies how they are used. This registry enumerates 1751 policy types a Policy Store may have. 1753 4.5.21.1. Name 1755 Policy Type 1757 4.5.21.2. Information Needed to Create a New Value 1759 Type, format and use of the policy 1761 4.5.21.3. Registration policy 1763 Specification Required [RFC8126], which requires expert review. The 1764 expert should confirm that entry represents a new interface. 1766 4.5.21.4. Content 1768 This registry contains: 1770 * The UTF-8 "Type" of the policy (a short string) (e.g., "LoST") 1772 * The UTF-8 "Format" of the policy (e.g., "XACML") 1774 * The UTF-8 "Use" of the policy (e.g., "Access rights for Spatial 1775 Interface") 1777 * A "Reference" (URI) to a document that requests the entry 1779 4.5.22. "Discrepancy Report Status Token" Registry 1781 Errors and discrepancies may occur in any set of data, including 1782 databases, configurations, etc. Standardized Discrepancy Report (DR) 1783 functions allow reporting and responding to reports of discrepancies 1784 across vendors. Various types of DRs and responses are defined in 1785 the standards. Many of the reports and/or responses have elements 1786 that are tokens in a restricted list. This registry enumerates the 1787 tokens, and where they can be used. 1789 The registry contains the name of the element in the DR object that 1790 uses the token, and the DR type that uses that element. More than 1791 one element could use the same token, and more than one DR type could 1792 use the same element name (and token values). This means 1793 registration requests can specify more than one value in the "Name" 1794 and "DiscrepancyReports" columns, and a new registration can add a 1795 value to "Name" or "Discrepancy Report" for an existing entry. 1797 4.5.22.1. Name 1799 Discrepancy Report Status Token 1801 4.5.22.2. Information Needed to Create a New Value 1803 Token, Member Name where token is used, Discrepancy Report where 1804 token is used 1806 4.5.22.3. Registration policy 1808 Specification Required [RFC8126], which requires expert review. The 1809 expert should confirm that entry represents a new interface. 1811 4.5.22.4. Content 1813 This registry contains: 1815 * The ASCII "Token" of the DR (a short string) (e.g., 1816 "LocationReferenceNotResolved") 1818 * The ASCII "Member" of the type of DR (e.g., "Problem" or "Query"). 1819 More than one is allowed 1821 * The ACII "Discrepancy Reports" of included discrepancy report(s) 1822 included (e.g., "LoSTDiscrepancyResponse, BCFDiscrepancyReport). 1823 More than one is allowed. 1825 * A "Reference" (URI) to document(s) that request the entry 1827 4.5.23. "Event Package" Registry 1829 SIP Event Package registration procedures are defined in [RFC5727] 1830 and are applicable for any SIP events used on the Internet. For use 1831 within an ESInet only, emergency standards define several SIP Event 1832 packages that are not specified in IETF RFCs. This registry 1833 enumerates those event packages. 1835 4.5.23.1. Name 1837 Event Package 1839 4.5.23.2. Information Needed to Create a New Value 1841 Name of the Event Package 1843 4.5.23.3. Registration policy 1845 Specification Required [RFC8126], which requires expert review. The 1846 expert should confirm that the event package is documented roughly 1847 similar to SIP Event Package registration requirements in [RFC5727]. 1849 4.5.23.4. Content 1851 This registry contains: 1853 * The ASCII "Name" (a short string) 1855 * A "Reference" (URI) to a document that requests the entry 1857 4.5.24. "LoggingServiceMediaErrorReasonCodes" Registry 1859 When logging real time media in an ESInet, the recording mechanism 1860 may fail, and a log event, RecordingFailedLogEvent is defined to log 1861 that failure. The reason why the media recording failed is 1862 documented with an entry from this registry. 1864 4.5.24.1. Name 1866 LoggingServiceMediaErrorReasonCodes 1868 4.5.24.2. Information Needed to Create a New Value 1870 Name and description of the reason code. 1872 4.5.24.3. Registration policy 1874 Specification Required [RFC8126], which requires expert review. The 1875 expert should confirm that the the entry represents a new reason for 1876 media failure. 1878 4.5.24.4. Content 1880 This registry contains: 1882 * The ASCII "Name" (a short string) 1884 * The ASCII "Description" (explanatory text, a string) 1886 * A "Reference" (URI) to a document that requests the entry 1888 4.5.24.5. Initial Values 1890 +================+====================================+===========+ 1891 | Name | Description | Reference | 1892 +================+====================================+===========+ 1893 | lostConnection | The connection to the SRS was lost | This | 1894 | | and could not be re-established | document | 1895 +----------------+------------------------------------+-----------+ 1896 | dropOuts | There were significant number of | This | 1897 | | missing media packets | document | 1898 +----------------+------------------------------------+-----------+ 1900 Table 1: Initial Values 1902 4.6. EIDO Registries 1904 Following are registries needed to implement the Emergency Incident 1905 Data Object, the standard way to represent incident state when passed 1906 between entities in an ESInet or other emergency services networks, 1907 [EIDO]. 1909 4.6.1. "EIDO-AgencyRole" Registry 1911 The role of the agency in relation to the Incident (e.g., "Call 1912 Receiving", "Dispatching", "Dispatched"). This may differ from 1913 agency role as defined in the Agency Role registry. 1915 4.6.1.1. Name 1917 EIDO-AgencyRole 1919 4.6.1.2. Information Needed to Create a New Value 1921 Value and description of the role. 1923 4.6.1.3. Registration policy 1925 Specification Required [RFC8126], which requires expert review. The 1926 expert should confirm that the the entry represents a new role. 1928 4.6.1.4. Content 1930 This registry contains: 1932 * The UTF-8 "Value" (a short string) 1934 * The UTF-8 "Literal Description" (a short string) 1936 * A "Reference" (URI) to a document that requests the entry 1938 4.6.2. "EIDO-IncidentType-Common" Registry 1940 When multiple agencies are involved in an incident, the type of 1941 incident must be communicated clearly. Many agencies have internal 1942 incident typing systems that are incompatible with each other. The 1943 Association of Public Safety Communications Offials (APCO) has 1944 documented a set of incident types which are the original basis for 1945 this registry ([APCO]), but there is no registry of codes. This 1946 registry forms the complete listing of common type codes. 1948 4.6.2.1. Name 1950 EIDO-IncidentType-Common 1952 4.6.2.2. Information Needed to Create a New Value 1954 Name and description of the reason code. 1956 4.6.2.3. Registration policy 1958 Specification Required [RFC8126], which requires expert review. The 1959 expert should confirm that the the entry represents a new incident 1960 type. Generally this registry should track the APCO document, but 1961 additional codes are allowed to be added provided they are unique 1962 from the APCO codes and are adequately documented in the 1963 specification. 1965 4.6.2.4. Content 1967 This registry contains: 1969 * The ASCII "Value" (a short string) 1971 * The ASCII "Literal Description" (a short string) 1973 * A "Reference" (URI) to a document that requests the entry 1975 4.6.3. "EIDO-IncidentStatus-Common" Registry 1977 When multiple agencies are involved in an incident, the status of 1978 incident must be communicated clearly. Many agencies have internal 1979 incident status reporting systems that are incompatible with each 1980 other. This registry enumerates status codes used in an EIDO. 1982 4.6.3.1. Name 1984 EIDO-IncidentStatus-Common 1986 4.6.3.2. Information Needed to Create a New Value 1988 Name and description of the staus code. 1990 4.6.3.3. Registration policy 1992 Specification Required [RFC8126], which requires expert review. The 1993 expert should confirm that the the entry represents a new incident 1994 status. 1996 4.6.3.4. Content 1998 This registry contains: 2000 * The ASCII "Value" (a short string) 2002 * The ASCII "Literal Description" (a short string) 2004 * A "Reference" (URI) to a document that requests the entry 2006 4.6.4. "EIDO-ReportNumberType" Registry 2008 Used to indicate the current status of the report number associated 2009 with an incident. If a report number is present in an EIDO, it is 2010 required to indicate the current status of the report number (.e.g, 2011 "New" or "Ongoing"). This registry enumerates the allowed statuses 2013 4.6.4.1. Name 2015 EIDO-ReportNumberType 2017 4.6.4.2. Information Needed to Create a New Value 2019 Name and description of the type. 2021 4.6.4.3. Registration policy 2023 Specification Required [RFC8126], which requires expert review. The 2024 expert should confirm that the the entry represents a new report 2025 number type. 2027 4.6.4.4. Content 2029 This registry contains: 2031 * The UTF-8 "Value" (a short string) 2033 * The UTF-8 "Literal Description" (a short string) 2035 * A "Reference" (URI) to a document that requests the entry 2037 4.6.5. "EIDO-CommonDispositionCode" Registry 2039 An agency assigns a disposition to an incident when its participation 2040 in the incident ends. The disposition code indicates whether follow- 2041 up reports are required and conveys other information about the 2042 incident, such as whether it resulted from a false or actual alarm. 2043 They are used to exchange the status and follow up requirements of an 2044 incident upon its closure. The disposition codes are drawn from a 2045 registry containing common disposition codes for Police, Fire and EMS 2046 disciplines. These codes are defined by [APCO1.111] and implemented 2047 by [EIDO]. 2049 APCO ANS 1.111.2-2018 uses a two-digit integer as an incident status 2050 code. IANA is also requested to hold values 46-100 for future 2051 versions of the standard. 2053 4.6.5.1. Name 2055 EIDO-CommonDispositionCode 2057 4.6.5.2. Information Needed to Create a New Value 2059 Name and description of the disposition code. 2061 4.6.5.3. Registration policy 2063 Specification Required [RFC8126], which requires expert review. The 2064 expert should confirm that the the entry represents a new incident 2065 type. Generally this registry should track the APCO document, but 2066 additional codes are allowed to be added provided they are unique 2067 from the APCO codes and are adequately documented in the 2068 specification. 2070 4.6.5.4. Content 2072 This registry contains: 2074 * The 2 or 3 digit integer code 2076 * The ASCII "Literal Description" (a short string) 2078 * A "Reference" (URI) to a document that requests the entry 2080 4.6.6. "EIDO-PersonRole" Registry 2082 EIDOs may contain Person objects that describe a person someohow 2083 involved in an incident. The "role" of a person in an EIDO describes 2084 the relationship (Caller, Victim, suspect, etc.) of a person to the 2085 incident. This registry enumerates allowable roles. A person can 2086 have multiple roles in an incident. 2088 4.6.6.1. Name 2090 EIDO-PersonRole 2092 4.6.6.2. Information Needed to Create a New Value 2094 Name and description of the role. 2096 4.6.6.3. Registration policy 2098 Specification Required [RFC8126], which requires expert review. The 2099 expert should confirm that the the entry represents a new role. 2101 4.6.6.4. Content 2103 This registry contains: 2105 * The ASCII "Value" (a short string) 2107 * The ASCII "Literal Description" (a short string) 2108 * A "Reference" (URI) to a document that requests the entry 2110 4.6.7. "EIDO-VehicleRelationshipType" Registry 2112 A VehicleRelationshipType describes the relationship (victim's 2113 vehicle, accident vehicle, suspect vehicle, etc.) of a vehicle to the 2114 incident. This registry enumerate the allowable relationship types 2115 allowed. 2117 4.6.7.1. Name 2119 EIDO-VehicleRelationshipType 2121 4.6.7.2. Information Needed to Create a New Value 2123 Name and description of the relationship type. 2125 4.6.7.3. Registration policy 2127 Specification Required [RFC8126], which requires expert review. The 2128 expert should confirm that the the entry represents a new 2129 relationship type. 2131 4.6.7.4. Content 2133 This registry contains: 2135 * The ASCII "Value" (a short string) 2137 * The ASCII "Literal Description" (a short string) 2139 * A "Reference" (URI) to a document that requests the entry 2141 4.6.8. "EIDO-LocationType" Registry 2143 A LocationType conveys the location type (Caller, Initial, 2144 CurrentIncident, Staging, Investigation, Tower Location, etc.) of a 2145 location and its relationship to an ongoing incident. This registry 2146 enumerate the allowed LocationTypes. 2148 4.6.8.1. Name 2150 EIDO-LocationType 2152 4.6.8.2. Information Needed to Create a New Value 2154 Name and description of the relationship type. 2156 4.6.8.3. Registration policy 2158 Specification Required [RFC8126], which requires expert review. The 2159 expert should confirm that the the entry represents a new 2160 relationship type. 2162 4.6.8.4. Content 2164 This registry contains: 2166 * The ASCII "Value" (a short string) 2168 * The ASCII "Literal Description" (a short string) 2170 * A "Reference" (URI) to a document that requests the entry 2172 4.6.9. "EIDO-PrimaryUnitStatus-Common" Registry 2174 A PrimaryUnitStatus-Common is a standardized code for the current 2175 status of an emergency response units (e.g., whether a fire engine is 2176 "available" or "notAvailable"). This registry enumerates the allowed 2177 primary status codes. Primary status is a fundamental status 2178 ("notAvailable") rather than a "why" the unit is in that status. See 2179 Section 4.6.10 for the latter information. 2181 4.6.9.1. Name 2183 EIDO-PrimaryUnitStatus-Common 2185 4.6.9.2. Information Needed to Create a New Value 2187 Name and description of the status code. 2189 4.6.9.3. Registration policy 2191 Specification Required [RFC8126], which requires expert review. The 2192 expert should confirm that the the entry represents a new primary 2193 unit status. 2195 4.6.9.4. Content 2197 This registry contains: 2199 * The ASCII "Value" (a short string) 2201 * The ASCII "Literal Description" (a short string) 2203 * A "Reference" (URI) to a document that requests the entry 2205 4.6.10. "EIDO-SecondaryUnitStatus-Common" Registry 2207 Statuses that further qualifies the Primary Unit Status by providing 2208 more detail about the associated primary status. This registry 2209 enumerates the allowed secondary status values. 2211 4.6.10.1. Name 2213 EIDO-SecondaryUnitStatus-Common 2215 4.6.10.2. Information Needed to Create a New Value 2217 Name and description of the status. 2219 4.6.10.3. Registration policy 2221 Specification Required [RFC8126], which requires expert review. The 2222 expert should confirm that the the entry represents a new secondary 2223 unit status. 2225 4.6.10.4. Content 2227 This registry contains: 2229 * The ASCII "Value" (a short string) 2231 * The ASCII "Literal Description" (a short string) 2233 * A "Reference" (URI) to a document that requests the entry 2235 4.6.11. "EIDO-EmergencyResourceType-Common" Registry 2237 A standardized code for an emergency resource type (e.g., BombSquad, 2238 AirAmbulanceRotaryWing). Resource Types are teams and/equipment as 2239 opposed to individuals with a skill set. This registry enumerates 2240 allowed resource types. 2242 4.6.11.1. Name 2244 EIDO-EmergencyResourceType-Common 2246 4.6.11.2. Information Needed to Create a New Value 2248 Name and description of the resource type. 2250 4.6.11.3. Registration policy 2252 First Come, First Served and Expert Review. The expert should 2253 confirm that the the entry represents a new resource type. Use of 2254 trademarked names, or vendor specific terms is discouraged. 2256 4.6.11.4. Content 2258 This registry contains: 2260 * The UTF-8 "Value" (a short string) 2262 * The UTF-8 "Literal Description" (a short string) 2264 * A "Reference" (URI) to a document that requests the entry 2266 4.6.12. "EIDO-ResourceAttribute" Registry 2268 A standard code for an emergency resource attribute (skill and 2269 equipment; e.g., "EMSPhysician, "EMT", "SCBA". Also indicates an 2270 interpreter's translation abilities, such as "UkranianInterpreter") 2271 possessed by an emergency resource). This registry enumerates the 2272 allowed attributes. 2274 4.6.12.1. Name 2276 EIDO-ResourceAttribute 2278 4.6.12.2. Information Needed to Create a New Value 2280 Name and description of the resource attribute. 2282 4.6.12.3. Registration policy 2284 Expert Review. No standards document required. The expert should 2285 confirm that the the entry represents a new resource attribute. Use 2286 of trademarked names, or vendor specific terms is discouraged. 2288 4.6.12.4. Content 2290 This registry contains: 2292 * The UTF-8 "Value" (a short string) 2294 * The UTF-8 "Literal Description" (a short string) 2296 * A "Reference" (URI) to a document that requests the entry 2298 4.6.13. "eidoExtensionId" Registry 2300 Vendors and users are highly likely to need to extend an EIDO to 2301 handle capabilities not common to all implementations. It is useful 2302 to at least list all such extensions and provide a way to inform 2303 others of what they are. This registry provides a way to inform 2304 others about a proprietary extension to the EIDO. 2306 4.6.13.1. Name 2308 EIDO-Resource Attribute 2310 4.6.13.2. Information Needed to Create a New Value 2312 Owner, contact, unique identifier, description and a reference to a 2313 schema. Note that the "Contact" may not be in English and therefore 2314 is specified as UTF-8. 2316 4.6.13.3. Registration policy 2318 Expert Review. No standards document required. The expert should 2319 confirm that the the entry is complete, the provided URIs resolve to 2320 reasonable locations and the ID is unique. 2322 4.6.13.4. Content 2324 This registry contains: 2326 * The UTF-8 "Owner" of the extension (either a person or an 2327 organization) (a short string) 2329 * A stable "Contact" (URI) to contact the Owner 2331 * The ASCII "ID" (a unique short string) 2333 * The ASCII "Literal Description" (a short string) 2335 * A "Reference" (URI) to the extension schema 2337 5. Security Considerations 2339 This document only defines registries populated by other documents, 2340 not how they are used. As such there are no special security 2341 considerations introduced by this document, outside of those 2342 considerations specific to a given registry (e.g., the 2343 "securityPosture" registry), although those considerations are 2344 introduced by the source document and not this one. 2346 6. References 2348 6.1. Normative References 2350 [APCO] Association of Public Safety Communications Officials 2351 International, "APCO 2.103.2-2019 Public Safety 2352 Communications Common Incident Types for Data Exchange", 2353 2019, . 2357 [APCO1.111] 2358 Association of Public Safety Communications Officials 2359 International, "APCO ANS 1.111.2-2018 Public Safety 2360 Communications Common Disposition Codes for Data 2361 Exchange", 2018, . 2364 [EIDO] NENA: the 9-1-1 Association, "NENA Standard for Emergency 2365 Incident Data Object (Public Review Draft)", May 2021, 2366 . 2369 [NENAi3] NENA: the 9-1-1 Association, "NENA i3 Standard for Next- 2370 Generation 9-1-1, Version 3 ("i3 Version 3")", April 2021, 2371 . 2373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2374 Requirement Levels", BCP 14, RFC 2119, 2375 DOI 10.17487/RFC2119, March 1997, 2376 . 2378 6.2. Informative References 2380 [GIS] NENA: the 9-1-1 Association, "NENA Standard for Next- 2381 Generation 9-1-1 GIS Data Model", February 2020, 2382 . 2384 [i3v2] NENA: the 9-1-1 Association, "NENA Detailed Functional and 2385 Interface Standards for the NENA i3 Solution ("i3 Version 2386 2").", August 2016, 2387 . 2390 [NG112] European Emergency Number Association, "EENA NG112 2391 Project", May 2020, 2392 . 2394 [NRS] NENA: the 9-1-1 Association, "NENA Registry System", 2395 . 2397 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2398 A., Peterson, J., Sparks, R., Handley, M., and E. 2399 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2400 DOI 10.17487/RFC3261, June 2002, 2401 . 2403 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2404 Jacobson, "RTP: A Transport Protocol for Real-Time 2405 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2406 July 2003, . 2408 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2409 "Indicating User Agent Capabilities in the Session 2410 Initiation Protocol (SIP)", RFC 3840, 2411 DOI 10.17487/RFC3840, August 2004, 2412 . 2414 [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic 2415 Network Media Services with SIP", RFC 4240, 2416 DOI 10.17487/RFC4240, December 2005, 2417 . 2419 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 2420 (SIP) Event Package for Key Press Stimulus (KPML)", 2421 RFC 4730, DOI 10.17487/RFC4730, November 2006, 2422 . 2424 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 2425 Emergency and Other Well-Known Services", RFC 5031, 2426 DOI 10.17487/RFC5031, January 2008, 2427 . 2429 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 2430 Tschofenig, "LoST: A Location-to-Service Translation 2431 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 2432 . 2434 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2435 IANA Considerations Section in RFCs", RFC 5226, 2436 DOI 10.17487/RFC5226, May 2008, 2437 . 2439 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 2440 for the Session Initiation Protocol (SIP) and the Real- 2441 time Applications and Infrastructure Area", BCP 67, 2442 RFC 5727, DOI 10.17487/RFC5727, March 2010, 2443 . 2445 [RFC6061] Rosen, B., "Uniform Resource Name (URN) Namespace for the 2446 National Emergency Number Association (NENA)", RFC 6061, 2447 DOI 10.17487/RFC6061, January 2011, 2448 . 2450 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 2451 "Framework for Emergency Calling Using Internet 2452 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2453 2011, . 2455 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 2456 DOI 10.17487/RFC6665, July 2012, 2457 . 2459 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2460 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2461 DOI 10.17487/RFC7231, June 2014, 2462 . 2464 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2465 Writing an IANA Considerations Section in RFCs", BCP 26, 2466 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2467 . 2469 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 2470 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 2471 . 2473 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 2474 RFC 8216, DOI 10.17487/RFC8216, August 2017, 2475 . 2477 [StatusCodes] 2478 Internet Assigned Numbers Authority, "Hypertext Transfer 2479 Protocol (HTTP) Status Code Registry", September 2018, 2480 . 2483 Appendix A. Additional Stuff 2485 This becomes an Appendix. 2487 Authors' Addresses 2489 Brian Rosen 2490 Unaffiliated 2491 Mars, PA 2492 Us 2494 Email: br@brianrosen.net 2496 Brandon Abley (editor) 2497 NENA 2498 Alexandria, VA 2499 Us 2501 Email: babley@nena.org