A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
updated by
- rfc-7163 — URN for Country-Specific Emergency Services
Extracted elements (18)
A special domain approach (e.g., sip:[email protected]) was rejected because it would require a single global emergency services proxy, which has undesirable scaling and administrative properties.
Service URN labels are hierarchical so that sub-service identifiers can be removed right-to-left and the resulting URN remains valid, referring to a more generic service. This allows implementations to fall back gracefully when a specific sub-service is not recognized.
The service URN does not prescribe a particular resolution mechanism. A Location-to-Service Translation Protocol (LoST) is expected to be used for mapping service URNs to URLs based on geographic location, but multiple resolution protocols may coexist for different services.
The sip:sos@domain approach was rejected because it overloads the user part of the URI with specific semantics, makes outbound proxy routing a special case inconsistent with normal SIP request-URI handling, is SIP-specific, and does not extend readily to other services.
The tel:NNN;context=+C approach was rejected because proxies would need to know all number-context combinations worldwide and track changes; also, many emergency numbers double as non-emergency numbers in other countries (e.g., 00 in Paraguay is also the US international operator prefix).
Since service URNs are not routable, a SIP proxy or user agent must translate the service URN into a routable URI (e.g., a SIP URL) for a location-appropriate service provider before routing the request.
The translation of service dial strings or service numbers to service URNs in the end host is outside the scope of this document and may be many-to-one; for example, both a home country and visited country emergency number could map to urn:service:sos.
All top-level service names MUST NOT exceed 27 characters, to allow use within the constraints of S-NAPTR (RFC 3958).
Service URN labels MUST be specified in all lower-case, though comparison is case-insensitive string equality.
Service URNs MUST be unique for each unique service; uniqueness is guaranteed through the IANA registration process described in Section 4.
The policy for assigning labels to sub-services may differ for each top-level service designation and MUST be defined by the document describing the top-level service.
The services described by the URN are meant to be well-known, so privacy considerations do not apply to the URN itself. There are likely no specific privacy issues when including a service URN on a web page.
The 'counseling' top-level service identifies services where callers receive advice and support, often anonymous, not requiring emergency response. Sub-services include counseling.children, counseling.mental-health, and counseling.suicide.
The 'service' URN namespace uses a hierarchical identifier with dot-separated labels, where the leftmost label is the top-level service and labels to the right are sub-services. The ABNF syntax is: service-URN = 'URN:service:' service; service = top-level *('.' sub-service). Labels are case-insensitive but MUST be specified in all lower-case.
The 'sos' top-level service identifies emergency services requiring immediate response. Sub-services defined include sos.ambulance, sos.animal-control, sos.fire, sos.gas, sos.marine, sos.mountain, sos.physician, sos.poison, and sos.police.
This document creates the IANA 'Service URN Labels' registry. Top-level service labels require Standards Action; sub-service label policies are defined per top-level service. Initial entries include 'sos' (emergency services) and 'counseling' with their respective sub-services.
Carrying a service URN in a signaling protocol can expose to attackers the kind of service desired by the caller, making it easier to automatically identify all calls for emergency services or directory assistance. Protocol-specific security mechanisms must be implemented for protocols carrying service URNs.
The mapping protocol used to resolve service URNs needs to address a number of threats as detailed in RFC 5069, which also discusses security considerations related to use of the service URN for emergency services.