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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/