ecrit                                                         B.R. Rosen
Internet-Draft                                              Unaffiliated
Intended status: Standards Track                              B.A. Abley
Expires: 6 July 2025                                                NENA
                                                          2 January 2025


                          Emergency Registries
                draft-ietf-ecrit-emergency-registries-00

Abstract

   Multiple emergency services standards organizations are developing
   specifications based on IETF emergency calling 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 6 July 2025.

Copyright Notice

   Copyright (c) 2025 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 6 July 2025                  [Page 1]

Internet-Draft            Emergency Registries              January 2025


   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
   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 Purpose Parameter Value . . . . . . . . . . . .   9
     4.3.  "Emergency" Group . . . . . . . . . . . . . . . . . . . .   9
     4.4.  "emergency" URN namespace . . . . . . . . . . . . . . . .  10
       4.4.1.  Namespace Identifier  . . . . . . . . . . . . . . . .  10
       4.4.2.  Version . . . . . . . . . . . . . . . . . . . . . . .  10
       4.4.3.  Date  . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.4.4.  Registrant  . . . . . . . . . . . . . . . . . . . . .  10
       4.4.5.  Purpose . . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.6.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.7.  Assignment  . . . . . . . . . . . . . . . . . . . . .  12
       4.4.8.  Security and Privacy  . . . . . . . . . . . . . . . .  12
       4.4.9.  Interoperability  . . . . . . . . . . . . . . . . . .  12
       4.4.10. Resolution  . . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Emergency Call Additional Data Registry . . . . . . . . .  12
     4.6.  "urn:emergency" registry  . . . . . . . . . . . . . . . .  12
       4.6.1.  Name  . . . . . . . . . . . . . . . . . . . . . . . .  13
       4.6.2.  Information Needed to Create a New Value  . . . . . .  13
       4.6.3.  Registration policy . . . . . . . . . . . . . . . . .  13
       4.6.4.  Content . . . . . . . . . . . . . . . . . . . . . . .  13
       4.6.5.  Subregistries for top level classes of
               urn:emergency . . . . . . . . . . . . . . . . . . . .  13
         4.6.5.1.  "urn:emergency:service" Subregistry . . . . . . .  14
           4.6.5.1.1.  Name  . . . . . . . . . . . . . . . . . . . .  14
           4.6.5.1.2.  Information Needed to Create a New Value  . .  14
           4.6.5.1.3.  Registration policy . . . . . . . . . . . . .  14
           4.6.5.1.4.  Content . . . . . . . . . . . . . . . . . . .  15
         4.6.5.2.  "urn:emergency:service:sos" Subregistry . . . . .  15
           4.6.5.2.1.  Name  . . . . . . . . . . . . . . . . . . . .  15
           4.6.5.2.2.  Information Needed to Create a New Value  . .  15
           4.6.5.2.3.  Registration policy . . . . . . . . . . . . .  15
           4.6.5.2.4.  Content . . . . . . . . . . . . . . . . . . .  16
         4.6.5.3.  "urn:emergency:service:test" Registry . . . . . .  16
           4.6.5.3.1.  Name  . . . . . . . . . . . . . . . . . . . .  16
           4.6.5.3.2.  Information Needed to Create a New Value  . .  17



Rosen & Abley              Expires 6 July 2025                  [Page 2]

Internet-Draft            Emergency Registries              January 2025


           4.6.5.3.3.  Registration policy . . . . . . . . . . . . .  17
           4.6.5.3.4.  Content . . . . . . . . . . . . . . . . . . .  17
         4.6.5.4.  "urn:emergency:service:responder" Registry  . . .  17
           4.6.5.4.1.  Name  . . . . . . . . . . . . . . . . . . . .  18
           4.6.5.4.2.  Information Needed to Create a New Value  . .  18
           4.6.5.4.3.  Registration policy . . . . . . . . . . . . .  18
           4.6.5.4.4.  Content . . . . . . . . . . . . . . . . . . .  18
         4.6.5.5.  "urn:emergency:service:responder.police"
                 Subregistry . . . . . . . . . . . . . . . . . . . .  18
           4.6.5.5.1.  Name  . . . . . . . . . . . . . . . . . . . .  18
           4.6.5.5.2.  Information Needed to Create a New Value  . .  18
           4.6.5.5.3.  Registration policy . . . . . . . . . . . . .  19
           4.6.5.5.4.  Content . . . . . . . . . . . . . . . . . . .  19
         4.6.5.6.  "police.federal" Subregistry  . . . . . . . . . .  19
           4.6.5.6.1.  Name  . . . . . . . . . . . . . . . . . . . .  19
           4.6.5.6.2.  Information Needed to Create a New Value  . .  20
           4.6.5.6.3.  Registration policy . . . . . . . . . . . . .  20
           4.6.5.6.4.  Content . . . . . . . . . . . . . . . . . . .  20
         4.6.5.7.  "urn:emergency:service:responder.fire"
                 Subregistry . . . . . . . . . . . . . . . . . . . .  20
           4.6.5.7.1.  Name  . . . . . . . . . . . . . . . . . . . .  20
           4.6.5.7.2.  Information Needed to Create a New Value  . .  20
           4.6.5.7.3.  Registration policy . . . . . . . . . . . . .  21
           4.6.5.7.4.  Content . . . . . . . . . . . . . . . . . . .  21
         4.6.5.8.  "urn:emergency:service:responder.ems"
                 Subregistry . . . . . . . . . . . . . . . . . . . .  21
           4.6.5.8.1.  Name  . . . . . . . . . . . . . . . . . . . .  21
           4.6.5.8.2.  Information Needed to Create a New Value  . .  21
           4.6.5.8.3.  Registration policy . . . . . . . . . . . . .  21
           4.6.5.8.4.  Content . . . . . . . . . . . . . . . . . . .  22
         4.6.5.9.  "urn:emergency:service:serviceAgencyLocator"
                 Subregistry . . . . . . . . . . . . . . . . . . . .  22
           4.6.5.9.1.  Name  . . . . . . . . . . . . . . . . . . . .  22
           4.6.5.9.2.  Information Needed to Create a New Value  . .  22
           4.6.5.9.3.  Registration policy . . . . . . . . . . . . .  22
           4.6.5.9.4.  Content . . . . . . . . . . . . . . . . . . .  22
         4.6.5.10. "urn:emergency:uid" Registry  . . . . . . . . . .  23
           4.6.5.10.1.  Name . . . . . . . . . . . . . . . . . . . .  23
           4.6.5.10.2.  Information Needed to Create a New Value . .  23
           4.6.5.10.3.  Registration policy  . . . . . . . . . . . .  23
           4.6.5.10.4.  Content  . . . . . . . . . . . . . . . . . .  23
         4.6.5.11. "urn:emergency:media-feature" Registry  . . . . .  24
           4.6.5.11.1.  Name . . . . . . . . . . . . . . . . . . . .  24
           4.6.5.11.2.  Information Needed to Create a New Value . .  24
           4.6.5.11.3.  Registration policy  . . . . . . . . . . . .  24
           4.6.5.11.4.  Content  . . . . . . . . . . . . . . . . . .  24
     4.7.  Internal Services Registries  . . . . . . . . . . . . . .  24
       4.7.1.  "serviceNames" Registry . . . . . . . . . . . . . . .  25



Rosen & Abley              Expires 6 July 2025                  [Page 3]

Internet-Draft            Emergency Registries              January 2025


         4.7.1.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  25
         4.7.1.2.  Information Needed to Create a New Value  . . . .  25
         4.7.1.3.  Registration policy . . . . . . . . . . . . . . .  25
         4.7.1.4.  Content . . . . . . . . . . . . . . . . . . . . .  25
       4.7.2.  "serviceState" Registry . . . . . . . . . . . . . . .  25
         4.7.2.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  25
         4.7.2.2.  Information Needed to Create a New Value  . . . .  26
         4.7.2.3.  Registration policy . . . . . . . . . . . . . . .  26
         4.7.2.4.  Content . . . . . . . . . . . . . . . . . . . . .  26
       4.7.3.  "elementState" Registry . . . . . . . . . . . . . . .  26
         4.7.3.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  26
         4.7.3.2.  Information Needed to Create a New Value  . . . .  26
         4.7.3.3.  Registration policy . . . . . . . . . . . . . . .  26
         4.7.3.4.  Content . . . . . . . . . . . . . . . . . . . . .  27
       4.7.4.  "SIPHeaderIsOperatorConditions" Registry  . . . . . .  27
         4.7.4.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  27
         4.7.4.2.  Information Needed to Create a New Value  . . . .  27
         4.7.4.3.  Registration policy . . . . . . . . . . . . . . .  27
         4.7.4.4.  Content . . . . . . . . . . . . . . . . . . . . .  28
       4.7.5.  "queueState" Registry . . . . . . . . . . . . . . . .  28
         4.7.5.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  28
         4.7.5.2.  Information Needed to Create a New Value  . . . .  28
         4.7.5.3.  Registration policy . . . . . . . . . . . . . . .  28
         4.7.5.4.  Content . . . . . . . . . . . . . . . . . . . . .  28
       4.7.6.  "securityPosture" Registry  . . . . . . . . . . . . .  29
         4.7.6.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  29
         4.7.6.2.  Information Needed to Create a New Value  . . . .  29
         4.7.6.3.  Registration policy . . . . . . . . . . . . . . .  29
         4.7.6.4.  Content . . . . . . . . . . . . . . . . . . . . .  29
       4.7.7.  "ESRP Notify Event Code" Registry . . . . . . . . . .  29
         4.7.7.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  30
         4.7.7.2.  Information Needed to Create a New Value  . . . .  30
         4.7.7.3.  Registration policy . . . . . . . . . . . . . . .  30
         4.7.7.4.  Content . . . . . . . . . . . . . . . . . . . . .  30
       4.7.8.  "Route Cause" Registry  . . . . . . . . . . . . . . .  30
         4.7.8.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  30
         4.7.8.2.  Information Needed to Create a New Value  . . . .  30
         4.7.8.3.  Registration policy . . . . . . . . . . . . . . .  31
         4.7.8.4.  Content . . . . . . . . . . . . . . . . . . . . .  31
       4.7.9.  "LogEvent" Registry . . . . . . . . . . . . . . . . .  31
         4.7.9.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  31
         4.7.9.2.  Information Needed to Create a New Value  . . . .  31
         4.7.9.3.  Registration policy . . . . . . . . . . . . . . .  31
         4.7.9.4.  Content . . . . . . . . . . . . . . . . . . . . .  31
       4.7.10. "LogEvent Protocol" Registry  . . . . . . . . . . . .  32
         4.7.10.1.  Name . . . . . . . . . . . . . . . . . . . . . .  32
         4.7.10.2.  Information Needed to Create a New Value . . . .  32
         4.7.10.3.  Registration policy  . . . . . . . . . . . . . .  32



Rosen & Abley              Expires 6 July 2025                  [Page 4]

Internet-Draft            Emergency Registries              January 2025


         4.7.10.4.  Content  . . . . . . . . . . . . . . . . . . . .  32
       4.7.11. "LogEvent CallTypes" Registry . . . . . . . . . . . .  32
         4.7.11.1.  Name . . . . . . . . . . . . . . . . . . . . . .  32
         4.7.11.2.  Information Needed to Create a New Value . . . .  33
         4.7.11.3.  Registration policy  . . . . . . . . . . . . . .  33
         4.7.11.4.  Content  . . . . . . . . . . . . . . . . . . . .  33
       4.7.12. "Call States" Registry  . . . . . . . . . . . . . . .  33
         4.7.12.1.  Name . . . . . . . . . . . . . . . . . . . . . .  33
         4.7.12.2.  Information Needed to Create a New Value . . . .  33
         4.7.12.3.  Registration policy  . . . . . . . . . . . . . .  33
         4.7.12.4.  Content  . . . . . . . . . . . . . . . . . . . .  34
       4.7.13. "LogEvent Announcement Types" Registry  . . . . . . .  34
         4.7.13.1.  Name . . . . . . . . . . . . . . . . . . . . . .  34
         4.7.13.2.  Information Needed to Create a New Value . . . .  34
         4.7.13.3.  Registration policy  . . . . . . . . . . . . . .  34
         4.7.13.4.  Content  . . . . . . . . . . . . . . . . . . . .  34
       4.7.14. "non-RTP Media Types" Registry  . . . . . . . . . . .  35
         4.7.14.1.  Name . . . . . . . . . . . . . . . . . . . . . .  35
         4.7.14.2.  Information Needed to Create a New Value . . . .  35
         4.7.14.3.  Registration policy  . . . . . . . . . . . . . .  35
         4.7.14.4.  Content  . . . . . . . . . . . . . . . . . . . .  35
       4.7.15. "Agency Roles" Registry . . . . . . . . . . . . . . .  35
         4.7.15.1.  Name . . . . . . . . . . . . . . . . . . . . . .  35
         4.7.15.2.  Information Needed to Create a New Value . . . .  35
         4.7.15.3.  Registration policy  . . . . . . . . . . . . . .  36
         4.7.15.4.  Content  . . . . . . . . . . . . . . . . . . . .  36
       4.7.16. "Agent Roles" Registry  . . . . . . . . . . . . . . .  36
         4.7.16.1.  Name . . . . . . . . . . . . . . . . . . . . . .  36
         4.7.16.2.  Information Needed to Create a New Value . . . .  36
         4.7.16.3.  Registration policy  . . . . . . . . . . . . . .  36
         4.7.16.4.  Content  . . . . . . . . . . . . . . . . . . . .  36
       4.7.17. "Status Codes" Registry . . . . . . . . . . . . . . .  37
         4.7.17.1.  Name . . . . . . . . . . . . . . . . . . . . . .  37
         4.7.17.2.  Information Needed to Create a New Value . . . .  37
         4.7.17.3.  Registration policy  . . . . . . . . . . . . . .  37
         4.7.17.4.  Content  . . . . . . . . . . . . . . . . . . . .  37
       4.7.18. "Interface Names" Registry  . . . . . . . . . . . . .  37
         4.7.18.1.  Name . . . . . . . . . . . . . . . . . . . . . .  37
         4.7.18.2.  Information Needed to Create a New Value . . . .  37
         4.7.18.3.  Registration policy  . . . . . . . . . . . . . .  38
         4.7.18.4.  Content  . . . . . . . . . . . . . . . . . . . .  38
       4.7.19. "Match Type" Registry . . . . . . . . . . . . . . . .  38
         4.7.19.1.  Name . . . . . . . . . . . . . . . . . . . . . .  38
         4.7.19.2.  Information Needed to Create a New Value . . . .  38
         4.7.19.3.  Registration policy  . . . . . . . . . . . . . .  38
         4.7.19.4.  Content  . . . . . . . . . . . . . . . . . . . .  38
       4.7.20. "GIS Layers" Registry . . . . . . . . . . . . . . . .  39
         4.7.20.1.  Name . . . . . . . . . . . . . . . . . . . . . .  39



Rosen & Abley              Expires 6 July 2025                  [Page 5]

Internet-Draft            Emergency Registries              January 2025


         4.7.20.2.  Information Needed to Create a New Value . . . .  39
         4.7.20.3.  Registration policy  . . . . . . . . . . . . . .  39
         4.7.20.4.  Content  . . . . . . . . . . . . . . . . . . . .  39
       4.7.21. "Policy Type" Registry  . . . . . . . . . . . . . . .  39
         4.7.21.1.  Name . . . . . . . . . . . . . . . . . . . . . .  39
         4.7.21.2.  Information Needed to Create a New Value . . . .  40
         4.7.21.3.  Registration policy  . . . . . . . . . . . . . .  40
         4.7.21.4.  Content  . . . . . . . . . . . . . . . . . . . .  40
       4.7.22. "Discrepancy Report Status Token" Registry  . . . . .  40
         4.7.22.1.  Name . . . . . . . . . . . . . . . . . . . . . .  40
         4.7.22.2.  Information Needed to Create a New Value . . . .  40
         4.7.22.3.  Registration policy  . . . . . . . . . . . . . .  41
         4.7.22.4.  Content  . . . . . . . . . . . . . . . . . . . .  41
       4.7.23. "Event Package" Registry  . . . . . . . . . . . . . .  41
         4.7.23.1.  Name . . . . . . . . . . . . . . . . . . . . . .  41
         4.7.23.2.  Information Needed to Create a New Value . . . .  41
         4.7.23.3.  Registration policy  . . . . . . . . . . . . . .  41
         4.7.23.4.  Content  . . . . . . . . . . . . . . . . . . . .  41
       4.7.24. "LoggingServiceMediaErrorReasonCodes" Registry  . . .  42
         4.7.24.1.  Name . . . . . . . . . . . . . . . . . . . . . .  42
         4.7.24.2.  Information Needed to Create a New Value . . . .  42
         4.7.24.3.  Registration policy  . . . . . . . . . . . . . .  42
         4.7.24.4.  Content  . . . . . . . . . . . . . . . . . . . .  42
         4.7.24.5.  Initial Values . . . . . . . . . . . . . . . . .  42
     4.8.  Emergency Call-Info Purpose Registry  . . . . . . . . . .  43
       4.8.1.  Name  . . . . . . . . . . . . . . . . . . . . . . . .  43
       4.8.2.  Information Needed to Create a New Value  . . . . . .  43
       4.8.3.  Registration policy . . . . . . . . . . . . . . . . .  43
       4.8.4.  Content . . . . . . . . . . . . . . . . . . . . . . .  43
     4.9.  EIDO Registries . . . . . . . . . . . . . . . . . . . . .  43
       4.9.1.  "EIDO-AgencyRole" Registry  . . . . . . . . . . . . .  43
         4.9.1.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  44
         4.9.1.2.  Information Needed to Create a New Value  . . . .  44
         4.9.1.3.  Registration policy . . . . . . . . . . . . . . .  44
         4.9.1.4.  Content . . . . . . . . . . . . . . . . . . . . .  44
       4.9.2.  "EIDO-IncidentType-Common" Registry . . . . . . . . .  44
         4.9.2.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  44
         4.9.2.2.  Information Needed to Create a New Value  . . . .  44
         4.9.2.3.  Registration policy . . . . . . . . . . . . . . .  45
         4.9.2.4.  Content . . . . . . . . . . . . . . . . . . . . .  45
       4.9.3.  "EIDO-IncidentStatus-Common" Registry . . . . . . . .  45
         4.9.3.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  45
         4.9.3.2.  Information Needed to Create a New Value  . . . .  45
         4.9.3.3.  Registration policy . . . . . . . . . . . . . . .  45
         4.9.3.4.  Content . . . . . . . . . . . . . . . . . . . . .  45
       4.9.4.  "EIDO-ReportNumberType" Registry  . . . . . . . . . .  46
         4.9.4.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  46
         4.9.4.2.  Information Needed to Create a New Value  . . . .  46



Rosen & Abley              Expires 6 July 2025                  [Page 6]

Internet-Draft            Emergency Registries              January 2025


         4.9.4.3.  Registration policy . . . . . . . . . . . . . . .  46
         4.9.4.4.  Content . . . . . . . . . . . . . . . . . . . . .  46
       4.9.5.  "EIDO-CommonDispositionCode" Registry . . . . . . . .  46
         4.9.5.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  47
         4.9.5.2.  Information Needed to Create a New Value  . . . .  47
         4.9.5.3.  Registration policy . . . . . . . . . . . . . . .  47
         4.9.5.4.  Content . . . . . . . . . . . . . . . . . . . . .  47
       4.9.6.  "EIDO-PersonRole" Registry  . . . . . . . . . . . . .  47
         4.9.6.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  47
         4.9.6.2.  Information Needed to Create a New Value  . . . .  47
         4.9.6.3.  Registration policy . . . . . . . . . . . . . . .  47
         4.9.6.4.  Content . . . . . . . . . . . . . . . . . . . . .  48
       4.9.7.  "EIDO-VehicleRelationshipType" Registry . . . . . . .  48
         4.9.7.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  48
         4.9.7.2.  Information Needed to Create a New Value  . . . .  48
         4.9.7.3.  Registration policy . . . . . . . . . . . . . . .  48
         4.9.7.4.  Content . . . . . . . . . . . . . . . . . . . . .  48
       4.9.8.  "EIDO-LocationType" Registry  . . . . . . . . . . . .  48
         4.9.8.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  49
         4.9.8.2.  Information Needed to Create a New Value  . . . .  49
         4.9.8.3.  Registration policy . . . . . . . . . . . . . . .  49
         4.9.8.4.  Content . . . . . . . . . . . . . . . . . . . . .  49
       4.9.9.  "EIDO-PrimaryUnitStatus-Common" Registry  . . . . . .  49
         4.9.9.1.  Name  . . . . . . . . . . . . . . . . . . . . . .  49
         4.9.9.2.  Information Needed to Create a New Value  . . . .  49
         4.9.9.3.  Registration policy . . . . . . . . . . . . . . .  49
         4.9.9.4.  Content . . . . . . . . . . . . . . . . . . . . .  50
       4.9.10. "EIDO-SecondaryUnitStatus-Common" Registry  . . . . .  50
         4.9.10.1.  Name . . . . . . . . . . . . . . . . . . . . . .  50
         4.9.10.2.  Information Needed to Create a New Value . . . .  50
         4.9.10.3.  Registration policy  . . . . . . . . . . . . . .  50
         4.9.10.4.  Content  . . . . . . . . . . . . . . . . . . . .  50
       4.9.11. "EIDO-EmergencyResourceType-Common" Registry  . . . .  50
         4.9.11.1.  Name . . . . . . . . . . . . . . . . . . . . . .  51
         4.9.11.2.  Information Needed to Create a New Value . . . .  51
         4.9.11.3.  Registration policy  . . . . . . . . . . . . . .  51
         4.9.11.4.  Content  . . . . . . . . . . . . . . . . . . . .  51
       4.9.12. "EIDO-ResourceAttribute" Registry . . . . . . . . . .  51
         4.9.12.1.  Name . . . . . . . . . . . . . . . . . . . . . .  51
         4.9.12.2.  Information Needed to Create a New Value . . . .  51
         4.9.12.3.  Registration policy  . . . . . . . . . . . . . .  51
         4.9.12.4.  Content  . . . . . . . . . . . . . . . . . . . .  52
       4.9.13. "eidoExtensionId" Registry  . . . . . . . . . . . . .  52
         4.9.13.1.  Name . . . . . . . . . . . . . . . . . . . . . .  52
         4.9.13.2.  Information Needed to Create a New Value . . . .  52
         4.9.13.3.  Registration policy  . . . . . . . . . . . . . .  52
         4.9.13.4.  Content  . . . . . . . . . . . . . . . . . . . .  52
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  53



Rosen & Abley              Expires 6 July 2025                  [Page 7]

Internet-Draft            Emergency Registries              January 2025


   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  53
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  53
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  53
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  55

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 worldwide 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 top-level registry called "Emergency" and to
   create a set of sub-registries within that registry.  This document
   does not provide 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].

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]) and similar programs in other
   regions.








Rosen & Abley              Expires 6 July 2025                  [Page 8]

Internet-Draft            Emergency Registries              January 2025


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 Purpose Parameter Value

   This document defines the 'Emergency' prefix for the 'purpose'
   parameter of the Call-Info header field [RFC3261].  IANA is requested
   to add this document to the list of references for the 'purpose'
   value of Call-Info in the "Header Field Parameters and Parameter
   Values" sub- registry of the "Session Initiation Protocol (SIP)
   Parameters" registry.  Note that 'Emergency' is a compound value;
   when used as a value of the 'purpose' parameter of a Call-Info header
   field, 'Emergency' is immediately followed by a hyphen ('-') and a
   value from the Emergency Call-Info Purpose registry.

4.3.  "Emergency" Group

   IANA is requested to establish the registries within this section
   under the "Emergency" group.  These registries contain enumerated
   values used for various aspects of emergency calling and call
   handling.  New registries or subregistries in the "Emergency" group
   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 in which emergency services standards are in scope.
   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



Rosen & Abley              Expires 6 July 2025                  [Page 9]

Internet-Draft            Emergency Registries              January 2025


   organization in which emergency services standards are in scope, 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
   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 needed in order 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" URN namespace

   IANA is requested to register a new URN namespace for "emergency".

4.4.1.  Namespace Identifier

   emergency

4.4.2.  Version

   1

4.4.3.  Date

   RFC Editor: please insert the date this RFC was published

4.4.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 6 July 2025                 [Page 10]

Internet-Draft            Emergency Registries              January 2025


4.4.5.  Purpose

   This namespace is used for unique identifiers for use in emergency
   services, including emergency calls.  Although 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" Namespace Identifier (NID), defined in [RFC6061].  Most
   identifiers in top level class <<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 be
   primarily specified in public safety standards SDOs, but some IETF
   standards may use or define them.

4.4.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.6

   <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 case insensitive.  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.










Rosen & Abley              Expires 6 July 2025                 [Page 11]

Internet-Draft            Emergency Registries              January 2025


4.4.7.  Assignment

   Assignment of top level classes is by standards documents, both
   standards-track RFCs and standards documents in other SDOs.  See
   Section 4.6.  Assignments within top level classes are as specified
   in the document that defines the class.  Such documents MUST specify
   how uniqueness within the class is achieved.

4.4.8.  Security and Privacy

   The document defining a top level class 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.
   Transport 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.  Specifications implementing
   classes in this document MAY allow exceptions to this encryption
   requirement if justified.  Where a document defines top level
   class(es), it MUST state if transport encryption is required when
   conveying any indentifiers it defines.

4.4.9.  Interoperability

   Many of the identifiers in "<urn:emergency>" are similar in
   construction and use to 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
   document that defined and uses most of the identifiers in
   "<urn:nena>"; a future revision is expected to address backwards
   compatibility requirements between "<urn:emergency>" and
   "<urn:nena>".  There are no other interoperability issues.

4.4.10.  Resolution

   No resolution of these identifiers is defined.

4.5.  Emergency Call Additional Data Registry

   IANA is requested to move the Emergency Call Additional Data registry
   and its sub-registries to the Emergency Registry.

4.6.  "urn:emergency" registry

   IANA is requested to create a registry for the emergency NID top
   level classes in the Emergency Registry.



Rosen & Abley              Expires 6 July 2025                 [Page 12]

Internet-Draft            Emergency Registries              January 2025


4.6.1.  Name

   urn:emergency

4.6.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.6.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.6.5.

4.6.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.6.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:emergency>".  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.



Rosen & Abley              Expires 6 July 2025                 [Page 13]

Internet-Draft            Emergency Registries              January 2025


4.6.5.1.  "urn:emergency:service" Subregistry

   IANA is requested to create a subregistry for "urn:emergency:service"
   under "urn:emergency".

   When calls are routed to or 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.  External 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 distinguishable by the LoST server from other uses.  For example,
   emergency calls being routed to or within an 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.

4.6.5.1.1.  Name

   urn:emergency:service

4.6.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.6.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 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



Rosen & Abley              Expires 6 July 2025                 [Page 14]

Internet-Draft            Emergency Registries              January 2025


   *  the reference leads to a document that clearly describes the use
      of the class.

   Also see Section 4.6.5.

4.6.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.6.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 an ESInet is a primary function of
   systems that process such calls.  When routing entities must route
   calls within an 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 an ESInet.  The separator
   between urn:emergency:service:sos and an entry in the subregistry is
   a colon (":").

4.6.5.2.1.  Name

   urn:emergency:service:sos

4.6.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.6.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:



Rosen & Abley              Expires 6 July 2025                 [Page 15]

Internet-Draft            Emergency Registries              January 2025


   *  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.6.5.

4.6.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.6.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 from outside an ESInet 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 corresponding 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 an 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"
   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" at a corresponding level.

4.6.5.3.1.  Name

   urn:emergency:service:test




Rosen & Abley              Expires 6 July 2025                 [Page 16]

Internet-Draft            Emergency Registries              January 2025


4.6.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.6.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.6.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.6.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 an 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 an 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
   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.




Rosen & Abley              Expires 6 July 2025                 [Page 17]

Internet-Draft            Emergency Registries              January 2025


4.6.5.4.1.  Name

   urn:emergency:service:responder

4.6.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.6.5.4.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a kind of responder,
   considered broadly.  For example, a tow truck operator may be
   considered a responder.

4.6.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.6.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 (".").

4.6.5.5.1.  Name

   urn:emergency:service:responder.police

4.6.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.






Rosen & Abley              Expires 6 July 2025                 [Page 18]

Internet-Draft            Emergency Registries              January 2025


4.6.5.5.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each 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.6.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.6.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 a federal/national level.  The
   "police.federal" registry contains label values appropriate for the
   types of national police responders within an ESInet.  This is
   distinct from the parent subregistry, "police.federal", which
   includes the names for specific federal agencies.  This is 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 ".".

4.6.5.6.1.  Name

   urn:emergency:service:responder.police.federal









Rosen & Abley              Expires 6 July 2025                 [Page 19]

Internet-Draft            Emergency Registries              January 2025


4.6.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.  The short form of
   the entry is often an abbreviation, while the long form is the
   official full agency name.

4.6.5.6.3.  Registration policy

   Expert Review.  No standards document required.  The expert should
   confirm that each entry represents a kind of federal police
   department, considered broadly.  As this is a specific agency,
   entries for different countries may be different.

4.6.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.6.5.7.  "urn:emergency:service:responder.fire" Subregistry

   This registry has a similar purposes as the "responder.police"
   subregistry, except for differentiating among types of fire response
   agencies (for example, "forest" or "private").

4.6.5.7.1.  Name

   urn:emergency:service:responder.fire

4.6.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 6 July 2025                 [Page 20]

Internet-Draft            Emergency Registries              January 2025


4.6.5.7.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a kind of fire
   department, considered broadly.  The names used for various kinds of
   fire departments vary 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.6.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.6.5.8.  "urn:emergency:service:responder.ems" Subregistry

   This registry has a similar purpose as the "responder.police"
   subregistry, except for types of Emergency Medical Service response
   agencies (for example, "Local" or "countyParish").

4.6.5.8.1.  Name

   urn:emergency:service:responder.ems

4.6.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.6.5.8.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each 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 6 July 2025                 [Page 21]

Internet-Draft            Emergency Registries              January 2025


   name is preferred, to match the existing entries.

4.6.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.6.5.9.  "urn:emergency:service:serviceAgencyLocator" Subregistry

   Agencies connected to an ESInet need to communicate with various
   services and public safety agencies.  A service called the Service/
   Agency Locator provides a directory ("white pages") of agencies,
   together with key information about the service or agency.  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 in a LoST query to find a specific service
   at a particular location.

4.6.5.9.1.  Name

   urn:emergency:service:serviceAgencyLocator

4.6.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.6.5.9.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a kind of service
   the Service/Agency Locator holds information for.

4.6.5.9.4.  Content

   This subregistry contains:




Rosen & Abley              Expires 6 July 2025                 [Page 22]

Internet-Draft            Emergency Registries              January 2025


   *  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.6.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 the 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.6.5.10.1.  Name

   urn:emergency:uid

4.6.5.10.2.  Information Needed to Create a New Value

   Name of the entry, a short description and a reference to the
   document that specifies the entry.

4.6.5.10.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of
   identifier, and that the document specifies the structure of that
   identifier.

4.6.5.10.4.  Content

   this registry contains:

   *  The UTF-8 "Name" of the identifier prefix

   *  The UTF-8 "Purpose" of the identifier prefix





Rosen & Abley              Expires 6 July 2025                 [Page 23]

Internet-Draft            Emergency Registries              January 2025


   *  A "Reference" with a URI to the document that requested the
      registry entry.

4.6.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.6.5.11.1.  Name

   urn:emergency:media-feature

4.6.5.11.2.  Information Needed to Create a New Value

   A short tag, purpose description and a reference to the document that
   specifies the entry.

4.6.5.11.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of SIP
   media feature tag and that the document specifies how it is used.

4.6.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.7.  Internal Services Registries

   The following are additional registries used internally in an ESInet:






Rosen & Abley              Expires 6 July 2025                 [Page 24]

Internet-Draft            Emergency Registries              January 2025


4.7.1.  "serviceNames" Registry

   A variety of services are used during the processing of emergency
   calls.  These services are deployed within an ESInet and are
   discoverable using the LoST [RFC5222] protocol or a discovery service
   known as the Service/Agency Locator (SAL).  Standardized query terms
   are needed for both discovery mechanisms to work.  When querying
   LoST, the service URNs in section 4.4.5.1. "urn:emergency:service"
   Subregistry are used.  When querying the SAL, service names from the
   registry defined in this section are used.  IANA is requested to
   create the ServiceNames subregistry in the Emergency Registry.

4.7.1.1.  Name

   serviceNames

4.7.1.2.  Information Needed to Create a New Value

   Short and long names of the service and a reference to the document
   that specifies the service.

4.7.1.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of
   service.

4.7.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.7.2.  "serviceState" Registry

   All services have a common notion of "state" which comes from this
   registry.

4.7.2.1.  Name

   serviceNames





Rosen & Abley              Expires 6 July 2025                 [Page 25]

Internet-Draft            Emergency Registries              January 2025


4.7.2.2.  Information Needed to Create a New Value

   Name and description of the state and a reference to the document
   that specifies it.

4.7.2.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of
   identifier, and that the document specifies the structure of that
   identifier.

4.7.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.7.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.7.3.1.  Name

   elementState

4.7.3.2.  Information Needed to Create a New Value

   Name and description of the state and a reference to the document
   that specifies it.

4.7.3.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new state and the
   specification adequately describes it.




Rosen & Abley              Expires 6 July 2025                 [Page 26]

Internet-Draft            Emergency Registries              January 2025


4.7.3.4.  Content

   This registry contains:

   *  The short "Name" of the element state (e.g., "Normal" or
      "ScheduledMaintenanceDown")

   *  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.7.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.7.4.1.  Name

   SIPHeaderIsOperatorConditions

4.7.4.2.  Information Needed to Create a New Value

   Name and description of the test and a reference to the document that
   specifies it.

4.7.4.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new test and the
   specification adequately describes it.







Rosen & Abley              Expires 6 July 2025                 [Page 27]

Internet-Draft            Emergency Registries              January 2025


4.7.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.

4.7.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.7.5.1.  Name

   queueState

4.7.5.2.  Information Needed to Create a New Value

   Short name and description of the state and a reference to the
   document that specifies it.

4.7.5.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new state and the
   specification adequately describes it.

4.7.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.









Rosen & Abley              Expires 6 July 2025                 [Page 28]

Internet-Draft            Emergency Registries              January 2025


4.7.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.7.6.1.  Name

   securityPosture

4.7.6.2.  Information Needed to Create a New Value

   Name and purpose of the state and a reference to the document that
   specifies it.

4.7.6.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new security
   posture, the value is consistent with the existing values and the
   specification adequately describes it.

4.7.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.7.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.







Rosen & Abley              Expires 6 July 2025                 [Page 29]

Internet-Draft            Emergency Registries              January 2025


4.7.7.1.  Name

   ESRP Notify Event Code

4.7.7.2.  Information Needed to Create a New Value

   Name and description of the code and a reference to the document that
   specifies it.

4.7.7.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new code and the
   specification adequately describes it.

4.7.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.7.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.7.8.1.  Name

   Route Cause

4.7.8.2.  Information Needed to Create a New Value

   Short value, integer code, description of the cause and a reference
   to the document that specifies it.





Rosen & Abley              Expires 6 July 2025                 [Page 30]

Internet-Draft            Emergency Registries              January 2025


4.7.8.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new cause, the
   code is unique and appropriate, and the specification adequately
   describes it.

4.7.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)

   *  A "Reference" (URI) to the document that requests the entry

4.7.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.7.9.1.  Name

   logEvent

4.7.9.2.  Information Needed to Create a New Value

   Name and purpose of the log event and a reference to the document
   that specifies it.

4.7.9.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new log event and
   the specification adequately describes it.

4.7.9.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)



Rosen & Abley              Expires 6 July 2025                 [Page 31]

Internet-Draft            Emergency Registries              January 2025


   *  The ASCII "Purpose" (explanatory text, a string)

   *  A "Reference" (URI) to the document that requests the entry

4.7.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.7.10.1.  Name

   LogEvent Protocol

4.7.10.2.  Information Needed to Create a New Value

   Name a reference to the document that specifies the protocol.

4.7.10.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new protocol and
   the specification is an appropriate definition for the protocol.

4.7.10.4.  Content

   This registry contains:

   *  The ASCII "Name" of the protocol used (a short string)

   *  A "Reference" to the document that requests the entry, such as an
      RFC

4.7.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.7.11.1.  Name

   LogEvent CallType







Rosen & Abley              Expires 6 July 2025                 [Page 32]

Internet-Draft            Emergency Registries              January 2025


4.7.11.2.  Information Needed to Create a New Value

   Name and description of the call type and a reference to the document
   that specifies it and the classification (primary or secondary) of
   the call type.

4.7.11.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new call type, the
   specification adequately describes it and the classification is
   appropriate.

4.7.11.4.  Content

   This registry contains:

   *  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 the document that requests the entry

4.7.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.7.12.1.  Name

   Call States

4.7.12.2.  Information Needed to Create a New Value

   Name and purpose of the state and a reference to the document that
   specifies it.

4.7.12.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new state and the
   specification adequately describes it.




Rosen & Abley              Expires 6 July 2025                 [Page 33]

Internet-Draft            Emergency Registries              January 2025


4.7.12.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)

   *  The ASCII "Purpose" (explanatory text, a string)

   *  A "Reference" (URI) to the document that requests the entry

4.7.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.

4.7.13.1.  Name

   LogEvent Announcement Type

4.7.13.2.  Information Needed to Create a New Value

   Name and purpose of the announcement type and a reference to the
   document that specifies it.

4.7.13.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new announcement
   type and the specification adequately describes it.

4.7.13.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)

   *  The ASCII "Purpose" (explanatory text, a string)

   *  A "Reference" (URI) to the document that requests the entry









Rosen & Abley              Expires 6 July 2025                 [Page 34]

Internet-Draft            Emergency Registries              January 2025


4.7.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.7.14.1.  Name

   non-RTP Media Types

4.7.14.2.  Information Needed to Create a New Value

   Name and description of the media

4.7.14.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of media
   not carried in RTP.

4.7.14.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)

   *  The ASCII "Description" (explanatory text, a string)

4.7.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.7.15.1.  Name

   Agency Roles

4.7.15.2.  Information Needed to Create a New Value

   Name and description of the role






Rosen & Abley              Expires 6 July 2025                 [Page 35]

Internet-Draft            Emergency Registries              January 2025


4.7.15.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of role.

4.7.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.7.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.

4.7.16.1.  Name

   Agent Roles

4.7.16.2.  Information Needed to Create a New Value

   Name and description of the role

4.7.16.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new type of role.

4.7.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.






Rosen & Abley              Expires 6 July 2025                 [Page 36]

Internet-Draft            Emergency Registries              January 2025


4.7.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.7.17.1.  Name

   Status Codes

4.7.17.2.  Information Needed to Create a New Value

   Status code and text used in the response

4.7.17.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new status code,
   the numeric value is appropriate and the specification adequately
   describes its use.

4.7.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.7.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.7.18.1.  Name

   Interface Names

4.7.18.2.  Information Needed to Create a New Value

   Name of the interface




Rosen & Abley              Expires 6 July 2025                 [Page 37]

Internet-Draft            Emergency Registries              January 2025


4.7.18.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new interface.

4.7.18.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.7.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
   enumerates the match types that can be returned.

4.7.19.1.  Name

   Match Type

4.7.19.2.  Information Needed to Create a New Value

   Name of the interface

4.7.19.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new interface.

4.7.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 the document that requests the entry




Rosen & Abley              Expires 6 July 2025                 [Page 38]

Internet-Draft            Emergency Registries              January 2025


4.7.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.7.20.1.  Name

   GIS Layers

4.7.20.2.  Information Needed to Create a New Value

   Full name of the layer and a short version of the name

4.7.20.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new GIS layer.

4.7.20.4.  Content

   This registry contains:

   *  The UTF-8 Full "Name"

   *  The UTF-8 "Layer Indicator"

   *  A "Reference" (URI) to the document that requests the entry

4.7.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.7.21.1.  Name

   Policy Type






Rosen & Abley              Expires 6 July 2025                 [Page 39]

Internet-Draft            Emergency Registries              January 2025


4.7.21.2.  Information Needed to Create a New Value

   Type, format and use of the policy

4.7.21.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new interface.

4.7.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 the document that requests the entry

4.7.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.7.22.1.  Name

   Discrepancy Report Status Token

4.7.22.2.  Information Needed to Create a New Value

   Token, Member Name where token is used, Discrepancy Report where
   token is used.



Rosen & Abley              Expires 6 July 2025                 [Page 40]

Internet-Draft            Emergency Registries              January 2025


4.7.22.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that each entry represents a new interface.

4.7.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

4.7.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.7.23.1.  Name

   Event Package

4.7.23.2.  Information Needed to Create a New Value

   Name of the Event Package

4.7.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.7.23.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)



Rosen & Abley              Expires 6 July 2025                 [Page 41]

Internet-Draft            Emergency Registries              January 2025


   *  A "Reference" (URI) to the document that requests the entry

4.7.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.7.24.1.  Name

   LoggingServiceMediaErrorReasonCodes

4.7.24.2.  Information Needed to Create a New Value

   Name and description of the reason code.

4.7.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.7.24.4.  Content

   This registry contains:

   *  The ASCII "Name" (a short string)

   *  The ASCII "Description" (explanatory text, a string)

   *  A "Reference" (URI) to the document that requests the entry

4.7.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





Rosen & Abley              Expires 6 July 2025                 [Page 42]

Internet-Draft            Emergency Registries              January 2025


4.8.  Emergency Call-Info Purpose Registry

   Emergency calls use a number of Call-Info headers to provide
   information about the call to entities along the call path.  The
   purpose parameter for all of these consists of the string
   "emergency", Section 4.2 followed by a hypen and a member of this
   registry.

4.8.1.  Name

   Emergency Call-Info Purpose

4.8.2.  Information Needed to Create a New Value

   Name of the purpose

4.8.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that the Call-Info purpose parameter use is
   well documented and unique.

4.8.4.  Content

   This registry contains:

   *  An ASCII "Name" (a short string)

   *  A UTF-8 Description (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.  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.9.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.







Rosen & Abley              Expires 6 July 2025                 [Page 43]

Internet-Draft            Emergency Registries              January 2025


4.9.1.1.  Name

   EIDO-AgencyRole

4.9.1.2.  Information Needed to Create a New Value

   Value and description of the role.

4.9.1.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that the the entry represents a new role.

4.9.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 the document that requests the entry

4.9.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.9.2.1.  Name

   EIDO-IncidentType-Common

4.9.2.2.  Information Needed to Create a New Value

   Name and description of the reason code.











Rosen & Abley              Expires 6 July 2025                 [Page 44]

Internet-Draft            Emergency Registries              January 2025


4.9.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.

4.9.2.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.9.3.1.  Name

   EIDO-IncidentStatus-Common

4.9.3.2.  Information Needed to Create a New Value

   Name and description of the staus code.

4.9.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.9.3.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)




Rosen & Abley              Expires 6 July 2025                 [Page 45]

Internet-Draft            Emergency Registries              January 2025


   *  A "Reference" (URI) to the document that requests the entry

4.9.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

4.9.4.1.  Name

   EIDO-ReportNumberType

4.9.4.2.  Information Needed to Create a New Value

   Name and description of the type.

4.9.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.9.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 the document that requests the entry

4.9.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.



Rosen & Abley              Expires 6 July 2025                 [Page 46]

Internet-Draft            Emergency Registries              January 2025


4.9.5.1.  Name

   EIDO-CommonDispositionCode

4.9.5.2.  Information Needed to Create a New Value

   Name and description of the disposition code.

4.9.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.9.5.4.  Content

   This registry contains:

   *  The 2 or 3 digit integer code

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.9.6.1.  Name

   EIDO-PersonRole

4.9.6.2.  Information Needed to Create a New Value

   Name and description of the role.

4.9.6.3.  Registration policy

   Specification Required [RFC8126], which requires expert review.  The
   expert should confirm that the the entry represents a new role.




Rosen & Abley              Expires 6 July 2025                 [Page 47]

Internet-Draft            Emergency Registries              January 2025


4.9.6.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.9.7.1.  Name

   EIDO-VehicleRelationshipType

4.9.7.2.  Information Needed to Create a New Value

   Name and description of the relationship type.

4.9.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.9.7.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.




Rosen & Abley              Expires 6 July 2025                 [Page 48]

Internet-Draft            Emergency Registries              January 2025


4.9.8.1.  Name

   EIDO-LocationType

4.9.8.2.  Information Needed to Create a New Value

   Name and description of the relationship type.

4.9.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.9.8.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.9.10 for the latter information.

4.9.9.1.  Name

   EIDO-PrimaryUnitStatus-Common

4.9.9.2.  Information Needed to Create a New Value

   Name and description of the status code.

4.9.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.





Rosen & Abley              Expires 6 July 2025                 [Page 49]

Internet-Draft            Emergency Registries              January 2025


4.9.9.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.9.10.1.  Name

   EIDO-SecondaryUnitStatus-Common

4.9.10.2.  Information Needed to Create a New Value

   Name and description of the status.

4.9.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.9.10.4.  Content

   This registry contains:

   *  The ASCII "Value" (a short string)

   *  The ASCII "Literal Description" (a short string)

   *  A "Reference" (URI) to the document that requests the entry

4.9.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.





Rosen & Abley              Expires 6 July 2025                 [Page 50]

Internet-Draft            Emergency Registries              January 2025


4.9.11.1.  Name

   EIDO-EmergencyResourceType-Common

4.9.11.2.  Information Needed to Create a New Value

   Name and description of the resource type.

4.9.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.9.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 the document that requests the entry

4.9.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.9.12.1.  Name

   EIDO-ResourceAttribute

4.9.12.2.  Information Needed to Create a New Value

   Name and description of the resource attribute.

4.9.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.






Rosen & Abley              Expires 6 July 2025                 [Page 51]

Internet-Draft            Emergency Registries              January 2025


4.9.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 the document that requests the entry

4.9.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.9.13.1.  Name

   EIDO-Resource Attribute

4.9.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.9.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.9.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



Rosen & Abley              Expires 6 July 2025                 [Page 52]

Internet-Draft            Emergency Registries              January 2025


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.

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", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, 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>.





Rosen & Abley              Expires 6 July 2025                 [Page 53]

Internet-Draft            Emergency Registries              January 2025


   [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>.

   [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", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.




Rosen & Abley              Expires 6 July 2025                 [Page 54]

Internet-Draft            Emergency Registries              January 2025


   [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

   Brian Rosen
   Unaffiliated
   Mars, PA
   United States of America
   Email: br@brianrosen.net


   Brandon Abley
   NENA
   Alexandria, VA
   United States of America
   Email: babley@nena.org




























Rosen & Abley              Expires 6 July 2025                 [Page 55]