Internet DRAFT - draft-rosen-ecrit-emergency-registries
draft-rosen-ecrit-emergency-registries
ecrit B. Rosen
Internet-Draft Unaffiliated
Intended status: Informational B. Abley, Ed.
Expires: 27 January 2023 NENA
26 July 2022
Emergency Registries
draft-rosen-ecrit-emergency-registries-01
Abstract
Multiple emergency services standards organizations are developing
standards based on IETF emergency call standards and other IETF
protocols. There is a desire among these organizations to use common
registries not tied to a particular country or national Standards
Development Organization (SDO), in the long term pursuit of a single
worldwide standard. This document asks IANA to create a set of
registries and provides processes for expanding the set and
populating them.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Rosen & Abley Expires 27 January 2023 [Page 1]
Internet-Draft Emergency Registries July 2022
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 8
2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
3. Conventions used in this document . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4.1. SIP Reason Protocols . . . . . . . . . . . . . . . . . . 9
4.1.1. Protocol Value . . . . . . . . . . . . . . . . . . . 9
4.1.2. Protocol Cause . . . . . . . . . . . . . . . . . . . 9
4.1.3. Reference . . . . . . . . . . . . . . . . . . . . . . 9
4.2. "emergency" URN namespace . . . . . . . . . . . . . . . . 9
4.2.1. Namespace Identifier . . . . . . . . . . . . . . . . 9
4.2.2. Version . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Date . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.4. Registrant . . . . . . . . . . . . . . . . . . . . . 9
4.2.5. Purpose . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.7. Assignment . . . . . . . . . . . . . . . . . . . . . 10
4.2.8. Security and Privacy . . . . . . . . . . . . . . . . 11
4.2.9. Interoperability . . . . . . . . . . . . . . . . . . 11
4.2.10. Resolution . . . . . . . . . . . . . . . . . . . . . 11
4.3. "Emergency" Area . . . . . . . . . . . . . . . . . . . . 11
4.4. Emergency Call Additional Data Registry . . . . . . . . . 12
4.5. "urn:emergency" registry . . . . . . . . . . . . . . . . 12
4.5.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.2. Information Needed to Create a New Value . . . . . . 12
4.5.3. Registration policy . . . . . . . . . . . . . . . . . 12
4.5.4. Content . . . . . . . . . . . . . . . . . . . . . . . 13
4.5.5. Subregistries for top level classes of
urn:emergency . . . . . . . . . . . . . . . . . . . . 13
4.5.5.1. "urn:emergency:service" Subregistry . . . . . . . 13
4.5.5.1.1. Name . . . . . . . . . . . . . . . . . . . . 14
4.5.5.1.2. Information Needed to Create a New Value . . 14
4.5.5.1.3. Registration policy . . . . . . . . . . . . . 14
4.5.5.1.4. Content . . . . . . . . . . . . . . . . . . . 14
4.5.5.2. "urn:emergency:service:sos" Subregistry . . . . . 14
4.5.5.2.1. Name . . . . . . . . . . . . . . . . . . . . 15
4.5.5.2.2. Information Needed to Create a New Value . . 15
4.5.5.2.3. Registration policy . . . . . . . . . . . . . 15
4.5.5.2.4. Content . . . . . . . . . . . . . . . . . . . 15
4.5.5.3. "urn:emergency:service:test" Registry . . . . . . 15
4.5.5.3.1. Name . . . . . . . . . . . . . . . . . . . . 16
4.5.5.3.2. Information Needed to Create a New Value . . 16
Rosen & Abley Expires 27 January 2023 [Page 2]
Internet-Draft Emergency Registries July 2022
4.5.5.3.3. Registration policy . . . . . . . . . . . . . 16
4.5.5.3.4. Content . . . . . . . . . . . . . . . . . . . 16
4.5.5.4. "urn:emergency:service:responder" Registry . . . 16
4.5.5.4.1. Name . . . . . . . . . . . . . . . . . . . . 17
4.5.5.4.2. Information Needed to Create a New Value . . 17
4.5.5.4.3. Registration policy . . . . . . . . . . . . . 17
4.5.5.4.4. Content . . . . . . . . . . . . . . . . . . . 17
4.5.5.5. "urn:emergency:service:responder.police"
Subregistry . . . . . . . . . . . . . . . . . . . . 17
4.5.5.5.1. Name . . . . . . . . . . . . . . . . . . . . 18
4.5.5.5.2. Information Needed to Create a New Value . . 18
4.5.5.5.3. Registration policy . . . . . . . . . . . . . 18
4.5.5.5.4. Content . . . . . . . . . . . . . . . . . . . 18
4.5.5.6. "police.federal" Subregistry . . . . . . . . . . 18
4.5.5.6.1. Name . . . . . . . . . . . . . . . . . . . . 19
4.5.5.6.2. Information Needed to Create a New Value . . 19
4.5.5.6.3. Registration policy . . . . . . . . . . . . . 19
4.5.5.6.4. Content . . . . . . . . . . . . . . . . . . . 19
4.5.5.7. "urn:emergency:service:responder.fire"
Subregistry . . . . . . . . . . . . . . . . . . . . 19
4.5.5.7.1. Name . . . . . . . . . . . . . . . . . . . . 19
4.5.5.7.2. Information Needed to Create a New Value . . 19
4.5.5.7.3. Registration policy . . . . . . . . . . . . . 20
4.5.5.7.4. Content . . . . . . . . . . . . . . . . . . . 20
4.5.5.8. "urn:emergency:service:responder.ems"
Subregistry . . . . . . . . . . . . . . . . . . . . 20
4.5.5.8.1. Name . . . . . . . . . . . . . . . . . . . . 20
4.5.5.8.2. Information Needed to Create a New Value . . 20
4.5.5.8.3. Registration policy . . . . . . . . . . . . . 20
4.5.5.8.4. Content . . . . . . . . . . . . . . . . . . . 21
4.5.5.9. "urn:emergency:service:serviceAgencyLocator"
Subregistry . . . . . . . . . . . . . . . . . . . . 21
4.5.5.9.1. Name . . . . . . . . . . . . . . . . . . . . 21
4.5.5.9.2. Information Needed to Create a New Value . . 21
4.5.5.9.3. Registration policy . . . . . . . . . . . . . 21
4.5.5.9.4. Content . . . . . . . . . . . . . . . . . . . 21
4.5.5.10. "urn:emergency:uid" Registry . . . . . . . . . . 22
4.5.5.10.1. Name . . . . . . . . . . . . . . . . . . . . 22
4.5.5.10.2. Information Needed to Create a New Value . . 22
4.5.5.10.3. Registration policy . . . . . . . . . . . . 22
4.5.5.10.4. Content . . . . . . . . . . . . . . . . . . 22
4.5.5.11. "urn:emergency:media-feature" Registry . . . . . 23
4.5.5.11.1. Name . . . . . . . . . . . . . . . . . . . . 23
4.5.5.11.2. Information Needed to Create a New Value . . 23
4.5.5.11.3. Registration policy . . . . . . . . . . . . 23
4.5.5.11.4. Content . . . . . . . . . . . . . . . . . . 23
4.6. Internal Services Registries . . . . . . . . . . . . . . 23
4.6.1. "serviceNames" Registry . . . . . . . . . . . . . . . 24
Rosen & Abley Expires 27 January 2023 [Page 3]
Internet-Draft Emergency Registries July 2022
4.6.1.1. Name . . . . . . . . . . . . . . . . . . . . . . 24
4.6.1.2. Information Needed to Create a New Value . . . . 24
4.6.1.3. Registration policy . . . . . . . . . . . . . . . 24
4.6.1.4. Content . . . . . . . . . . . . . . . . . . . . . 24
4.6.2. "serviceState" Registry . . . . . . . . . . . . . . . 24
4.6.2.1. Name . . . . . . . . . . . . . . . . . . . . . . 24
4.6.2.2. Information Needed to Create a New Value . . . . 24
4.6.2.3. Registration policy . . . . . . . . . . . . . . . 25
4.6.2.4. Content . . . . . . . . . . . . . . . . . . . . . 25
4.6.3. "elementState" Registry . . . . . . . . . . . . . . . 25
4.6.3.1. Name . . . . . . . . . . . . . . . . . . . . . . 25
4.6.3.2. Information Needed to Create a New Value . . . . 25
4.6.3.3. Registration policy . . . . . . . . . . . . . . . 25
4.6.3.4. Content . . . . . . . . . . . . . . . . . . . . . 25
4.6.4. "SIPHeaderIsOperatorConditions" Registry . . . . . . 26
4.6.4.1. Name . . . . . . . . . . . . . . . . . . . . . . 26
4.6.4.2. Information Needed to Create a New Value . . . . 26
4.6.4.3. Registration policy . . . . . . . . . . . . . . . 26
4.6.4.4. Content . . . . . . . . . . . . . . . . . . . . . 26
4.6.5. "queueState" Registry . . . . . . . . . . . . . . . . 27
4.6.5.1. Name . . . . . . . . . . . . . . . . . . . . . . 27
4.6.5.2. Information Needed to Create a New Value . . . . 27
4.6.5.3. Registration policy . . . . . . . . . . . . . . . 27
4.6.5.4. Content . . . . . . . . . . . . . . . . . . . . . 27
4.6.6. "securityPosture" Registry . . . . . . . . . . . . . 27
4.6.6.1. Name . . . . . . . . . . . . . . . . . . . . . . 27
4.6.6.2. Information Needed to Create a New Value . . . . 28
4.6.6.3. Registration policy . . . . . . . . . . . . . . . 28
4.6.6.4. Content . . . . . . . . . . . . . . . . . . . . . 28
4.6.7. "ESRP Notify Event Code" Registry . . . . . . . . . . 28
4.6.7.1. Name . . . . . . . . . . . . . . . . . . . . . . 28
4.6.7.2. Information Needed to Create a New Value . . . . 28
4.6.7.3. Registration policy . . . . . . . . . . . . . . . 28
4.6.7.4. Content . . . . . . . . . . . . . . . . . . . . . 29
4.6.8. "Route Cause" Registry . . . . . . . . . . . . . . . 29
4.6.8.1. Name . . . . . . . . . . . . . . . . . . . . . . 29
4.6.8.2. Information Needed to Create a New Value . . . . 29
4.6.8.3. Registration policy . . . . . . . . . . . . . . . 29
4.6.8.4. Content . . . . . . . . . . . . . . . . . . . . . 29
4.6.9. "LogEvent" Registry . . . . . . . . . . . . . . . . . 30
4.6.9.1. Name . . . . . . . . . . . . . . . . . . . . . . 30
4.6.9.2. Information Needed to Create a New Value . . . . 30
4.6.9.3. Registration policy . . . . . . . . . . . . . . . 30
4.6.9.4. Content . . . . . . . . . . . . . . . . . . . . . 30
4.6.10. "LogEvent Protocol" Registry . . . . . . . . . . . . 30
4.6.10.1. Name . . . . . . . . . . . . . . . . . . . . . . 30
4.6.10.2. Information Needed to Create a New Value . . . . 31
4.6.10.3. Registration policy . . . . . . . . . . . . . . 31
Rosen & Abley Expires 27 January 2023 [Page 4]
Internet-Draft Emergency Registries July 2022
4.6.10.4. Content . . . . . . . . . . . . . . . . . . . . 31
4.6.11. "LogEvent CallTypes" Registry . . . . . . . . . . . . 31
4.6.11.1. Name . . . . . . . . . . . . . . . . . . . . . . 31
4.6.11.2. Information Needed to Create a New Value . . . . 31
4.6.11.3. Registration policy . . . . . . . . . . . . . . 31
4.6.11.4. Content . . . . . . . . . . . . . . . . . . . . 31
4.6.12. "Call States" Registry . . . . . . . . . . . . . . . 32
4.6.12.1. Name . . . . . . . . . . . . . . . . . . . . . . 32
4.6.12.2. Information Needed to Create a New Value . . . . 32
4.6.12.3. Registration policy . . . . . . . . . . . . . . 32
4.6.12.4. Content . . . . . . . . . . . . . . . . . . . . 32
4.6.13. "LogEvent Announcement Types" Registry . . . . . . . 32
4.6.13.1. Name . . . . . . . . . . . . . . . . . . . . . . 33
4.6.13.2. Information Needed to Create a New Value . . . . 33
4.6.13.3. Registration policy . . . . . . . . . . . . . . 33
4.6.13.4. Content . . . . . . . . . . . . . . . . . . . . 33
4.6.14. "non-RTP Media Types" Registry . . . . . . . . . . . 33
4.6.14.1. Name . . . . . . . . . . . . . . . . . . . . . . 33
4.6.14.2. Information Needed to Create a New Value . . . . 33
4.6.14.3. Registration policy . . . . . . . . . . . . . . 33
4.6.14.4. Content . . . . . . . . . . . . . . . . . . . . 34
4.6.15. "Agency Roles" Registry . . . . . . . . . . . . . . . 34
4.6.15.1. Name . . . . . . . . . . . . . . . . . . . . . . 34
4.6.15.2. Information Needed to Create a New Value . . . . 34
4.6.15.3. Registration policy . . . . . . . . . . . . . . 34
4.6.15.4. Content . . . . . . . . . . . . . . . . . . . . 34
4.6.16. "Agent Roles" Registry . . . . . . . . . . . . . . . 34
4.6.16.1. Name . . . . . . . . . . . . . . . . . . . . . . 35
4.6.16.2. Information Needed to Create a New Value . . . . 35
4.6.16.3. Registration policy . . . . . . . . . . . . . . 35
4.6.16.4. Content . . . . . . . . . . . . . . . . . . . . 35
4.6.17. "Status Codes" Registry . . . . . . . . . . . . . . . 35
4.6.17.1. Name . . . . . . . . . . . . . . . . . . . . . . 35
4.6.17.2. Information Needed to Create a New Value . . . . 35
4.6.17.3. Registration policy . . . . . . . . . . . . . . 35
4.6.17.4. Content . . . . . . . . . . . . . . . . . . . . 36
4.6.18. "Interface Names" Registry . . . . . . . . . . . . . 36
4.6.18.1. Name . . . . . . . . . . . . . . . . . . . . . . 36
4.6.18.2. Information Needed to Create a New Value . . . . 36
4.6.18.3. Registration policy . . . . . . . . . . . . . . 36
4.6.18.4. Content . . . . . . . . . . . . . . . . . . . . 36
4.6.19. "Match Type" Registry . . . . . . . . . . . . . . . . 36
4.6.19.1. Name . . . . . . . . . . . . . . . . . . . . . . 37
4.6.19.2. Information Needed to Create a New Value . . . . 37
4.6.19.3. Registration policy . . . . . . . . . . . . . . 37
4.6.19.4. Content . . . . . . . . . . . . . . . . . . . . 37
4.6.20. "GIS Layers" Registry . . . . . . . . . . . . . . . . 37
4.6.20.1. Name . . . . . . . . . . . . . . . . . . . . . . 37
Rosen & Abley Expires 27 January 2023 [Page 5]
Internet-Draft Emergency Registries July 2022
4.6.20.2. Information Needed to Create a New Value . . . . 37
4.6.20.3. Registration policy . . . . . . . . . . . . . . 37
4.6.20.4. Content . . . . . . . . . . . . . . . . . . . . 38
4.6.21. "Policy Type" Registry . . . . . . . . . . . . . . . 38
4.6.21.1. Name . . . . . . . . . . . . . . . . . . . . . . 38
4.6.21.2. Information Needed to Create a New Value . . . . 38
4.6.21.3. Registration policy . . . . . . . . . . . . . . 38
4.6.21.4. Content . . . . . . . . . . . . . . . . . . . . 38
4.6.22. "Discrepancy Report Status Token" Registry . . . . . 39
4.6.22.1. Name . . . . . . . . . . . . . . . . . . . . . . 39
4.6.22.2. Information Needed to Create a New Value . . . . 39
4.6.22.3. Registration policy . . . . . . . . . . . . . . 39
4.6.22.4. Content . . . . . . . . . . . . . . . . . . . . 39
4.6.23. "Event Package" Registry . . . . . . . . . . . . . . 40
4.6.23.1. Name . . . . . . . . . . . . . . . . . . . . . . 40
4.6.23.2. Information Needed to Create a New Value . . . . 40
4.6.23.3. Registration policy . . . . . . . . . . . . . . 40
4.6.23.4. Content . . . . . . . . . . . . . . . . . . . . 40
4.6.24. "LoggingServiceMediaErrorReasonCodes" Registry . . . 40
4.6.24.1. Name . . . . . . . . . . . . . . . . . . . . . . 40
4.6.24.2. Information Needed to Create a New Value . . . . 40
4.6.24.3. Registration policy . . . . . . . . . . . . . . 41
4.6.24.4. Content . . . . . . . . . . . . . . . . . . . . 41
4.6.24.5. Initial Values . . . . . . . . . . . . . . . . . 41
4.7. EIDO Registries . . . . . . . . . . . . . . . . . . . . . 41
4.7.1. "EIDO-AgencyRole" Registry . . . . . . . . . . . . . 41
4.7.1.1. Name . . . . . . . . . . . . . . . . . . . . . . 41
4.7.1.2. Information Needed to Create a New Value . . . . 42
4.7.1.3. Registration policy . . . . . . . . . . . . . . . 42
4.7.1.4. Content . . . . . . . . . . . . . . . . . . . . . 42
4.7.2. "EIDO-IncidentType-Common" Registry . . . . . . . . . 42
4.7.2.1. Name . . . . . . . . . . . . . . . . . . . . . . 42
4.7.2.2. Information Needed to Create a New Value . . . . 42
4.7.2.3. Registration policy . . . . . . . . . . . . . . . 42
4.7.2.4. Content . . . . . . . . . . . . . . . . . . . . . 43
4.7.3. "EIDO-IncidentStatus-Common" Registry . . . . . . . . 43
4.7.3.1. Name . . . . . . . . . . . . . . . . . . . . . . 43
4.7.3.2. Information Needed to Create a New Value . . . . 43
4.7.3.3. Registration policy . . . . . . . . . . . . . . . 43
4.7.3.4. Content . . . . . . . . . . . . . . . . . . . . . 43
4.7.4. "EIDO-ReportNumberType" Registry . . . . . . . . . . 43
4.7.4.1. Name . . . . . . . . . . . . . . . . . . . . . . 44
4.7.4.2. Information Needed to Create a New Value . . . . 44
4.7.4.3. Registration policy . . . . . . . . . . . . . . . 44
4.7.4.4. Content . . . . . . . . . . . . . . . . . . . . . 44
4.7.5. "EIDO-CommonDispositionCode" Registry . . . . . . . . 44
4.7.5.1. Name . . . . . . . . . . . . . . . . . . . . . . 44
4.7.5.2. Information Needed to Create a New Value . . . . 44
Rosen & Abley Expires 27 January 2023 [Page 6]
Internet-Draft Emergency Registries July 2022
4.7.5.3. Registration policy . . . . . . . . . . . . . . . 45
4.7.5.4. Content . . . . . . . . . . . . . . . . . . . . . 45
4.7.6. "EIDO-PersonRole" Registry . . . . . . . . . . . . . 45
4.7.6.1. Name . . . . . . . . . . . . . . . . . . . . . . 45
4.7.6.2. Information Needed to Create a New Value . . . . 45
4.7.6.3. Registration policy . . . . . . . . . . . . . . . 45
4.7.6.4. Content . . . . . . . . . . . . . . . . . . . . . 45
4.7.7. "EIDO-VehicleRelationshipType" Registry . . . . . . . 46
4.7.7.1. Name . . . . . . . . . . . . . . . . . . . . . . 46
4.7.7.2. Information Needed to Create a New Value . . . . 46
4.7.7.3. Registration policy . . . . . . . . . . . . . . . 46
4.7.7.4. Content . . . . . . . . . . . . . . . . . . . . . 46
4.7.8. "EIDO-LocationType" Registry . . . . . . . . . . . . 46
4.7.8.1. Name . . . . . . . . . . . . . . . . . . . . . . 46
4.7.8.2. Information Needed to Create a New Value . . . . 46
4.7.8.3. Registration policy . . . . . . . . . . . . . . . 47
4.7.8.4. Content . . . . . . . . . . . . . . . . . . . . . 47
4.7.9. "EIDO-PrimaryUnitStatus-Common" Registry . . . . . . 47
4.7.9.1. Name . . . . . . . . . . . . . . . . . . . . . . 47
4.7.9.2. Information Needed to Create a New Value . . . . 47
4.7.9.3. Registration policy . . . . . . . . . . . . . . . 47
4.7.9.4. Content . . . . . . . . . . . . . . . . . . . . . 47
4.7.10. "EIDO-SecondaryUnitStatus-Common" Registry . . . . . 48
4.7.10.1. Name . . . . . . . . . . . . . . . . . . . . . . 48
4.7.10.2. Information Needed to Create a New Value . . . . 48
4.7.10.3. Registration policy . . . . . . . . . . . . . . 48
4.7.10.4. Content . . . . . . . . . . . . . . . . . . . . 48
4.7.11. "EIDO-EmergencyResourceType-Common" Registry . . . . 48
4.7.11.1. Name . . . . . . . . . . . . . . . . . . . . . . 48
4.7.11.2. Information Needed to Create a New Value . . . . 48
4.7.11.3. Registration policy . . . . . . . . . . . . . . 49
4.7.11.4. Content . . . . . . . . . . . . . . . . . . . . 49
4.7.12. "EIDO-ResourceAttribute" Registry . . . . . . . . . . 49
4.7.12.1. Name . . . . . . . . . . . . . . . . . . . . . . 49
4.7.12.2. Information Needed to Create a New Value . . . . 49
4.7.12.3. Registration policy . . . . . . . . . . . . . . 49
4.7.12.4. Content . . . . . . . . . . . . . . . . . . . . 49
4.7.13. "eidoExtensionId" Registry . . . . . . . . . . . . . 50
4.7.13.1. Name . . . . . . . . . . . . . . . . . . . . . . 50
4.7.13.2. Information Needed to Create a New Value . . . . 50
4.7.13.3. Registration policy . . . . . . . . . . . . . . 50
4.7.13.4. Content . . . . . . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 50
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1. Normative References . . . . . . . . . . . . . . . . . . 51
6.2. Informative References . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
Rosen & Abley Expires 27 January 2023 [Page 7]
Internet-Draft Emergency Registries July 2022
1. Introduction
[RFC6443] establishes a framework for carrying emergency calls over
the Internet using the SIP ( [RFC3261] ) protocol. Various regional
organizations are developing standards for how calls conforming to
this framework are handled within the Emergency Services IP Networks
(ESInets) established by local, regional or national authorities to
handle such calls and deliver them to the appropriate Public Safety
Answering Point (PSAP). Many of these standards have needed
registries of values used in the protocols and services the services
define. Prior to this document, such registries were managed by the
regional SDOs themselves. There is a desire among many of the
regional emergency services SDOs to have a single world-wide standard
for handling emergency calls and as part of that effort, a single set
of registries managed by a neutral party. This document requests
IANA to establish a new registry area called "Emergency" and to
create a set of registries within that area. This document does not
describe initial contents of the registries, with some exceptions.
The registries will be populated by requests from the regional SDOs,
including The NENA i3 Standard [NENAi3].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] .
2. Acknowledgements
Thanks to the workgroups and committees at NENA: The 9-1-1
Association, especially the Core Services and Agency Systems
committees, as well as ETSI and EENA for their contributions to unify
international emergency calling standards.
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In this document, "NG9-1-1" is use to describe next-generation
emergency calling services generally and is meant to include NG112
initiatives ongoing in Europe ([NG112]).
Rosen & Abley Expires 27 January 2023 [Page 8]
Internet-Draft Emergency Registries July 2022
4. IANA Considerations
This document creates a number of registries. The initial values for
these registries are not defined and will be submitted by regional
and international SDOs such as NENA and ETSI.
4.1. SIP Reason Protocols
IANA is requested to add the value "emergency" to the SIP Protocols
Registry ([SIPProto]).
4.1.1. Protocol Value
"emergency"
4.1.2. Protocol Cause
"Emergency call processing"
4.1.3. Reference
This document, and ([NENAi3]).
4.2. "emergency" URN namespace
IANA is requested to register a new URN namespace for "emergency".
4.2.1. Namespace Identifier
emergency
4.2.2. Version
1
4.2.3. Date
RFC Editor: please insert the date this RFC was published
4.2.4. Registrant
IETF and the ecrit Working Group. Should the working group cease to
exist, discussion should be directed to the Applications and Real-
Time Area or general IETF discussion forums, or the IESG.
Rosen & Abley Expires 27 January 2023 [Page 9]
Internet-Draft Emergency Registries July 2022
4.2.5. Purpose
This namespace is used for unique identifiers for use in emergency
services, including emergency calls. Most uses for these identifiers
will be within private "Emergency Services IP Networks" (ESInets),
some use in the public Internet is expected. These identifiers will
be used in several countries, and hopefully, eventually, worldwide
for handling of emergency calls and incidents. Prior to this
document, North American emergency services used the "nena" nid,
defined in [RFC6061]. Most identifiers in urn:nena will be replaced
by identifiers in urn:emergency in pursuit of a single worldwide
standard set for emergency services which are not controlled by a
single public safety organization like NENA. Identifiers with this
nid do not require resolution. Identifiers in this nid will
primarily specified in public safety standards SDOs, but some IETF
standards may use or define them.
4.2.6. Syntax
The basic syntax for identifiers in the emergency nid is:
urn:emergency:<top level class>:<:extended>
where
<top level class> is a member of the urn:emergency namespace
registry, see Section 4.5
<extended> is a class-specific value defined by the document
describing the registry entry. In many cases, the extension includes
sub classes. For example:
urn:emergency:service:responder:police.local
There are no special encoding rules for identifiers in urn:emergency.
URN equivalence is non-case sensitive. Hyphens are not expected in
these identifiers, but if used, they are significant in comparisons.
Quotes are not allowed in this nid. There are no special
considerations for conforming to URN syntax. Percent encoding is
permitted. There are no uses for q-components or f-components in
this namespace.
4.2.7. Assignment
Assignment of top level classes is by standards documents, both
standards-track RFCs and standards documents in other SDOs. See
Section 4.5. Assignments within top level classes are defined in the
document that defines the class. Such documents MUST specify how
uniqueness within the class is achieved.
Rosen & Abley Expires 27 January 2023 [Page 10]
Internet-Draft Emergency Registries July 2022
4.2.8. Security and Privacy
Each top level class, in its defining document, MUST describe the
security and privacy considerations of that class. In general, there
are no special security considerations for these identifiers.
Several top level classes are defined in this document. In some
circumstances, these identifiers may indicate what kind of agency is
involved with a public safety incident, and some may identify a
specific agency. Encryption of the communications that contain the
identifier in classes defined in this document is REQUIRED and MUST
be TLS or an equally secure protocol.
4.2.9. Interoperability
Many of the identifiers in urn:emergency are similar in construction
and use as identifiers originally defined in urn:nena. Backwards
compatibility with those identifiers MUST be specified in the
documents that use them. NENA STA-010.3-2021 is the primary document
that has this backwards compatibility requirement, as it defined most
of the identifiers in urn:nena. There are no other interoperability
issues.
4.2.10. Resolution
No resolution of these identifiers is defined.
4.3. "Emergency" Area
IANA is requested to establish the registries within this section
under the "Emergency" area. These registries contain enumerated
values used for various aspects of emergency calling and call
handling. New registries or subregistrues in the "Emergency" area
require a standards document, which MAY be a standards track RFC, but
also MAY be a defined in a document from a recognized standards
organization that promulgates emergency services standards. Where a
new registry or subregistry is defined in an external standards
organization, an expert SHALL review the document to ascertain that
it is relevant to the "Emergency" area, that the organization
defining the registry is a recognized standards organization, that
the document clearly articulates the management method for the
regisry, which MUST be substantially similar to one or more of the
management methods in [RFC8216], and if expert review is specified,
that experts acceptable to the IESG for the registry are available.
The expert(s) reviewing the new registry shall also request IANA to
review the relevant documents using the same criteria as it would for
a standards track RFC. The expert SHALL NOT approve the new registry
unless IANA is satisfied it can maintain the registry with the same
or similar level of effort it expends for similar registries created
Rosen & Abley Expires 27 January 2023 [Page 11]
Internet-Draft Emergency Registries July 2022
by RFCs. If the management of the registry is specified as First
Come First Served, which, per RFC8126 does not require an expert, an
expert acceptable to the IESG must be available to answer questions
about registrations and advise IANA of any issues in registrations in
that registry.
These registries are required to implement the NENA i3 Standard for
Next-Generation 9-1-1 [NENAi3] as well as the NENA Standard for
Emergency Incident Data Object [EIDO]. These standards, unless
otherwise specified, will initially populate the registries created
by this document. Some registries previously existed in the NENA
Registry System [NRS], but the intent of international SDOs is to
maintain next-generation emergency calling registries under IANA in
the future. [NRS] will be maintained only for backwards
compatibility, and for registries required only for North America.
4.4. Emergency Call Additional Data Registry
IANA is requested to move the Emergency Call Additional Data registry
and its sub-registries to the Emergency Area.
4.5. "urn:emergency" registry
IANA is requested to create a registry for the emergency nid top
level classes in the Emergency Area.
4.5.1. Name
urn:emergency
4.5.2. Information Needed to Create a New Value
Name of the top level class, a short description and a reference to a
document that defines it.
4.5.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
specification MUST be from the IETF or a recognized standards
organization that creates standards for emergency services. The
expert must confirm the requested class is appropriate for emergency
services, if the registering organization is not the IETF, that it is
an appropriate organization to define the class, that the purpose
adequately describes the new class and the reference leads to a
document that clearly describes the use of the class. Also see
Section 4.5.5.
Rosen & Abley Expires 27 January 2023 [Page 12]
Internet-Draft Emergency Registries July 2022
4.5.4. Content
This registry contains:
* The ASCII "Name" of the "top level" class (a short string)
* The ASCII "Purpose" of the label (explanatory text)
* A "Reference" (URI) to the standard that defines the label
4.5.5. Subregistries for top level classes of urn:emergency
In most cases, top level classes of urn:emergency will define
subregistries. Several levels of subregistries may be needed. The
document that defines the class MUST define the subregistry if
needed. IETF and emergency service standards organizations MAY
define subregistries of urn:nena. Instructions to IANA for the
subregistry MUST conform to [RFC8126]. The expert reviewer for the
top level class works with IANA to assure that they do if the
standards organization creating the subregistry is not the IETF.
4.5.5.1. "urn:emergency:service" Subregistry
IANA is requested to create a subregistry for "urn:emergency:service"
under "urn:emergency".
When calls are routed within an Emergency Services IP Network
(ESInet), the routing element queries a LoST [RFC5222] server for the
(nominal) route. It does so with a service URN. Esternal routing is
accomplished with "urn:service:sos", as defined by [RFC5031]. Within
an ESInet, values under this registry are used.
Service URNs as defined here begin with "urn:emergency:service". The
sub-namespace defined by this registry MAY be further subdivided
(potentially several times), by sub-registries under this sub-
registry. The separator between urn:emergency:service and the entry
in the subregistry is a colon (":"). A new entry starting with
"urn:emergency:service" SHOULD denote a new type of route, which MUST
be distinguished by the LoST server from other uses. For example,
emergency calls being routed within the ESInet use
"urn:emergency:service:sos" (or a subspace of it). Calls routed by a
PSAP to a responder use "urn:emergency:service:responder" (the type
of responder is also included, e.g.,
"urn:emergency:service:responder.police"). A client specifies the
URN in a LoST query, and the LoST Server uses it to choose a
(nominal) route.
Rosen & Abley Expires 27 January 2023 [Page 13]
Internet-Draft Emergency Registries July 2022
4.5.5.1.1. Name
urn:emergency:service
4.5.5.1.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that defines it.
4.5.5.1.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
specification MUST be from the IETF or a recognized standards
organization that creates standards for emergency services. The
expert must confirm the requested entry is appropriate for emergency
services, if the registering organization is not the IETF, that it is
an appropriate organization to define the entry, that the purpose
adequately describes the new entry and the reference leads to a
document that clearly describes the use of the entry. Also see
Section 4.5.5.
4.5.5.1.4. Content
This registry contains:
* The ASCII "Name" of the value (a short string)
* The ASCII "Purpose" of the value (explanatory text)
* A "Reference" (URI) to the document that defines the value
4.5.5.2. "urn:emergency:service:sos" Subregistry
IANA is requested to creates a subregistry for
"urn:emergency:service:sos" under "urn:emergency:service".
Routing of emergency calls within the ESInet is a primary function of
systems that process such calls. When routing entities must route
calls within the ESInet, they query the LoST Server for the route.
Routing for emergency calls may involve multiple levels of routing
entities. Each level may need a different URN to be distinguishable.
Routing of emergency calls, including instant messages and non-
interactive calls within an ESInet, is accomplished with a URN
beginning with "urn:emergency:service:sos". The
"urn:emergency:service:sos" registry contains values appropriate for
the various levels of routing within the ESInet. The separator
between urn:emergency:service:sos and an entry in the subregistry is
a colon (":").
Rosen & Abley Expires 27 January 2023 [Page 14]
Internet-Draft Emergency Registries July 2022
4.5.5.2.1. Name
urn:emergency:service:sos
4.5.5.2.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that defines it.
4.5.5.2.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
specification MUST be from the IETF or a recognized standards
organization that creates standards for emergency services. The
expert must confirm the requested class is appropriate for emergency
services, if the registering organization is not the IETF, that it is
an appropriate organization to define the class, that the purpose
adequately describes the new class and the reference leads to a
document that clearly describes the use of the class. Also see
Section 4.5.5.
4.5.5.2.4. Content
This registry contains:
* The ASCII "Name" of the service value (a short string)
* The ASCII "Purpose" of the value (explanatory text)
* A "Reference" (URI) to the document that defines the value
4.5.5.3. "urn:emergency:service:test" Registry
IANA is requested to creates a subregistry for
"urn:emergency:service:test" under "urn:emergency:service".
Test calls are directed to "urn:service:test.sos". To route such
test calls where the routing infrastructure uses multiple levels of
routing, and thus uses URNs in the "urn:emergency:service:sos"
registry, service URNs are needed for test calls with similar levels.
IANA is requested to create an entry in the "urn:emergency:service"
registry with the name "test" and with the purpose noted as "routing
test calls within the ESInet toward a primary PSAP". The reference
will be to the registry created by this section,
"urn:emergency:service:test". The separator between the "test" label
and the service ("urn:emergency:service:test" registry entry) is a
period ".". The "urn:emergency:service:test" registry contains label
values corresponding to the levels in the "urn:emergency:service:sos"
Rosen & Abley Expires 27 January 2023 [Page 15]
Internet-Draft Emergency Registries July 2022
registry. These registries are normally kept in sync, an entry added
to "urn:emergency:service:sos" should also add a corresponding entry
to urn:emergency:service:test.
4.5.5.3.1. Name
urn:emergency:service:test
4.5.5.3.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that defines it.
4.5.5.3.3. Registration policy
Specification Required [RFC8126], which requires expert review.
Normally, entries in urn:emergency:service:test mirror those in
urn:emergency:service:sos. If there are any discrepancies the expert
shall determine if the requested entry meets the use defined above
and the specification document adequately describes how the entry is
used.
4.5.5.3.4. Content
The content of this registry should mirror the content of
urn:service:test:sos except with the "test" label as described above.
4.5.5.4. "urn:emergency:service:responder" Registry
IANA is requested to create the "urn:emergency:service:responder"
subregistry under "urn:emergency:service"
Once a PSAP gets a call, they may have to transfer the call to a
secondary PSAP. The secondary PSAP is chosen based on the type of
responder, and the location of the caller. Routing of emergency
calls from a PSAP towards a responder is accomplished with a URN
beginning with "urn:emergency:service:responder". IANA is requested
to create an entry in the "urn:emergency:service" registry with the
name "responder" and with the purpose noted as "routing emergency
calls within the ESInet towards a responder". The reference will be
to the registry created by this section,
"urn:emergency:service:responder".
The "urn:emergency:service:responder" registry contains label values
appropriate for the types of responders within the ESInet. The
separator between the "responder" label and the type of responder
("urn:emergency:service:responder" registry value) is a period ".".
This registry is also used in other contexts where an agency type is
Rosen & Abley Expires 27 January 2023 [Page 16]
Internet-Draft Emergency Registries July 2022
useful. For those purposes, a 'psap' entry is provided.
"urn:emergency:service:responder.psap" must not be used to route
emergency calls. It is not equivalent to, or a substitute for
"urn:service:sos" or "urn:emergency:service:sos".
Some of the entries in this registry will require further
subdivision. Subregistries for such divisions are REQUIRED.
4.5.5.4.1. Name
urn:emergency:service:responder
4.5.5.4.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that defines it.
4.5.5.4.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a kind of responder,
considered broadly. For example, a tow truck operator may be
considered a responder.
4.5.5.4.4. Content
This registry contains:
* The ASCII "Name" of the responder (a short string)
* The ASCII "Purpose" of the responder (explanatory text)
* A "Reference" (URI) to a document that defines the label
4.5.5.5. "urn:emergency:service:responder.police" Subregistry
There are many different kinds of law enforcement agencies that have
distinct differences in jurisdiction and formation (for example,
police department organized under a municipal government as opposed
to the sheriff's office organized under an elected sheriff). This
subregistry delineates different types of police agenices under the
urn:emergency:service:responder:police registry. The separator
between urn:emergency:responder.police and the entry in this
subregistry is a period (".").
Rosen & Abley Expires 27 January 2023 [Page 17]
Internet-Draft Emergency Registries July 2022
4.5.5.5.1. Name
urn:emergency:service:responder.police
4.5.5.5.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that defines it.
4.5.5.5.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a kind of police
department, considered broadly. The names used for various kinds of
police departments varies from country to country. The expert is
requested to try to minimize the number of entries in the registry,
but is not expected to have to learn the details of how police forces
are organized in any country. An English name is preferred, to match
the existing entries.
4.5.5.5.4. Content
This registry contains:
* The UTF-8 "Name" of the agency type
* The ASCII "Description" of the agency type
* A "Reference" with a URI either to the document that defines the
entry.
Note that the Name is defined as UTF-8, to permit names that have no
English equivalent
4.5.5.6. "police.federal" Subregistry
There are several federal police agencies. This registry is a
subregistry of "urn:emergency:service:responder.police." and lists
each police agency operating at the federal/national level. The
"federal.police" registry contains label values appropriate for the
types of national police responders within the ESInet. This is
distinct from the parent subregistry, "police.federal", is the
police.federal subregistry includes the names for specific federal
agencies, as opposed to the "responder.police" subregistry which
indicated the agency TYPE (police). The separator between the
"police.federal" label and the type of responder
("urn:emergency:service:responder.police.federal" registry value) is
a period ".".
Rosen & Abley Expires 27 January 2023 [Page 18]
Internet-Draft Emergency Registries July 2022
4.5.5.6.1. Name
urn:emergency:service:responder.police.federal
4.5.5.6.2. Information Needed to Create a New Value
Short and long forms of the entry and a reference to a document that
defines it or a person that requested the entry.
4.5.5.6.3. Registration policy
Expert Review. No standards document required. The expert should
confirm that entry represents a kind of federal police department,
considered broadly. As this is a specific agency, entries for
different countries may be different.
4.5.5.6.4. Content
This registry contains:
* The UTF-8 short "Name" of the agency, usually an abbreviation
(e.g., "FBI")
* The UTF-8 "Full Name" of the agency (e.g., "Federal Bureau of
Investigation")
* A "Reference" with a URI either to the document requested the
registry entry or contact contact information for the individual
who contributed the value.
Note that the Name is defined as UTF-8, and locally significant names
are expressly permitted.
4.5.5.7. "urn:emergency:service:responder.fire" Subregistry
This registry has similar purposes as the "responder.police"
subregistry, except for types of fire response agencies (for example,
"forest" or "private").
4.5.5.7.1. Name
urn:emergency:service:responder.fire
4.5.5.7.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that specifies the entry.
Rosen & Abley Expires 27 January 2023 [Page 19]
Internet-Draft Emergency Registries July 2022
4.5.5.7.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a kind of fire
department, considered broadly. The names used for various kinds of
fire departments varies from country to country. The expert is
requested to try to minimize the number of entries in the registry,
but is not expected to have to learn the details of how fire
departments are organized in any country. An English name is
preferred, to match the existing entries.
4.5.5.7.4. Content
This registry contains:
* The UTF-8 "Name" of the agency type
* The ASCII "Description" of the agency type
* A "Reference" with a URI to the document that specifies the entry.
Note that the Name is defined as UTF-8, to permit names that have no
English equivalent
4.5.5.8. "urn:emergency:service:responder.ems" Subregistry
This registry has similar purposes as the "responder.police"
subregistry, except for types of Emergency Medical Service response
agencies (for example, "Local" or "countyParish").
4.5.5.8.1. Name
urn:emergency:service:responder.ems
4.5.5.8.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that specifies the entry.
4.5.5.8.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a kind of emergency
medical service, considered broadly. The names used for various
kinds of emergency medical services varies from country to country.
The expert is requested to try to minimize the number of entries in
the registry, but is not expected to have to learn the details of how
emergency medical services are organized in any country. An English
Rosen & Abley Expires 27 January 2023 [Page 20]
Internet-Draft Emergency Registries July 2022
name is preferred, to match the existing entries.
4.5.5.8.4. Content
This registry contains:
* The UTF-8 "Name" of the agency type
* The ASCII "Description" of the agency type
* A "Reference" with a URI to the document that specifies the entry.
Note that the Name is defined as UTF-8, to permit names that have no
English equivalent
4.5.5.9. "urn:emergency:service:serviceAgencyLocator" Subregistry
The ESInet will connect to many services and public safety agencies.
A directory ("white pages" and "yellow pages") of agencies, together
with key information about the service or agency, is the function of
the Service/Agency Locator. The Service/Agency Locator is a
distributed database. There are several mechanisms by which the
Service/Agency Locator can be searched to locate a specific service
or agency. When searching for a service by location, the LoST
protocol ([RFC5222] is used, which accepts a URN that specifies the
service being searched by location. This registry provides urns to
be used witha LoST query to find that service at a particular
location.
4.5.5.9.1. Name
urn:emergency:service:serviceAgencyLocator
4.5.5.9.2. Information Needed to Create a New Value
Short and long versions of the service and a reference to a document
that specifies it.
4.5.5.9.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a kind of service the
Service/Agency Locator holds information for.
4.5.5.9.4. Content
This subregistry contains:
Rosen & Abley Expires 27 January 2023 [Page 21]
Internet-Draft Emergency Registries July 2022
* The "Service Identifier" of the service (e.g."ESRP")
* The long "Service" name of the service (e.g., "Emergency Services
Routing Proxy")
* A "Reference" with a URI to the document that requested the
service.
4.5.5.10. "urn:emergency:uid" Registry
Various entities need to create globally unique identifiers. A
simple way to do that is to combine a locally unique identifier and a
domain name (which is globally unique). However, many entities need
to create more than one type of globally unique identifier and
knowing what type of identifier is helpful in diagnosing problems.
For this purpose, the uid URN subregistry creates unique strings used
to prepend identifiers that indicate the type of identifier it is.
This document does not describe the structure of the identifier
beyond the urn:emergency:uid prefix and the value in this registry.
The defining specification MUST describe the structure of the
identifier.
4.5.5.10.1. Name
urn:emergency:uid
4.5.5.10.2. Information Needed to Create a New Value
Name of the entry, a short description and a reference to a document
that specifies the entry.
4.5.5.10.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of identifier,
and specifies the structure of that identifier.
4.5.5.10.4. Content
this registry contains:
* The UTF-8 "Name" of the identifier prefix
* The UTF-8 "Purpose" of the identifier prefix
* A "Reference" with a URI to the document that requested the
registry entry.
Rosen & Abley Expires 27 January 2023 [Page 22]
Internet-Draft Emergency Registries July 2022
4.5.5.11. "urn:emergency:media-feature" Registry
SIP Media Feature tags as defined in [RFC3840] are used to indicate
user agent capabilities. SIP elements inside ESInets use this
mechanism to indicate availablity of certain emergency call specific
functionality. Since these media feature tags are specific to
emergency calling, are primarily defined in non-IETF documents and
not used outside an ESInet, they are not appropriate for registration
in the SIP Media Feature Tag Registry. This registry provides a
similar function to the registry defined in RFC3840. The separator
between the "urn:emergency:media-feature" and the content of this
registry is a colon (":").
4.5.5.11.1. Name
urn:emergency:media-feature
4.5.5.11.2. Information Needed to Create a New Value
A short tag, purpose description and a reference to a document that
specifies the entry.
4.5.5.11.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of SIP media
feature tag and specifies how it is used.
4.5.5.11.4. Content
This registry contains:
* A short ASCII "Tag"
* A long ASCII "Purpose"
* A "Reference" with a URI to the document that requested the
registry entry.
4.6. Internal Services Registries
The following are additional registries used internally in an ESInet:
Rosen & Abley Expires 27 January 2023 [Page 23]
Internet-Draft Emergency Registries July 2022
4.6.1. "serviceNames" Registry
Processing of emergency calls uses a variety of services which are
queried either using SIP or HTTP. These services are discoverable
through the ESInet that has deployed an instance of these services.
In order to faciliate interoperability there is need to codify their
names in a registry. IANA is requested creates the ServiceNames
registry in the Emergency Area.
4.6.1.1. Name
serviceNames
4.6.1.2. Information Needed to Create a New Value
Short and long names of the service and a reference to a document
that specifies the service.
4.6.1.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of service.
4.6.1.4. Content
This registry contains:
* An ASCII short "Service Name" of the service (e.g., "ADR")
* An ASCII long "Service" name of the service (e.g., "Additional
Data Repository")
* A "Reference", a URI to the document that defines the service.
4.6.2. "serviceState" Registry
All services have a common notion of "state" which comes from this
registry.
4.6.2.1. Name
serviceNames
4.6.2.2. Information Needed to Create a New Value
Name and description of the state and a reference to a document that
specifies it.
Rosen & Abley Expires 27 January 2023 [Page 24]
Internet-Draft Emergency Registries July 2022
4.6.2.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of identifier,
and specifies the structure of that identifier.
4.6.2.4. Content
This registry contains:
* The short "Name" of the service state (e.g., "Normal" or
"ScheduledMaintenanceDown")
* The long "Description" of the service state (e.g., "The service is
operating normally. Calls can be sent to this destination
normally.")
* A "Reference" with a URI to the document that defines the state.
4.6.3. "elementState" Registry
Services are instantiated in physical servers or other equipment,
each of which is called an "element". Typically, multiple elements
are configured for a service for redundancy, and an instance of
multiple services can be instantiated in one element. Elements have
a common notion of state which comes from this registry.
4.6.3.1. Name
elementState
4.6.3.2. Information Needed to Create a New Value
Name and description of the state and a reference to a document that
specifies it.
4.6.3.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new state and the
specification adequately describes it.
4.6.3.4. Content
This registry contains:
* The short "Name" of the element state (e.g., "Normal" or
"ScheduledMaintenanceDown")
Rosen & Abley Expires 27 January 2023 [Page 25]
Internet-Draft Emergency Registries July 2022
* The long "Description" of the element state (e.g., "The service is
operating normally. Calls can be sent to this element normally.")
* A "Reference" with a URI to the document that defines the state.
4.6.4. "SIPHeaderIsOperatorConditions" Registry
Some emergency standards use a policy based routing mechanism where a
policy rule has a series of testable conditions. One such condition
is "SIPHeaderCondition" which tests a SIP header field in the INVITE
or MESSAGE of a call (such as "From", "To", "Contact", etc.).
SIPHeaderCondition has an "operator" member has three potential
values:
* "EQ" for an equality match
* "SS" for a substring match
* "IS" for a registry-defined match
The latter condition includes a value from this registry and tests
the header with the criteria defined for the value.
4.6.4.1. Name
SIPHeaderIsOperatorConditions
4.6.4.2. Information Needed to Create a New Value
Name and description of the test and a reference to a document that
specifies it.
4.6.4.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new test and the
specification adequately describes it.
4.6.4.4. Content
This registry contains:
* A short UTF-8 "Name"
* The long UTF-8 "Description"
* A "Reference" with a URI to the document that requested the
registry entry.
Rosen & Abley Expires 27 January 2023 [Page 26]
Internet-Draft Emergency Registries July 2022
4.6.5. "queueState" Registry
In some emergency services standards emergency calls are delivered to
queues. The state of a queue is standardized, and this registry
defines the allowed states of a queue.
4.6.5.1. Name
queueState
4.6.5.2. Information Needed to Create a New Value
Short name and description of the state and a reference to a document
that specifies it.
4.6.5.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new state and the
specification adequately describes it.
4.6.5.4. Content
This registry contains:
* A short ASCII "Name"
* The long ASCII "Description"
* A "Reference" with a URI to the document that requested the
registry entry.
4.6.6. "securityPosture" Registry
Emergency Services agencies may be attacked in an effort to disrupt
their services. Some emergency services standards allow for various
elements, services and other entities to communicate their current
security status, ranging on a color scale from Green to Red. This
allows downstram and upstream entities to evaluate the current
security conditions of a given entity, such as other parts of the
system or a Security Operations Center.
4.6.6.1. Name
securityPosture
Rosen & Abley Expires 27 January 2023 [Page 27]
Internet-Draft Emergency Registries July 2022
4.6.6.2. Information Needed to Create a New Value
Name and purpose of the state and a reference to a document that
specifies it.
4.6.6.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new security posture,
the value is consistent with the existing values and the
specification adequately describes it.
4.6.6.4. Content
This registry contains:
* A short ASCII "Value"
* The long ASCII "Purpose"
* A "Reference" with a URI to the document that requested the
registry entry.
4.6.7. "ESRP Notify Event Code" Registry
An Emergency Services Routing Proxy routes emergency calls using a
policy based routing mechanism. The policy mechanism includes a
function that can notify an entity when it encounters a defined
condition. This registry defines a common set of codes that tell the
recipient why it received the notification.
4.6.7.1. Name
ESRP Notify Event Code
4.6.7.2. Information Needed to Create a New Value
Name and description of the code and a reference to a document that
specifies it.
4.6.7.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new code and the
specification adequately describes it.
Rosen & Abley Expires 27 January 2023 [Page 28]
Internet-Draft Emergency Registries July 2022
4.6.7.4. Content
This registry contains:
* A short ASCII "Name"
* The long ASCII "Description"
* A "Reference" with a URI to the document that requested the
registry entry.
4.6.8. "Route Cause" Registry
The Emergency Services Routing Proxy routes calls using its Policy
Routing Function. The result of evaluating a rule set is a Route
action that routes the call towards a PSAP or responder. The Route
action includes a Cause value, which is placed in a SIP Reason header
associated with a History-Info header that informs the recipient why
it got the call. A registry is provided for the values in the cause.
The Route action cause is an enumeration, but the Reason header has a
numeric cause value and a text string. IANA is requested to create a
registry to enumerate allowable Route Cause values.
4.6.8.1. Name
Route Cause
4.6.8.2. Information Needed to Create a New Value
Short value, integer code, description of the cause and a reference
to a document that specifies it.
4.6.8.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new cause, the code is
unique and appropriate, and the specification adequately describes
it.
4.6.8.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The "Code" value (a 3-digit integer)
* The ASCII "Text" description (explanatory text, a string)
Rosen & Abley Expires 27 January 2023 [Page 29]
Internet-Draft Emergency Registries July 2022
* A "Reference" (URI) to a document that requests the entry
4.6.9. "LogEvent" Registry
In emergency services, logging is used extensively. Some emergency
services standards define the interface to the loging service and the
format of the data logged. Each event that occurs has a separately
logged "event", and the name and parameters of each type of event are
standardized. The "logEvent" registry enumerates the types of log
records that can be logged.
4.6.9.1. Name
logEvent
4.6.9.2. Information Needed to Create a New Value
Name and purpose of the log event and a reference to a document that
specifies it.
4.6.9.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new log event and the
specification adequately describes it.
4.6.9.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* The ASCII "Purpose" (explanatory text, a string)
* A "Reference" (URI) to a document that requests the entry
4.6.10. "LogEvent Protocol" Registry
In the CallSignalingMessage log event, the protocol of the message
must be logged. This registry provides a registry for the protocol
used for the logging event.
4.6.10.1. Name
LogEvent Protocol
Rosen & Abley Expires 27 January 2023 [Page 30]
Internet-Draft Emergency Registries July 2022
4.6.10.2. Information Needed to Create a New Value
Name a reference to a document that specifies the protocol.
4.6.10.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new protocol and the
specification is an appropriate definition for the protocol.
4.6.10.4. Content
This registry contains:
* The ASCII "Name" of the protocol used (a short string)
* A "Reference" to a document that requests the entry, such as an
RFC
4.6.11. "LogEvent CallTypes" Registry
The type of Call is logegd with the StartCall and EndCall LogEvents.
The StartCall log event includes a "callType" parameter. These call
types are enumerated in this registry. The logEvent allows a call to
have primary and secondary call types. The registry denotes which
call types may be primary call types and which may be secondary.
4.6.11.1. Name
LogEvent CallType
4.6.11.2. Information Needed to Create a New Value
Name and description of the call type and a reference to a document
that specifies it and the classification (primary or secondary) of
the call type.
4.6.11.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new call type, the
specification adequately describes it and the classification is
appropriate.
4.6.11.4. Content
This registry contains:
Rosen & Abley Expires 27 January 2023 [Page 31]
Internet-Draft Emergency Registries July 2022
* The ASCII "Name" (e.g., "emergency") (a short string)
* The ASCII "Description" (e.g., "Call is deemed urgent call and
treated as such") (explanatory text, a string)
* The ASCII "Classification" (e.g., "Primary") (a string)
* A "Reference" (URI) to a document that requests the entry
4.6.12. "Call States" Registry
The state of an emergncy call is logged when it changes (e.g.,
"callBegin" or "callAnswered"). Each change in state is associated
with a log event for that change in state. Many of these log events
correlate with transactions in SIP.
4.6.12.1. Name
Call States
4.6.12.2. Information Needed to Create a New Value
Name and purpose of the state and a reference to a document that
specifies it.
4.6.12.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new state and the
specification adequately describes it.
4.6.12.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* The ASCII "Purpose" (explanatory text, a string)
* A "Reference" (URI) to a document that requests the entry
4.6.13. "LogEvent Announcement Types" Registry
In some circumstances where a call taker is not available
immediately, an automated system may play a (potentially multimedia)
announcement to the caller. A log event records the playback. This
registry defines the generic type of announcement that was played to
the caller.
Rosen & Abley Expires 27 January 2023 [Page 32]
Internet-Draft Emergency Registries July 2022
4.6.13.1. Name
LogEvent Announcement Type
4.6.13.2. Information Needed to Create a New Value
Name and purpose of the announcement type and a reference to a
document that specifies it.
4.6.13.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new announcement type
and the specification adequately describes it.
4.6.13.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* The ASCII "Purpose" (explanatory text, a string)
* A "Reference" (URI) to a document that requests the entry
4.6.14. "non-RTP Media Types" Registry
Most media in an emergency calls uses Real Time Transport Protocol
(RTP), [RFC3550]. LogEvents for RTP transported media record what
kind of media was used in the call. To record what kind of media was
used when RTP is not the transport protocol (such as, for example,
instant messaging), values in this registry are used in the log
event.
4.6.14.1. Name
non-RTP Media Types
4.6.14.2. Information Needed to Create a New Value
Name and description of the media
4.6.14.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of media not
carried in RTP.
Rosen & Abley Expires 27 January 2023 [Page 33]
Internet-Draft Emergency Registries July 2022
4.6.14.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* The ASCII "Description" (explanatory text, a string)
4.6.15. "Agency Roles" Registry
In handling emergency calls Agencies are classified by a specified
Agency Role (e.g., "Dispatch). The role of the agency should not be
confused with the type of agency (such as "Fire"). Agency types are
enumerated in this registry.
4.6.15.1. Name
Agency Roles
4.6.15.2. Information Needed to Create a New Value
Name and description of the role
4.6.15.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of role.
4.6.15.4. Content
This registry contains:
* The ASCII "Role" (a short string)
* The ASCII "Description" (explanatory text, a string)
* A "Reference" (URI) with either contact information for the entity
that or a URI to the document that requests the entry.
4.6.16. "Agent Roles" Registry
Agents are people or automata that are associated with an agency.
Agents have roles (e.g., "Dispatching", "Calltaking"). Agency types
are enumerated in this registry.
Rosen & Abley Expires 27 January 2023 [Page 34]
Internet-Draft Emergency Registries July 2022
4.6.16.1. Name
Agent Roles
4.6.16.2. Information Needed to Create a New Value
Name and description of the role
4.6.16.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new type of role.
4.6.16.4. Content
This registry contains:
* The ASCII "Role" (a short string)
* The ASCII "Description" (explanatory text, a string)
* A "Reference" (URI) with either contact information for the entity
that or a URI to the document that requests the entry.
4.6.17. "Status Codes" Registry
Interfaces in the standards used by this registry use standard status
codes where appropriate. However there are many circumstances where
a more specific error code is used within an ESInet. This registry
enumerates the codes.
4.6.17.1. Name
Status Codes
4.6.17.2. Information Needed to Create a New Value
Status code and text used in the response
4.6.17.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new status code, the
numeric value is appropriate and the specification adequately
describes its use.
Rosen & Abley Expires 27 January 2023 [Page 35]
Internet-Draft Emergency Registries July 2022
4.6.17.4. Content
This registry contains:
* The "Status Code" (a 3 digit integer)
* The ASCII "Description" (explanatory text, a string)
* A "Reference" (URI) to the document that requests the entry.
4.6.18. "Interface Names" Registry
Emergency standards define interfaces that are used by other services
and elements within an ESInet. Policy based access control
mechanisms are used to control use of the interfaces. The policy
uses the entries in this registry to name the interface the policy
applies to.
4.6.18.1. Name
Interface Names
4.6.18.2. Information Needed to Create a New Value
Name of the interface
4.6.18.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new interface.
4.6.18.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.6.19. "Match Type" Registry
When using the LoST protocol [RFC5222] to validate a location prior
to using it in an emergency call, a match against a civic address
record in the LoST server may not be the most specific record
intended by the Location Information Server. This arises because
authorities may not have incomplete records. The emergency standards
define an extension to LoST that returns the type of record that
matched the location information in the LoST request. This registry
Rosen & Abley Expires 27 January 2023 [Page 36]
Internet-Draft Emergency Registries July 2022
enumerates the match types that can be returned.
4.6.19.1. Name
Match Type
4.6.19.2. Information Needed to Create a New Value
Name of the interface
4.6.19.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new interface.
4.6.19.4. Content
This registry contains:
* The UTF-8 "Token" (a short string) (e.g., "Road Centerline" or
"Hybrid").
* The ASCII "Description" (explanatory text, a string)
* A "Reference" (URI) to a document that requests the entry
4.6.20. "GIS Layers" Registry
A Geospatial Information System (GIS) contains features (points,
lines, polygons, etc.) each with a set of attributes, organized in
"layers". Layers (such as discipline-specific service regions, road
centerlines, address points, etc. are common in GIS systems used by
emergency services. This registry enumerates the names of layers
that are used for emergency services alongf with a shorter version
that may be used in databases or interfaces.
4.6.20.1. Name
GIS Layers
4.6.20.2. Information Needed to Create a New Value
Full name of the layer and a short version of the name
4.6.20.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new GIS layer.
Rosen & Abley Expires 27 January 2023 [Page 37]
Internet-Draft Emergency Registries July 2022
4.6.20.4. Content
This registry contains:
* The UTF-8 Full "Name"
* The UTF-8 "Layer Indicator"
* A "Reference" (URI) to a document that requests the entry
4.6.21. "Policy Type" Registry
Policy is widely used in emergency services standards to allow
agencies to control the use of their information, control how routing
is accomplished within an ESInet, and several other instances.
Policies are housed in a standardized "Policy Store". Policies have
a type, which identifies how they are used. This registry enumerates
policy types a Policy Store may have.
4.6.21.1. Name
Policy Type
4.6.21.2. Information Needed to Create a New Value
Type, format and use of the policy
4.6.21.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new interface.
4.6.21.4. Content
This registry contains:
* The UTF-8 "Type" of the policy (a short string) (e.g., "LoST")
* The UTF-8 "Format" of the policy (e.g., "XACML")
* The UTF-8 "Use" of the policy (e.g., "Access rights for Spatial
Interface")
* A "Reference" (URI) to a document that requests the entry
Rosen & Abley Expires 27 January 2023 [Page 38]
Internet-Draft Emergency Registries July 2022
4.6.22. "Discrepancy Report Status Token" Registry
Errors and discrepancies may occur in any set of data, including
databases, configurations, etc. Standardized Discrepancy Report (DR)
functions allow reporting and responding to reports of discrepancies
across vendors. Various types of DRs and responses are defined in
the standards. Many of the reports and/or responses have elements
that are tokens in a restricted list. This registry enumerates the
tokens, and where they can be used.
The registry contains the name of the element in the DR object that
uses the token, and the DR type that uses that element. More than
one element could use the same token, and more than one DR type could
use the same element name (and token values). This means
registration requests can specify more than one value in the "Name"
and "DiscrepancyReports" columns, and a new registration can add a
value to "Name" or "Discrepancy Report" for an existing entry.
4.6.22.1. Name
Discrepancy Report Status Token
4.6.22.2. Information Needed to Create a New Value
Token, Member Name where token is used, Discrepancy Report where
token is used.
4.6.22.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that entry represents a new interface.
4.6.22.4. Content
This registry contains:
* The ASCII "Token" of the DR (a short string) (e.g.,
"LocationReferenceNotResolved")
* The ASCII "Member" of the type of DR (e.g., "Problem" or "Query").
More than one is allowed
* The ACII "Discrepancy Reports" of included discrepancy report(s)
included (e.g., "LoSTDiscrepancyResponse, BCFDiscrepancyReport).
More than one is allowed.
* A "Reference" (URI) to document(s) that request the entry
Rosen & Abley Expires 27 January 2023 [Page 39]
Internet-Draft Emergency Registries July 2022
4.6.23. "Event Package" Registry
SIP Event Package registration procedures are defined in [RFC5727]
and are applicable for any SIP events used on the Internet. For use
within an ESInet only, emergency standards define several SIP Event
packages that are not specified in IETF RFCs. This registry
enumerates those event packages.
4.6.23.1. Name
Event Package
4.6.23.2. Information Needed to Create a New Value
Name of the Event Package
4.6.23.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the event package is documented roughly
similar to SIP Event Package registration requirements in [RFC5727].
4.6.23.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.6.24. "LoggingServiceMediaErrorReasonCodes" Registry
When logging real time media in an ESInet, the recording mechanism
may fail, and a log event, RecordingFailedLogEvent is defined to log
that failure. The reason why the media recording failed is
documented with an entry from this registry.
4.6.24.1. Name
LoggingServiceMediaErrorReasonCodes
4.6.24.2. Information Needed to Create a New Value
Name and description of the reason code.
Rosen & Abley Expires 27 January 2023 [Page 40]
Internet-Draft Emergency Registries July 2022
4.6.24.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new reason for
media failure.
4.6.24.4. Content
This registry contains:
* The ASCII "Name" (a short string)
* The ASCII "Description" (explanatory text, a string)
* A "Reference" (URI) to a document that requests the entry
4.6.24.5. Initial Values
+================+====================================+===========+
| Name | Description | Reference |
+================+====================================+===========+
| lostConnection | The connection to the SRS was lost | This |
| | and could not be re-established | document |
+----------------+------------------------------------+-----------+
| dropOuts | There were significant number of | This |
| | missing media packets | document |
+----------------+------------------------------------+-----------+
Table 1: Initial Values
4.7. EIDO Registries
Following are registries needed to implement the Emergency Incident
Data Object, the standard way to represent incident state when passed
between entities in an ESInet or other emergency services networks,
[EIDO].
4.7.1. "EIDO-AgencyRole" Registry
The role of the agency in relation to the Incident (e.g., "Call
Receiving", "Dispatching", "Dispatched"). This may differ from
agency role as defined in the Agency Role registry.
4.7.1.1. Name
EIDO-AgencyRole
Rosen & Abley Expires 27 January 2023 [Page 41]
Internet-Draft Emergency Registries July 2022
4.7.1.2. Information Needed to Create a New Value
Value and description of the role.
4.7.1.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new role.
4.7.1.4. Content
This registry contains:
* The UTF-8 "Value" (a short string)
* The UTF-8 "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.2. "EIDO-IncidentType-Common" Registry
When multiple agencies are involved in an incident, the type of
incident must be communicated clearly. Many agencies have internal
incident typing systems that are incompatible with each other. The
Association of Public Safety Communications Offials (APCO) has
documented a set of incident types which are the original basis for
this registry ([APCO]), but there is no registry of codes. This
registry forms the complete listing of common type codes.
4.7.2.1. Name
EIDO-IncidentType-Common
4.7.2.2. Information Needed to Create a New Value
Name and description of the reason code.
4.7.2.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new incident
type. Generally this registry should track the APCO document, but
additional codes are allowed to be added provided they are unique
from the APCO codes and are adequately documented in the
specification.
Rosen & Abley Expires 27 January 2023 [Page 42]
Internet-Draft Emergency Registries July 2022
4.7.2.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.3. "EIDO-IncidentStatus-Common" Registry
When multiple agencies are involved in an incident, the status of
incident must be communicated clearly. Many agencies have internal
incident status reporting systems that are incompatible with each
other. This registry enumerates status codes used in an EIDO.
4.7.3.1. Name
EIDO-IncidentStatus-Common
4.7.3.2. Information Needed to Create a New Value
Name and description of the staus code.
4.7.3.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new incident
status.
4.7.3.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.4. "EIDO-ReportNumberType" Registry
Used to indicate the current status of the report number associated
with an incident. If a report number is present in an EIDO, it is
required to indicate the current status of the report number (.e.g,
"New" or "Ongoing"). This registry enumerates the allowed statuses
Rosen & Abley Expires 27 January 2023 [Page 43]
Internet-Draft Emergency Registries July 2022
4.7.4.1. Name
EIDO-ReportNumberType
4.7.4.2. Information Needed to Create a New Value
Name and description of the type.
4.7.4.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new report
number type.
4.7.4.4. Content
This registry contains:
* The UTF-8 "Value" (a short string)
* The UTF-8 "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.5. "EIDO-CommonDispositionCode" Registry
An agency assigns a disposition to an incident when its participation
in the incident ends. The disposition code indicates whether follow-
up reports are required and conveys other information about the
incident, such as whether it resulted from a false or actual alarm.
They are used to exchange the status and follow up requirements of an
incident upon its closure. The disposition codes are drawn from a
registry containing common disposition codes for Police, Fire and EMS
disciplines. These codes are defined by [APCO1.111] and implemented
by [EIDO].
APCO ANS 1.111.2-2018 uses a two-digit integer as an incident status
code. IANA is also requested to hold values 46-100 for future
versions of the standard.
4.7.5.1. Name
EIDO-CommonDispositionCode
4.7.5.2. Information Needed to Create a New Value
Name and description of the disposition code.
Rosen & Abley Expires 27 January 2023 [Page 44]
Internet-Draft Emergency Registries July 2022
4.7.5.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new incident
type. Generally this registry should track the APCO document, but
additional codes are allowed to be added provided they are unique
from the APCO codes and are adequately documented in the
specification.
4.7.5.4. Content
This registry contains:
* The 2 or 3 digit integer code
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.6. "EIDO-PersonRole" Registry
EIDOs may contain Person objects that describe a person someohow
involved in an incident. The "role" of a person in an EIDO describes
the relationship (Caller, Victim, suspect, etc.) of a person to the
incident. This registry enumerates allowable roles. A person can
have multiple roles in an incident.
4.7.6.1. Name
EIDO-PersonRole
4.7.6.2. Information Needed to Create a New Value
Name and description of the role.
4.7.6.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new role.
4.7.6.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
Rosen & Abley Expires 27 January 2023 [Page 45]
Internet-Draft Emergency Registries July 2022
* A "Reference" (URI) to a document that requests the entry
4.7.7. "EIDO-VehicleRelationshipType" Registry
A VehicleRelationshipType describes the relationship (victim's
vehicle, accident vehicle, suspect vehicle, etc.) of a vehicle to the
incident. This registry enumerate the allowable relationship types
allowed.
4.7.7.1. Name
EIDO-VehicleRelationshipType
4.7.7.2. Information Needed to Create a New Value
Name and description of the relationship type.
4.7.7.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new
relationship type.
4.7.7.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.8. "EIDO-LocationType" Registry
A LocationType conveys the location type (Caller, Initial,
CurrentIncident, Staging, Investigation, Tower Location, etc.) of a
location and its relationship to an ongoing incident. This registry
enumerate the allowed LocationTypes.
4.7.8.1. Name
EIDO-LocationType
4.7.8.2. Information Needed to Create a New Value
Name and description of the relationship type.
Rosen & Abley Expires 27 January 2023 [Page 46]
Internet-Draft Emergency Registries July 2022
4.7.8.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new
relationship type.
4.7.8.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.9. "EIDO-PrimaryUnitStatus-Common" Registry
A PrimaryUnitStatus-Common is a standardized code for the current
status of an emergency response units (e.g., whether a fire engine is
"available" or "notAvailable"). This registry enumerates the allowed
primary status codes. Primary status is a fundamental status
("notAvailable") rather than a "why" the unit is in that status. See
Section 4.7.10 for the latter information.
4.7.9.1. Name
EIDO-PrimaryUnitStatus-Common
4.7.9.2. Information Needed to Create a New Value
Name and description of the status code.
4.7.9.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new primary
unit status.
4.7.9.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
Rosen & Abley Expires 27 January 2023 [Page 47]
Internet-Draft Emergency Registries July 2022
4.7.10. "EIDO-SecondaryUnitStatus-Common" Registry
Statuses that further qualifies the Primary Unit Status by providing
more detail about the associated primary status. This registry
enumerates the allowed secondary status values.
4.7.10.1. Name
EIDO-SecondaryUnitStatus-Common
4.7.10.2. Information Needed to Create a New Value
Name and description of the status.
4.7.10.3. Registration policy
Specification Required [RFC8126], which requires expert review. The
expert should confirm that the the entry represents a new secondary
unit status.
4.7.10.4. Content
This registry contains:
* The ASCII "Value" (a short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.11. "EIDO-EmergencyResourceType-Common" Registry
A standardized code for an emergency resource type (e.g., BombSquad,
AirAmbulanceRotaryWing). Resource Types are teams and/equipment as
opposed to individuals with a skill set. This registry enumerates
allowed resource types.
4.7.11.1. Name
EIDO-EmergencyResourceType-Common
4.7.11.2. Information Needed to Create a New Value
Name and description of the resource type.
Rosen & Abley Expires 27 January 2023 [Page 48]
Internet-Draft Emergency Registries July 2022
4.7.11.3. Registration policy
First Come, First Served and Expert Review. The expert should
confirm that the the entry represents a new resource type. Use of
trademarked names, or vendor specific terms is discouraged.
4.7.11.4. Content
This registry contains:
* The UTF-8 "Value" (a short string)
* The UTF-8 "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
4.7.12. "EIDO-ResourceAttribute" Registry
A standard code for an emergency resource attribute (skill and
equipment; e.g., "EMSPhysician, "EMT", "SCBA". Also indicates an
interpreter's translation abilities, such as "UkranianInterpreter")
possessed by an emergency resource). This registry enumerates the
allowed attributes.
4.7.12.1. Name
EIDO-ResourceAttribute
4.7.12.2. Information Needed to Create a New Value
Name and description of the resource attribute.
4.7.12.3. Registration policy
Expert Review. No standards document required. The expert should
confirm that the the entry represents a new resource attribute. Use
of trademarked names, or vendor specific terms is discouraged.
4.7.12.4. Content
This registry contains:
* The UTF-8 "Value" (a short string)
* The UTF-8 "Literal Description" (a short string)
* A "Reference" (URI) to a document that requests the entry
Rosen & Abley Expires 27 January 2023 [Page 49]
Internet-Draft Emergency Registries July 2022
4.7.13. "eidoExtensionId" Registry
Vendors and users are highly likely to need to extend an EIDO to
handle capabilities not common to all implementations. It is useful
to at least list all such extensions and provide a way to inform
others of what they are. This registry provides a way to inform
others about a proprietary extension to the EIDO.
4.7.13.1. Name
EIDO-Resource Attribute
4.7.13.2. Information Needed to Create a New Value
Owner, contact, unique identifier, description and a reference to a
schema. Note that the "Contact" may not be in English and therefore
is specified as UTF-8.
4.7.13.3. Registration policy
Expert Review. No standards document required. The expert should
confirm that the the entry is complete, the provided URIs resolve to
reasonable locations and the ID is unique.
4.7.13.4. Content
This registry contains:
* The UTF-8 "Owner" of the extension (either a person or an
organization) (a short string)
* A stable "Contact" (URI) to contact the Owner
* The ASCII "ID" (a unique short string)
* The ASCII "Literal Description" (a short string)
* A "Reference" (URI) to the extension schema
5. Security Considerations
This document only defines registries populated by other documents,
not how they are used. As such there are no special security
considerations introduced by this document, outside of those
considerations specific to a given registry (e.g., the
"securityPosture" registry), although those considerations are
introduced by the source document and not this one.
Rosen & Abley Expires 27 January 2023 [Page 50]
Internet-Draft Emergency Registries July 2022
6. References
6.1. Normative References
[APCO] APCO, "APCO 2.103.2-2019 Public Safety Communications
Common Incident Types for Data Exchange", 2019,
<https://www.apcointl.org/download/public-safety-
communications-common-incident-types-for-data-
exchange/?wpdmdl=6346>.
[APCO1.111]
APCO, "APCO ANS 1.111.2-2018 Public Safety Communications
Common Disposition Codes for Data Exchange", 2018,
<https://www.apcointl.org/download/apco_ans_1-111-2-2018-
disposition-codes/>.
[EIDO] NENA, "NENA Standard for Emergency Incident Data Object
(Public Review Draft)", February 2022,
<https://dev.nena.org/higherlogic/ws/public/
download/23026/NENA-STA-021.1%20EIDO%20JSON%20PubRvw.pdf>.
[NENAi3] NENA, "NENA i3 Standard for Next-Generation 9-1-1, Version
3 ("i3 Version 3")", April 2021,
<https://www.nena.org/page/i3_Stage3>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", DOI 10.17487/RFC2119, BCP 14,
RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[NG112] EENA, "EENA NG112 Project", May 2020,
<https://eena.org/eena-ng112-project/>.
[NRS] NENA, "NENA Registry System",
<https://www.nena.org/page/nena_registry_system>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
Rosen & Abley Expires 27 January 2023 [Page 51]
Internet-Draft Emergency Registries July 2022
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
DOI 10.17487/RFC5031, January 2008,
<https://www.rfc-editor.org/info/rfc5031>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/info/rfc5222>.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67,
RFC 5727, DOI 10.17487/RFC5727, March 2010,
<https://www.rfc-editor.org/info/rfc5727>.
[RFC6061] Rosen, B., "Uniform Resource Name (URN) Namespace for the
National Emergency Number Association (NENA)", RFC 6061,
DOI 10.17487/RFC6061, January 2011,
<https://www.rfc-editor.org/info/rfc6061>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <https://www.rfc-editor.org/info/rfc6443>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 8126,
DOI 10.17487/RFC8126, BCP 26, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
RFC 8216, DOI 10.17487/RFC8216, August 2017,
<https://www.rfc-editor.org/info/rfc8216>.
[SIPProto] IANA, "Session Initiation Protocol (SIP) Parameters,
Reason Parameters", June 2022,
<https://www.iana.org/assignments/sip-parameters/sip-
parameters.xhtml#sip-parameters-3>.
Authors' Addresses
Rosen & Abley Expires 27 January 2023 [Page 52]
Internet-Draft Emergency Registries July 2022
Brian Rosen
Unaffiliated
Mars, PA
United States of America
Email: br@brianrosen.net
Brandon Abley (editor)
NENA
Alexandria, VA
United States of America
Email: babley@nena.org
Rosen & Abley Expires 27 January 2023 [Page 53]
