RFC5031
Network Working Group H. Schulzrinne Request for Comments: 5031 Columbia U. Category: Standards Track January 2008
A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines.
Contents
Introduction
In existing telecommunications systems, there are many well-known communication and information services that are offered by loosely coordinated entities across a large geographic region, with well- known identifiers. Some of the services are operated by governments or regulated monopolies, others by competing commercial enterprises. Examples include emergency services (reached by dialing 9-1-1 in North America, 1-1-2 in Europe), community services and volunteer opportunities (2-1-1 in some regions of the United States), telephone directory and repair services (4-1-1 and 6-1-1 in the United States and Canada), government information services (3-1-1 in some cities in the United States), lawyer referral services (1-800-LAWYER), car roadside assistance (automobile clubs), and pizza delivery services. Unfortunately, almost all of them are limited in scope to a single country or possibly a group of countries, such as those belonging to the North American Numbering Plan or the European Union. The same identifiers are often used for other purposes outside that region, making access to such services difficult when users travel or use devices produced outside their home country.
These services are characterized by long-term stability of user- visible identifiers, decentralized administration of the underlying service, and a well-defined resolution or mapping mechanism. For example, there is no national coordination or call center for "9-1-1" in the United States; rather, various local government organizations cooperate to provide this service based on jurisdictions.
In this document, we propose a URN namespace that, together with resolution protocols beyond the scope of this document, allows us to define such global, well-known services, while distributing the actual implementation across a large number of service-providing entities. There are many ways to divide provision of such services, such as dividing responsibility by geographic region or by the service provider a user chooses. In addition, users can choose different mapping service providers that in turn manage how geographic locations are mapped to service providers.
Availability of such service identifiers allows end systems to convey information about the desired service to other network entities. For example, an IP phone could have a special set of short cuts, address book entries, or buttons that invoke emergency services. When such a service identifier is put into the outgoing Session Initiation Protocol (SIP) RFC3261 message, it allows SIP proxies to unambiguously take actions, as it would not be practical to configure them with dial strings and emergency numbers used throughout the world. Hence, such service identifiers make it possible to delegate routing decisions to third parties and to mark certain requests as
having special characteristics while preventing these characteristics from being accidentally invoked.
This URN identifies services independent of the particular protocol that is used to request or deliver the service. The URN may appear in protocols that allow general URIs, such as the SIP RFC3261 request URIs, web pages, or mapping protocols.
The service URN is a protocol element and is generally not expected to be visible to humans. For example, it is expected that callers will still dial the emergency number '9-1-1' in the United States to reach emergency services. In some other cases, speed dial buttons might identify the service, as is common practice on hotel phones today. (Speed dial buttons for summoning emergency help are considered inappropriate by most emergency services professionals, at least for mobile devices, as they are too prone to being triggered accidentally.)
The translation of service dial strings or service numbers to service URNs in the end host is beyond the scope of this document. These translations likely depend on the location of the caller and may be many-to-one, i.e., several service numbers may map to one service URN. For example, a phone for a traveler could recognize the emergency service number for both the traveler's home location and the traveler's visited location, mapping both to the same universal service URN, urn:service:sos.
Since service URNs are not routable, a SIP proxy or user agent has to translate the service URN into a routable URI for a location- appropriate service provider, such as a SIP URL. A Location-to- Service Translation Protocol (LoST) [LOST] is expected to be used as a resolution system for mapping service URNs to URLs based on geographic location. In the future, there may be several such protocols, possibly different ones for different services.
Services are described by top-level service type, and may contain a hierarchy of sub-services that further describe the service, as outlined in Section 3.
We discuss alternative approaches for creating service identifiers, and why they are unsatisfactory, in Appendix A.
Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 RFC2119.
Terminology specific to emergency services is defined in RFC5012.
Registration Template
Below, we include the registration template for the URN scheme according to RFC 3406 RFC3406.
Namespace ID: service
Registration Information:
Registration version: 1
Registration date: 2006-04-02
Declared registrant of the namespace:
Registering organization: IETF
Designated contact: Henning Schulzrinne
Designated contact email: [email protected]
Declaration of syntactic structure: The URN consists of a
hierarchical service identifier, with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level service', while names to the right are called 'sub-services'. The set of allowable characters is the same as that for domain names RFC1123 and a subset of the labels allowed in RFC3958. Labels are case-insensitive, but MUST be specified in all lower-case. For any given service URN, service- identifiers can be removed right-to-left; the resulting URN is still valid, referring to a more generic service. In other words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs. The ABNF RFC4234 is shown below.
service-URN = "URN:service:" service service = top-level *("." sub-service) top-level = let-dig [ *25let-dig-hyp let-dig ] sub-service = let-dig [ *let-dig-hyp let-dig ] let-dig-hyp = let-dig / "-" let-dig = ALPHA / DIGIT ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9
Relevant ancillary documentation: None
Community considerations: The service URN is believed to be relevant
to a large cross-section of Internet users, including both technical and non-technical users, on a variety of devices, but particularly for mobile and nomadic users. The service URN will allow Internet users needing services to identify the service by kind, without having to determine manually who provides the particular service in the user's current context, e.g., at the user's current location. For example, travelers will be able to use their mobile devices to request emergency services without having to know the emergency dial string of the visited country. The assignment of identifiers is described in the IANA Considerations (Section 4). The service URN does not prescribe a particular resolution mechanism, but it is assumed that a number of different entities could operate and offer such mechanisms.
Namespace considerations: There do not appear to be other URN
namespaces that serve the same need of uniquely identifying widely-available communication and information services. Unlike most other currently registered URN namespaces, the service URN does not identify documents and protocol objects (e.g., RFC3044, RFC3187, RFC4179, and RFC4195), types of telecommunications equipment RFC4152, people, or organizations RFC3043. tel URIs RFC3966 identify telephone numbers, but numbers commonly identifying services (such as 911 or 112) are specific to a particular region or country.
Identifier uniqueness considerations: A service URN identifies a
logical service, specified in the service registration (see IANA Considerations (Section 4)). Resolution of the URN, if successful, will return a particular instance of the service, and this instance may be different even for two users making the same request in the same place at the same time; the logical service identified by the URN, however, is persistent and unique. Service URNs MUST be unique for each unique service; this is guaranteed through the registration of each service within this namespace, described in Section 4.
Identifier persistence considerations: The 'service' URN for the
same service is expected to be persistent, although there naturally cannot be a guarantee that a particular service will continue to be available globally or at all times.
Process of identifier assignment: The process of identifier
assignment is described in the IANA Considerations (Section 4).
Process for identifier resolution: There is no single global
resolution service for 'service' URNs. However, each top-level service can provide a set of mapping protocols to be used with 'service' URNs of that service.
Rules for lexical equivalence: 'service' identifiers are compared
according to case-insensitive string equality.
Conformance with URN syntax: The BNF in the 'Declaration of
syntactic structure' above constrains the syntax for this URN scheme.
Validation mechanism: Validation determines whether a given string
is currently a validly-assigned URN RFC3406. Due to the distributed nature of the mapping mechanism, and since not all services are available everywhere and not all mapping servers may be configured with all current service registrations, validation in this sense is not possible. Also, the discovery mechanism for the mapping mechanism may not be configured with all current top- level services.
Scope: The scope for this URN is public and global.
IANA Considerations
This section registers a new URN scheme with the registration template provided in Section 3.
Below, Section 4.1 details how to register new service-identifying labels. Descriptions of sub-services for the first two services to be registered, sos and counseling, are given in Section 4.2 and Section 4.3, respectively. Finally, Section 4.4 contains the initial registration table.
New Service-Identifying Labels
Services and sub-services are identified by labels managed by IANA, according to the processes outlined in RFC2434 in a new registry called "Service URN Labels". Thus, creating a new service requires IANA action. The policy for adding top-level service labels is
'Standards Action'. (This document defines the top-level services 'sos' and 'counseling'.) 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.
Entries in the registration table have the following format:
Service Reference Description
foo RFCxyz Brief description of the 'foo' top-level service foo.bar RFCabc Description of the 'foo.bar' service
To allow use within the constraints of S-NAPTR RFC3958, all top- level service names MUST NOT exceed 27 characters.
Sub-Services for the 'sos' Service
This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'.
The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and must be of general public interest and have a similar emergency nature. The expert is designated by the ECRIT working group, its successor, or, in their absence, the IESG. The expert review should only approve emergency services that are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered. The 'sos' service is not meant to invoke general government, public information, counseling, or social services.
urn:service:sos The generic 'sos' service reaches a public safety
answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below.
urn:service:sos.ambulance This service identifier reaches an
ambulance service that provides emergency medical assistance and transportation.
urn:service:sos.animal-control Animal control typically enforces
laws and ordinances pertaining to animal control and management, investigates cases of animal abuse, educates the community in responsible pet ownership and wildlife care, and provides for the housing and care of homeless animals, among other animal-related services.
urn:service:sos.fire The 'fire' service identifier summons the fire
service, also known as the fire brigade or fire department.
urn:service:sos.gas The 'gas' service allows the reporting of
natural gas (and other flammable gas) leaks or other natural gas emergencies.
urn:service:sos.marine The 'marine' service refers to maritime
search and rescue services such as those offered by the coast guard, lifeboat, or surf lifesavers.
urn:service:sos.mountain The 'mountain' service refers to mountain
rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments.
urn:service:sos.physician The 'physician' emergency service connects
the caller to a physician referral service.
urn:service:sos.poison The 'poison' service refers to special
information centers set up to inform citizens about how to respond to potential poisoning. These poison control centers maintain a database of poisons and appropriate emergency treatment.
urn:service:sos.police The 'police' service refers to the police
department or other law enforcement authorities.
Sub-Services for the 'counseling' Service
The 'counseling' service type describes services where callers can receive advice and support, often anonymous, but not requiring an emergency response. (Naturally, such services may transfer callers to an emergency service or summon such services if the situation warrants.) Additional sub-services can be added after expert review and should be of general public interest. The expert is chosen in the same manner as described for the 'sos' service. The expert review should take into account whether these services are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered.
urn:service:counseling The generic 'counseling' service reaches a
call center that transfers the caller based on his or her specific needs.
urn:service:counseling.children The 'children' service refers to
counseling and support services that are specifically tailored to the needs of children. Such services may, for example, provide advice to run-aways or victims of child abuse.
urn:service:counseling.mental-health The 'mental-health' service
refers to the "diagnostic, treatment, and preventive care that helps improve how persons with mental illness feel both physically and emotionally as well as how they interact with other persons". (U.S. Department of Health and Human Services)
urn:service:counseling.suicide The 'suicide' service refers to the
suicide prevention hotline.
Initial IANA Registration
The following table contains the initial IANA registration for emergency and counseling services.
Service Reference Description
counseling RFC 5031 Counseling services counseling.children RFC 5031 Counseling for children counseling.mental-health RFC 5031 Mental health counseling counseling.suicide RFC 5031 Suicide prevention hotline
sos RFC 5031 Emergency services sos.ambulance RFC 5031 Ambulance service sos.animal-control RFC 5031 Animal control sos.fire RFC 5031 Fire service sos.gas RFC 5031 Gas leaks and gas emergencies sos.marine RFC 5031 Maritime search and rescue sos.mountain RFC 5031 Mountain rescue sos.physician RFC 5031 Physician referral service sos.poison RFC 5031 Poison control center sos.police RFC 5031 Police, law enforcement
Internationalization Considerations
The service labels are protocol elements RFC3536 and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 3.
Security Considerations
As an identifier, the service URN does not appear to raise any particular security issues. The services described by the URN are meant to be well-known, even if the particular service instance is access-controlled, so privacy considerations do not apply to the URN.
There are likely no specific privacy issues when including a service URN on a web page, for example. On the other hand, ferrying the URN in a signaling protocol can give attackers information on the kind of service desired by the caller. For example, this makes it easier for the attacker to automatically find all calls for emergency services or directory assistance. Appropriate, protocol-specific security mechanisms need to be implemented for protocols carrying service URNs. The mapping protocol needs to address a number of threats, as detailed in RFC5069. That document also discusses the security considerations related to the use of the service URN for emergency services.
References
Normative References
RFC1123 Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2434 Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
RFC3261 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
RFC3958 Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
RFC4234 Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Informative References
[LOST] Hardie, T., "LoST: A Location-to-Service Translation
Protocol", Work in Progress, March 2007.
RFC2142 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.
RFC2822 Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
RFC3043 Mealling, M., "The Network Solutions Personal Internet
Name (PIN): A URN Namespace for People and Organizations",
RFC 3043, January 2001.
RFC3044 Rozenfeld, S., "Using The ISSN (International Serial
Standard Number) as URN (Uniform Resource Names) within an
ISSN-URN Namespace", RFC 3044, January 2001.
RFC3187 Hakala, J. and H. Walravens, "Using International Standard
Book Numbers as Uniform Resource Names", RFC 3187, October 2001.
RFC3406 Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
RFC3536 Hoffman, P., "Terminology Used in Internationalization in
the IETF", RFC 3536, May 2003.
RFC3966 Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
RFC4152 Tesink, K. and R. Fox, "A Uniform Resource Name (URN)
Namespace for the Common Language Equipment Identifier
(CLEI) Code", RFC 4152, August 2005.
RFC4179 Kang, S., "Using Universal Content Identifier (UCI) as
Uniform Resource Names (URN)", RFC 4179, October 2005.
RFC4195 Kameyama, W., "A Uniform Resource Name (URN) Namespace for
the TV-Anytime Forum", RFC 4195, October 2005.
RFC5012 Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
RFC5069 Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069,
January 2008.
Appendix A. Alternative Approaches Considered
The discussions of ways to identify emergency calls has yielded a number of proposals. Since these are occasionally brought up during discussions, we briefly summarize why this document chose not to pursue these solutions.
tel:NNN;context=+C This approach uses tel URIs RFC3966. Here, NNN
is the national emergency number, where the country is identified by the context C. This approach is easy for user agents to implement, but hard for proxies and other SIP elements to recognize, as it would have to know about all number-context combinations in the world and track occasional changes. In addition, many of these numbers are being used for other services. For example, the emergency number in Paraguay (00) is also used to call the international operator in the United States. As another example, a number of countries, such as Italy, use 118 as an emergency number, but it also connects to directory assistance in Finland.
tel:sos This solution avoids name conflicts, but requires extending
the "tel" URI "tel" RFC3966. It also only works if every outbound proxy knows how to route requests to a proxy that can reach emergency services since tel URIs do not identify the destination server.
sip:sos@domain Earlier work had defined a special user identifier,
sos, within the caller's home domain in a SIP URI, for example, sip:[email protected]. Such a user identifier follows the convention of RFC 2142 RFC2142 and the "postmaster" convention documented in RFC 2822 RFC2822. This approach had the advantage that dial plans in existing user agents could probably be converted to generate such a URI and that only the home proxy for the domain has to understand the user naming convention. However, it overloads the user part of the URI with specific semantics rather than being opaque, makes routing by the outbound proxy a special case that does not conform to normal SIP request-URI handling rules and is SIP-specific. The mechanism also does not extend readily to other services.
SIP URI user parameter: One could create a special URI, such as
"aor-domain;user=sos". This avoids the name conflict problem, but requires mechanism-aware user agents that are capable of emitting this special URI. Also, the 'user' parameter is meant to describe the format of the user part of the SIP URI, which this usage does not do. Adding other parameters still leaves unclear what, if
any, conventions should be used for the user and domain part of the URL. Neither solution is likely to be backward-compatible with existing clients.
Special domain: A special domain, such as "sip:[email protected]" could
be used to identify emergency calls. This has similar properties as the "tel:sos" URI, except that it is indeed a valid URI. To make this usable, the special domain would have to be operational and point to an appropriate emergency services proxy. Having a single, if logical, emergency services proxy for the whole world seems to have undesirable scaling and administrative properties.
Appendix B. Acknowledgments
This document is based on discussions with Jonathan Rosenberg and benefited from the comments of Leslie Daigle, Keith Drage, Benja Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan Rosenberg, Martin Thomson, and Hannes Tschofenig.
Author's Address
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Phone: +1 212 939 7004 EMail: [email protected] URI: http://www.cs.columbia.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [email protected].
