Emergency RegistriesUnaffiliatedMarsPAUSbr@brianrosen.netNENAAlexandriaVAUSbabley@nena.org
ART
ecritMultiple emergency services standards organizations are developing standards based on IETF emergency call standards and other IETF protocols. There is a desire among these organizations to use common registries not tied to a particular country or national Standards Development Organization (SDO), in the long term pursuit of a single worldwide standard. This document asks IANA to create a set of registries and provides processes for expanding the set and populating them.Introduction
establishes a framework for carrying emergency calls over the Internet using the SIP (
) protocol. Various regional organizations are developing standards for how calls conforming to this framework are handled within the Emergency Services IP Networks (ESInets) established by local, regional or national authorities to handle such calls and deliver them to the appropriate Public Safety Answering Point (PSAP). Many of these standards have needed registries of values used in the protocols and services the services define. Prior to this document, such registries were managed by the regional SDOs themselves. There is a desire among many of the regional emergency services SDOs to have a single world-wide standard for handling emergency calls and as part of that effort, a single set of registries managed by a neutral party. This document requests IANA to establish a new registry area called "Emergency" and to create a set of registries within that area. This document does not describe initial contents of the registries, with some exceptions. The registries will be populated by requests from the regional SDOs, including The NENA i3 Standard.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119
.
AcknowledgementsThanks 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.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 .
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 ().
IANA ConsiderationsThis 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. SIP Reason Protocols
IANA is requested to add the value "emergency" to the SIP Protocols Registry ().Protocol Value"emergency"Protocol Cause"Emergency call processing"ReferenceThis document, and ()."emergency" URN namespaceIANA is requested to register a new URN namespace for "emergency".Namespace IdentifieremergencyVersion1DateRFC Editor: please insert the date this RFC was publishedRegistrantIETF 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.PurposeThis namespace is used for unique identifiers for use in emergency services, including emergency calls. Most uses for these identifiers will be within private "Emergency Services IP Networks" (ESInets), some use in the public Internet is expected. These identifiers will be used in several countries, and hopefully, eventually, worldwide for handling of emergency calls and incidents. Prior to this document, North American emergency services used the "nena" nid, defined in . Most identifiers in urn:nena will be replaced by identifiers in urn:emergency in pursuit of a single worldwide standard set for emergency services which are not controlled by a single public safety organization like NENA. Identifiers with this nid do not require resolution. Identifiers in this nid will primarily specified in public safety standards SDOs, but some IETF standards may use or define them. SyntaxThe 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 <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.localThere are no special encoding rules for identifiers in urn:emergency. URN equivalence is non-case sensitive. Hyphens are not expected in these identifiers, but if used, they are significant in comparisons. Quotes are not allowed in this nid. There are no special considerations for conforming to URN syntax. Percent encoding is permitted. There are no uses for q-components or f-components in this namespace.AssignmentAssignment of top level classes is by standards documents, both standards-track RFCs and standards documents in other SDOs. See . Assignments within top level classes are defined in the document that defines the class. Such documents MUST specify how uniqueness within the class is achieved.Security and PrivacyEach top level class, in its defining document, MUST describe the security and privacy considerations of that class. In general, there are no special security considerations for these identifiers. Several top level classes are defined in this document. In some circumstances, these identifiers may indicate what kind of agency is involved with a public safety incident, and some may identify a specific agency. Encryption of the communications that contain the identifier in classes defined in this document is REQUIRED and MUST be TLS or an equally secure protocol. InteroperabilityMany of the identifiers in urn:emergency are similar in construction and use as identifiers originally defined in urn:nena. Backwards compatibility with those identifiers MUST be specified in the documents that use them. NENA STA-010.3-2021 is the primary document that has this backwards compatibility requirement, as it defined most of the identifiers in urn:nena. There are no other interoperability issues.ResolutionNo resolution of these identifiers is defined."Emergency" AreaIANA is requested to establish the registries within this section under the "Emergency" area. These registries contain enumerated values used for various aspects of emergency calling and call handling. New registries or subregistrues in the "Emergency" area require a standards document, which MAY be a standards track RFC, but also MAY be a defined in a document from a recognized standards organization that promulgates emergency services standards. Where a new registry or subregistry is defined in an external standards organization, an expert SHALL review the document to ascertain that it is relevant to the "Emergency" area, that the organization defining the registry is a recognized standards organization, that the document clearly articulates the management method for the regisry, which MUST be substantially similar to one or more of the management methods in , 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 required to implement the NENA i3 Standard for Next-Generation 9-1-1 as well as the NENA Standard for Emergency Incident Data Object. These standards, unless otherwise specified, will initially populate the registries created by this document. Some registries previously existed in the NENA Registry System, but the intent of international SDOs is to maintain next-generation emergency calling registries under IANA in the future. will be maintained only for backwards compatibility, and for registries required only for North America.Emergency Call Additional Data RegistryIANA is requested to move the Emergency Call Additional Data registry and its sub-registries to the Emergency Area."urn:emergency" registryIANA is requested to create a registry for the emergency nid top level classes in the Emergency Area.Nameurn:emergencyInformation Needed to Create a New ValueName of the top level class, a short description and a reference to a document that defines it.Registration policySpecification Required , 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 .ContentThis 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
Subregistries for top level classes of urn:emergencyIn most cases, top level classes of urn:emergency will define subregistries. Several levels of subregistries may be needed. The document that defines the class MUST define the subregistry if needed. IETF and emergency service standards organizations MAY define subregistries of urn:nena. Instructions to IANA for the subregistry MUST conform to . 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."urn:emergency:service" SubregistryIANA is requested to create a subregistry for "urn:emergency:service" under "urn:emergency".When calls are routed within an Emergency Services IP Network (ESInet), the routing element queries a LoST server for the (nominal) route. It does so with a service URN. Esternal routing is accomplished with "urn:service:sos", as defined by . Within an ESInet, values under this registry are used.Service URNs as defined here begin with “urn:emergency:service”. The sub-namespace defined by this registry MAY be further subdivided (potentially several times), by sub-registries under this sub-registry. The separator between urn:emergency:service and the entry in the subregistry is a colon (":"). A new entry starting with “urn:emergency:service” SHOULD denote a new type of route, which MUST be distinguished by the LoST server from other uses. For example, emergency calls being routed within the ESInet use “urn:emergency:service:sos” (or a subspace of it). Calls routed by a PSAP to a responder use “urn:emergency:service:responder” (the type of responder is also included, e.g., “urn:emergency:service:responder.police”). A client specifies the URN in a LoST query, and the LoST Server uses it to choose a (nominal) route.Nameurn:emergency:serviceInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that defines it.Registration policySpecification Required , which requires expert review. The specification MUST be from the IETF or a recognized standards organization that creates standards for emergency services. The expert must confirm the requested entry is appropriate for emergency services, if the registering organization is not the IETF, that it is an appropriate organization to define the entry, that the purpose adequately describes the new entry and the reference leads to a document that clearly describes the use of the entry. Also see .ContentThis 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
"urn:emergency:service:sos" SubregistryIANA is requested to creates a subregistry for "urn:emergency:service:sos" under "urn:emergency:service".Routing of emergency calls within the ESInet is a primary function of systems that process such calls. When routing entities must route calls within the ESInet, they query the LoST Server for the route. Routing for emergency calls may involve multiple levels of routing entities. Each level may need a different URN to be distinguishable. Routing of emergency calls, including instant messages and non-interactive calls within an ESInet, is accomplished with a URN beginning with “urn:emergency:service:sos”. The “urn:emergency:service:sos” registry contains values appropriate for the various levels of routing within the ESInet. The separator between urn:emergency:service:sos and an entry in the subregistry is a colon (":").Nameurn:emergency:service:sosInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that defines it.Registration policySpecification Required , 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 .ContentThis 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
"urn:emergency:service:test" RegistryIANA is requested to creates a subregistry for "urn:emergency:service:test" under "urn:emergency:service".Test calls are directed to “urn:service:test.sos”. To route such test calls where the routing infrastructure uses multiple levels of routing, and thus uses URNs in the “urn:emergency:service:sos” registry, service URNs are needed for test calls with similar levels. IANA is requested to create an entry in the “urn:emergency:service” registry with the name “test” and with the purpose noted as “routing test calls within the ESInet toward a primary PSAP”. The reference will be to the registry created by this section, “urn:emergency:service:test”. The separator between the “test” label and the service (“urn:emergency:service:test” registry entry) is a period “.”. The “urn:emergency:service:test” registry contains label values corresponding to the levels in the “urn:emergency:service:sos” 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.Nameurn:emergency:service:testInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that defines it.Registration policySpecification Required , 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.ContentThe content of this registry should mirror the content of urn:service:test:sos except with the "test" label as described above."urn:emergency:service:responder" RegistryIANA is requested to create the "urn:emergency:service:responder" subregistry under "urn:emergency:service"Once a PSAP gets a call, they may have to transfer the call to a secondary PSAP. The secondary PSAP is chosen based on the type of responder, and the location of the caller. Routing of emergency calls from a PSAP towards a responder is accomplished with a URN beginning with “urn:emergency:service:responder”. IANA is requested to create an entry in the “urn:emergency:service” registry with the name “responder” and with the purpose noted as “routing emergency calls within the ESInet towards a responder”. The reference will be to the registry created by this section, “urn:emergency:service:responder”.The “urn:emergency:service:responder” registry contains label values appropriate for the types of responders within the ESInet. The separator between the “responder” label and the type of responder (“urn:emergency:service:responder” registry value) is a period “.”. This registry is also used in other contexts where an agency type is 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.Nameurn:emergency:service:responderInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that defines it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a kind of responder, considered broadly. For example, a tow truck operator may be considered a responder.ContentThis 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
"urn:emergency:service:responder.police" SubregistryThere 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 (".").Nameurn:emergency:service:responder.policeInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that defines it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a kind of police department, considered broadly. The names used for various kinds of police departments varies from country to country. The expert is requested to try to minimize the number of entries in the registry, but is not expected to have to learn the details of how police forces are organized in any country. An English name is preferred, to match the existing entries.ContentThis 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"police.federal" SubregistryThere are several federal police agencies. This registry is a subregistry of “urn:emergency:service:responder.police.” and lists each police agency operating at the federal/national level. The “federal.police” registry contains label values appropriate for the types of national police responders within the ESInet. This is distinct from the parent subregistry, "police.federal", is the police.federal subregistry includes the names for specific federal agencies, as opposed to the "responder.police" subregistry which indicated the agency TYPE (police). The separator between the “police.federal” label and the type of responder (“urn:emergency:service:responder.police.federal” registry value) is a period “.”.Nameurn:emergency:service:responder.police.federalInformation Needed to Create a New ValueShort and long forms of the entry and a reference to a document that defines it or a person that requested the entry.Registration policyExpert Review. No standards document required. The expert should confirm that entry represents a kind of federal police department, considered broadly. As this is a specific agency, entries for different countries may be different.ContentThis 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."urn:emergency:service:responder.fire" SubregistryThis registry has similar purposes as the "responder.police" subregistry, except for types of fire response agencies (for example, "forest" or "private").Nameurn:emergency:service:responder.fireInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that specifies the entry.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a kind of fire department, considered broadly. The names used for various kinds of fire departments varies from country to country. The expert is requested to try to minimize the number of entries in the registry, but is not expected to have to learn the details of how fire departments are organized in any country. An English name is preferred, to match the existing entries.ContentThis 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"urn:emergency:service:responder.ems" SubregistryThis registry has similar purposes as the "responder.police" subregistry, except for types of Emergency Medical Service response agencies (for example, "Local" or "countyParish").Nameurn:emergency:service:responder.emsInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that specifies the entry.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a kind of emergency medical service, considered broadly. The names used for various kinds of emergency medical services varies from country to country. The expert is requested to try to minimize the number of entries in the registry, but is not expected to have to learn the details of how emergency medical services are organized in any country. An English name is preferred, to match the existing entries.ContentThis 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"urn:emergency:service:serviceAgencyLocator" Subregistry
The ESInet will connect to many services and public safety agencies. A directory (“white pages” and “yellow pages”) of agencies, together with key information about the service or agency, is the function of the Service/Agency Locator. The Service/Agency Locator is a distributed database. There are several mechanisms by which the Service/Agency Locator can be searched to locate a specific service or agency. When searching for a service by location, the LoST protocol ( is used, which accepts a URN that specifies the service being searched by location. This registry provides urns to be used witha LoST query to find that service at a particular location.
Nameurn:emergency:service:serviceAgencyLocatorInformation Needed to Create a New ValueShort and long versions of the service and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a kind of service the Service/Agency Locator holds information for.Content
This subregistry contains:
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.
"urn:emergency:uid" RegistryVarious entities need to create globally unique identifiers. A simple way to do that is to combine a locally unique identifier and a domain name (which is globally unique). However, many entities need to create more than one type of globally unique identifier and knowing what type of identifier is helpful in diagnosing problems. For this purpose, the uid URN subregistry creates unique strings used to prepend identifiers that indicate the type of identifier it is.This document does not describe the structure of the identifier beyond the urn:emergency:uid prefix and the value in this registry. The defining specification MUST describe the structure of the identifier.Nameurn:emergency:uidInformation Needed to Create a New ValueName of the entry, a short description and a reference to a document that specifies the entry.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of identifier, and specifies the structure of that identifier.Contentthis registry contains:
The UTF-8 "Name" of the identifier prefix
The UTF-8 "Purpose" of the identifier prefix
A "Reference" with a URI to the document that requested the registry entry.
"urn:emergency:media-feature" RegistrySIP Media Feature tags as defined in 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 (":").
Nameurn:emergency:media-featureInformation Needed to Create a New ValueA short tag, purpose description and a reference to a document that specifies the entry.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of SIP media feature tag and specifies how it is used.ContentThis registry contains:
A short ASCII "Tag"
A long ASCII "Purpose"
A "Reference" with a URI to the document that requested the registry entry.
Internal Services RegistriesThe following are additional registries used internally in an ESInet:"serviceNames" RegistryProcessing of emergency calls uses a variety of services which are queried either using SIP or HTTP. These services are discoverable through the ESInet that has deployed an instance of these services. In order to faciliate interoperability there is need to codify their names in a registry. IANA is requested creates the ServiceNames registry in the Emergency Area.NameserviceNamesInformation Needed to Create a New ValueShort and long names of the service and a reference to a document that specifies the service.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of service.ContentThis 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.
"serviceState" RegistryAll services have a common notion of "state" which comes from this registry. NameserviceNamesInformation Needed to Create a New ValueName and description of the state and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of identifier, and specifies the structure of that identifier.ContentThis 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.
"elementState" RegistryServices 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.NameelementStateInformation Needed to Create a New ValueName and description of the state and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new state and the specification adequately describes it.ContentThis 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.
"SIPHeaderIsOperatorConditions" RegistrySome 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.NameSIPHeaderIsOperatorConditionsInformation Needed to Create a New ValueName and description of the test and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new test and the specification adequately describes it.ContentThis 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.
"queueState" RegistryIn 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.NamequeueStateInformation Needed to Create a New ValueShort name and description of the state and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new state and the specification adequately describes it.ContentThis registry contains:
A short ASCII "Name"
The long ASCII "Description"
A "Reference" with a URI to the document that requested the registry entry.
"securityPosture" RegistryEmergency 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.NamesecurityPostureInformation Needed to Create a New ValueName and purpose of the state and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new security posture, the value is consistent with the existing values and the specification adequately describes it.ContentThis registry contains:
A short ASCII "Value"
The long ASCII "Purpose"
A "Reference" with a URI to the document that requested the registry entry.
"ESRP Notify Event Code" RegistryAn 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.NameESRP Notify Event CodeInformation Needed to Create a New ValueName and description of the code and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new code and the specification adequately describes it.ContentThis registry contains:
A short ASCII "Name"
The long ASCII "Description"
A "Reference" with a URI to the document that requested the registry entry.
"Route Cause" RegistryThe 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.NameRoute CauseInformation Needed to Create a New ValueShort value, integer code, description of the cause and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new cause, the code is unique and appropriate, and the specification adequately describes it.ContentThis 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 a document that requests the entry
"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.NamelogEventInformation Needed to Create a New ValueName and purpose of the log event and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new log event and the specification adequately describes it.ContentThis registry contains:
The ASCII "Name" (a short string)
The ASCII "Purpose" (explanatory text, a string)
A "Reference" (URI) to a document that requests the entry
"LogEvent Protocol" RegistryIn 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.NameLogEvent ProtocolInformation Needed to Create a New ValueName a reference to a document that specifies the protocol.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new protocol and the specification is an appropriate definition for the protocol.ContentThis registry contains:
The ASCII "Name" of the protocol used (a short string)
A "Reference" to a document that requests the entry, such as an RFC
"LogEvent CallTypes" RegistryThe 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.NameLogEvent CallTypeInformation Needed to Create a New ValueName and description of the call type and a reference to a document that specifies it and the classification (primary or secondary) of the call type.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new call type, the specification adequately describes it and the classification is appropriate.ContentThis 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 a document that requests the entry
"Call States" RegistryThe 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.NameCall StatesInformation Needed to Create a New ValueName and purpose of the state and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new state and the specification adequately describes it.ContentThis registry contains:
The ASCII "Name" (a short string)
The ASCII "Purpose" (explanatory text, a string)
A "Reference" (URI) to a document that requests the entry
"LogEvent Announcement Types" RegistryIn 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.NameLogEvent Announcement TypeInformation Needed to Create a New ValueName and purpose of the announcement type and a reference to a document that specifies it.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new announcement type and the specification adequately describes it.ContentThis registry contains:
The ASCII "Name" (a short string)
The ASCII "Purpose" (explanatory text, a string)
A "Reference" (URI) to a document that requests the entry
"non-RTP Media Types" RegistryMost media in an emergency calls uses Real Time Transport Protocol (RTP), . 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.Namenon-RTP Media TypesInformation Needed to Create a New ValueName and description of the mediaRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of media not carried in RTP.ContentThis registry contains:
The ASCII "Name" (a short string)
The ASCII "Description" (explanatory text, a string)
"Agency Roles" RegistryIn 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.NameAgency RolesInformation Needed to Create a New ValueName and description of the roleRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of role.ContentThis 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.
"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.NameAgent RolesInformation Needed to Create a New ValueName and description of the roleRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new type of role.ContentThis 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.
"Status Codes" RegistryInterfaces 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.NameStatus CodesInformation Needed to Create a New ValueStatus code and text used in the responseRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new status code, the numeric value is appropriate and the specification adequately describes its use.ContentThis 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.
"Interface Names" RegistryEmergency 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.NameInterface NamesInformation Needed to Create a New ValueName of the interfaceRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new interface.ContentThis registry contains:
The ASCII "Name" (a short string)
A "Reference" (URI) to a document that requests the entry
"Match Type" RegistryWhen using the LoST protocol 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.NameMatch TypeInformation Needed to Create a New ValueName of the interfaceRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new interface.ContentThis registry contains:
The UTF-8 "Token" (a short string) (e.g., "Road Centerline" or "Hybrid").
The ASCII "Description" (explanatory text, a string)
A "Reference" (URI) to a document that requests the entry
"GIS Layers" RegistryA 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.
NameGIS LayersInformation Needed to Create a New ValueFull name of the layer and a short version of the nameRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new GIS layer.ContentThis registry contains:
The UTF-8 Full "Name"
The UTF-8 "Layer Indicator"
A "Reference" (URI) to a document that requests the entry
"Policy Type" RegistryPolicy 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.NamePolicy TypeInformation Needed to Create a New ValueType, format and use of the policyRegistration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new interface.ContentThis registry contains:
The UTF-8 "Type" of the policy (a short string) (e.g., "LoST")
The UTF-8 "Format" of the policy (e.g., "XACML")
The UTF-8 "Use" of the policy (e.g., "Access rights for Spatial Interface")
A "Reference" (URI) to a document that requests the entry
"Discrepancy Report Status Token" RegistryErrors 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.NameDiscrepancy Report Status TokenInformation Needed to Create a New ValueToken, Member Name where token is used, Discrepancy Report where token is used.Registration policySpecification Required , which requires expert review. The expert should confirm that entry represents a new interface.ContentThis 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
"Event Package" RegistrySIP Event Package registration procedures are defined in 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. NameEvent PackageInformation Needed to Create a New ValueName of the Event PackageRegistration policySpecification Required , which requires expert review. The expert should confirm that the event package is documented roughly similar to SIP Event Package registration requirements in .ContentThis registry contains:
The ASCII "Name" (a short string)
A "Reference" (URI) to a document that requests the entry
"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.NameLoggingServiceMediaErrorReasonCodesInformation Needed to Create a New ValueName and description of the reason code.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new reason for media failure.ContentThis registry contains:
The ASCII "Name" (a short string)
The ASCII "Description" (explanatory text, a string)
A "Reference" (URI) to a document that requests the entry
Initial Values
Initial Values
Name
Description
Reference
lostConnection
The connection to the SRS was lost and could not be re-established
This document
dropOuts
There were significant number of missing media packets
This document
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-AgencyRole" RegistryThe 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.NameEIDO-AgencyRoleInformation Needed to Create a New ValueValue and description of the role.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new role.ContentThis registry contains:
The UTF-8 "Value" (a short string)
The UTF-8 "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-IncidentType-Common" RegistryWhen 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 (), but there is no registry of codes. This registry forms the complete listing of common type codes.NameEIDO-IncidentType-CommonInformation Needed to Create a New ValueName and description of the reason code.Registration policySpecification Required , 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.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-IncidentStatus-Common" RegistryWhen 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.NameEIDO-IncidentStatus-CommonInformation Needed to Create a New ValueName and description of the staus code.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new incident status.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-ReportNumberType" RegistryUsed 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
NameEIDO-ReportNumberTypeInformation Needed to Create a New ValueName and description of the type.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new report number type.ContentThis registry contains:
The UTF-8 "Value" (a short string)
The UTF-8 "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"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 and implemented by .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.NameEIDO-CommonDispositionCodeInformation Needed to Create a New ValueName and description of the disposition code.Registration policySpecification Required , 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.ContentThis registry contains:
The 2 or 3 digit integer code
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"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.NameEIDO-PersonRoleInformation Needed to Create a New ValueName and description of the role.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new role.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"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.
NameEIDO-VehicleRelationshipTypeInformation Needed to Create a New ValueName and description of the relationship type.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new relationship type.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-LocationType" RegistryA 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.NameEIDO-LocationTypeInformation Needed to Create a New ValueName and description of the relationship type.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new relationship type.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-PrimaryUnitStatus-Common" RegistryA 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 for the latter information.NameEIDO-PrimaryUnitStatus-CommonInformation Needed to Create a New ValueName and description of the status code.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new primary unit status.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-SecondaryUnitStatus-Common" RegistryStatuses that further qualifies the Primary Unit Status by providing more detail about the associated primary status. This registry enumerates the allowed secondary status values.NameEIDO-SecondaryUnitStatus-CommonInformation Needed to Create a New ValueName and description of the status.Registration policySpecification Required , which requires expert review. The expert should confirm that the the entry represents a new secondary unit status.ContentThis registry contains:
The ASCII "Value" (a short string)
The ASCII "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"EIDO-EmergencyResourceType-Common" RegistryA 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.NameEIDO-EmergencyResourceType-CommonInformation Needed to Create a New ValueName and description of the resource type.Registration policyFirst 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.ContentThis registry contains:
The UTF-8 "Value" (a short string)
The UTF-8 "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"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.
NameEIDO-ResourceAttributeInformation Needed to Create a New ValueName and description of the resource attribute.Registration policyExpert 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.ContentThis registry contains:
The UTF-8 "Value" (a short string)
The UTF-8 "Literal Description" (a short string)
A "Reference" (URI) to a document that requests the entry
"eidoExtensionId" RegistryVendors 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.NameEIDO-Resource AttributeInformation Needed to Create a New ValueOwner, 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.Registration policyExpert 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.ContentThis 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
Security ConsiderationsThis 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.ReferencesNormative ReferencesNENA Standard for Emergency Incident Data Object (Public Review Draft)NENA: the 9-1-1 Association
APCO 2.103.2-2019 Public Safety Communications Common Incident Types for Data Exchange
Association of Public Safety Communications Officials International
APCO ANS 1.111.2-2018 Public Safety Communications Common Disposition Codes for Data Exchange
Association of Public Safety Communications Officials InternationalNENA i3 Standard for Next-Generation 9-1-1, Version 3 ("i3 Version 3")NENA: the 9-1-1 AssociationInformative References
EENA NG112 Project
European Emergency Number Association
Session Initiation Protocol (SIP) Parameters, Reason Parameters
Internet Assigned Numbers Authority
NENA Registry System
NENA: the 9-1-1 Association