draft-ietf-ecrit-service-urn-02.txt   draft-ietf-ecrit-service-urn-03.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: October 4, 2006 April 2, 2006 Expires: November 20, 2006 May 19, 2006
A Uniform Resource Name (URN) for Services A Uniform Resource Name (URN) for Services
draft-ietf-ecrit-service-urn-02 draft-ietf-ecrit-service-urn-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 4, 2006. This Internet-Draft will expire on November 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The content of many communication services depend 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 register such context-dependent services that can be resolved in a to register such context-dependent services that can be resolved in a
distributed manner. distributed manner.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Registration Template . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Finding the Mapping Server . . . . . . . . . . . . . . . . . . 6 3. Registration Template . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Finding the Mapping Server . . . . . . . . . . . . . . . . . . 7
4.1 New Service-Identifying Tokens . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.2 S-NAPTR Application Service Label . . . . . . . . . . . . 7 5.1 New Service-Identifying Labels . . . . . . . . . . . . . . 8
4.3 sos Service Types . . . . . . . . . . . . . . . . . . . . 7 5.2 S-NAPTR Application Service Tag . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.3 Sub-Services for the 'sos' Service . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Sub-Services for the 'counseling' Service . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 6. International Considerations . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A. Alternative Approaches Considered . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
A. Alternative Approaches Considered . . . . . . . . . . . . . . 12
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
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 911 in North Examples include emergency services (reached by dialing 911 in North
America, 112 in Europe), community services and volunteer America, 112 in Europe), community services and volunteer
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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 mechanism. (For example, there service and a well-defined resolution mechanism. (For example, there
is no national coordination or call center for "9-1-1" in the United is no national coordination or call center for "9-1-1" in the United
States; rather, various local government organizations cooperate to States; rather, various local government organizations cooperate to
provide this service, based on jurisdictions.) provide this service, based on jurisdictions.)
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 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 directory providers that in turn manage how geographic different directory providers that in turn manage how geographic
locations are mapped to service providers. locations are mapped to service providers.
Availability of such service identifiers simplifies end system Availability of such service identifiers simplifies end system
configuration. For example, an IP phone could have a special set of configuration. For example, an IP phone could have a special set of
short cuts or buttons that invoke emergency services, as it would not short cuts or buttons that invoke emergency services, as it would not
be practical to manually re-configure the device with local emergency be practical to manually re-configure the device with local emergency
contacts for each city or town a user visits with his or her mobile contacts for each city or town a user visits with his or her mobile
device. Also, such identifiers allow to delegate routing decisions device. Also, such identifiers make it possible to delegate routing
to third parties and mark certain requests as having special decisions to third parties and to mark certain requests as having
characteristics while preventing these characteristics to be special characteristics while preventing these characteristics to be
accidentally invoked on inappropriate requests. accidentally invoked on inappropriate requests.
This URN allows to identify services independent of a particular This URN identifies services independent of a particular protocol to
protocol to deliver the services. It may appear in protocols that deliver the services. It may appear in protocols that allow general
allow general URIs, such as the Session Initiation Protocol (SIP) [5] URIs, such as the Session Initiation Protocol (SIP) [5] request URIs,
request URIs, web pages or mapping protocols. web pages or mapping protocols.
The service URN is generally not expected to be visible to humans. The service URN is generally not expected to be visible to humans.
For example, it is expected that callers will still dial '9-1-1' in For example, it is expected that callers will still dial '9-1-1' in
the United States to reach emergency services. In some other cases, the United States to reach emergency services. In some other cases,
speed dial buttons might identify the service, as is common practice speed dial buttons might identify the service, as is common practice
on hotel phones today. (Speed dial buttons for summoning emergency on hotel phones today. (Speed dial buttons for summoning emergency
help are considered inappropriate by most emergency services help are considered inappropriate by most emergency services
professionals, at least for mobile devices, as they are too prone to professionals, at least for mobile devices, as they are too prone to
being triggered accidentally.) Rather, protocol elements would carry being triggered accidentally.) Rather, protocol elements would carry
the service URN described here, allowing universal identification. the service URN described here, allowing universal identification.
The translation of dial strings to service URNs is beyond the scope The translation of dial strings to service URNs is beyond the scope
of this document; it is likely to depend on the location of the of this document; it is likely to depend on the location of the
caller and may be many-to-one. For example, a phone for a traveler caller and may be many-to-one. For example, a phone for a traveler
could recognize the emergency dial string for both the traveler's could recognize the emergency dial string for both the traveler's
home location and the traveler's visited location, translating both home location and the traveler's visited location, translating both
to the same universal service URN, urn:service:sos. to the same universal service URN, urn:service:sos.
Since service URNs are not routable, a proxy or user agent has to Since service URNs are not routable, a 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 [20] is one appropriate service provider, such as a SIP URL. LoST [21] is one
resolution system for mapping service URNs to URLs based on resolution system for mapping service URNs to URLs based on
geographic location. It is anticipated that there will be several geographic location. It is anticipated that there will be several
such systems, possibly with different systems for different services. such systems, possibly with different systems for different services.
We discuss alternative approaches, and why they are unsatisfactory, Services are described by top-level service type, and may contain a
in Appendix A. hierarchy of sub-services further describing the service, as outlined
in Section 3. Mapping protocols SHOULD always provide a mapping just
for the top-level service even if sub-services are in use. This
mapping for the top-level service MAY also be used if an entity is
presented with an invalid sub-service and presenting an error
condition to the user is inappropriate, e.g., during an emergency.
2. Registration Template We discuss alternative approaches for creating service identifiers,
and why they are unsatisfactory, in Appendix A.
2. 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 [2].
Terminology specific to emergency services is defined in [23].
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 [15]. according to RFC 3406 [15].
Namespace ID: service Namespace ID: service
Registration Information: Registration version: 1; registration date: Registration Information: Registration version: 1; registration date:
2006-04-02 2006-04-02
Declared registrant of the namespace: TBD Declared registrant of the namespace: TBD
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 [1] and a subset of the labels
allowed in [6]; labels are case-insensitive and SHOULD be allowed in [6]. Labels are case-insensitive and SHOULD be
specified in all lower-case. Any string of service labels can be specified in all lower-case. For any given service URN, service-
used to request services that are either more generic or more identifiers can be removed right-to-left and the resulting URN is
specific. In other words, if a service 'x.y.z' exists, the URNs still valid, referring a more generic service. In other words, if
'x' and 'x.y' are also valid service URNs. a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid
service URNs.
"URN:service:" service "URN:service:" service
service = top-level *("." service-identifier) service = top-level *("." sub-service)
let-dig = ALPHA / DIGIT let-dig = ALPHA / DIGIT
let-dig-hyp = let-dig / '-' let-dig-hyp = let-dig / '-'
service-identifier = let-dig [ *let-dig-hyp let-dig ] sub-service = let-dig [ *let-dig-hyp let-dig ]
top-level = let-dig [ *25let-dig-hyp let-dig ] top-level = let-dig [ *25let-dig-hyp let-dig ]
Relevant ancillary documentation: None Relevant ancillary documentation: None
Community considerations: The service URN is believe to be relevant
Community considerations: The service URN is believed to be relevant
to a large cross-section of Internet users, including both to a large cross-section of Internet users, including both
technical and non-technical users, on a variety of devices, but technical and non-technical users, on a variety of devices, but
particularly for mobile and nomadic users. The service URN will particularly for mobile and nomadic users. The service URN will
allow Internet users needing services to identify the service by allow Internet users needing services to identify the service by
kind, without having to determine manually who provides the kind, without having to determine manually who provides the
particular service in the user's current context, e.g., at his particular service in the user's current context, e.g., at the
current location. For example, a traveler will be able to use his user's current location. For example, travelers will be able to
mobile device to request emergency services without having to know use their mobile devices to request emergency services without
the local emergency number. The assignment of identifiers is having to know the emergency dial string of the visited country.
described in the IANA Considerations (Section 4). The service URN The assignment of identifiers is described in the IANA
does not prescribe a particular resolution mechanism, but it is Considerations (Section 5). The service URN does not prescribe a
assumed that a number of different entities could operate and particular resolution mechanism, but it is assumed that a number
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., [13], does not identify documents and protocol objects (e.g., [13],
[14], [18], [19]), types of telecommunications equipment [17], [14], [18], [19]), types of telecommunications equipment [17],
people or organizations [12]. tel URIs [16] identify telephone people or organizations [12]. tel URIs [16] identify telephone
numbers, but numbers commonly identifying services, such as 911 or numbers, but numbers commonly identifying services, such as 911 or
112, are specific to a particular region or country. 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). Resolution of the URN, if successful, will considerations). Resolution of the URN, if successful, will
return a particular instance of the service, and this instance may return a particular instance of the service, and this instance may
be different even for two users making the same request in the be different even for two users making the same request in the
same place at the same time; the logical service identified by the same place at the same time; the logical service identified by the
URN, however, is persistent and unique. Service URNs MUST be URN, however, is persistent and unique. Service URNs MUST be
unique for each unique service; this is guaranteed through the unique for each unique service; this is guaranteed through the
registration of each service within this namespace, described in registration of each service within this namespace, described in
Section 4. Section 5.
Identifier persistence considerations: The 'service' URN for the same Identifier persistence considerations: The 'service' URN for the same
service is expected to be persisent, although there naturally service is expected to be persistent, although there naturally
cannot be a guarantee that a particular service will continue to cannot be a guarantee that a particular service will continue to
be available globally or at all times. 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 5).
Process for identifier resolution: 'service' identifiers are resolved Process for identifier resolution: 'service' identifiers are resolved
by the mapping protocols, an instance of a Resolution Discovery by the mapping protocols, an instance of a Resolution Discovery
System (RDS) as described in RFC 2276 [3]. Each top-level service System (RDS) as described in RFC 2276 [3]. Each top-level service
can provide its own distinct set of mapping protocols. Within can provide its own distinct set of mapping protocols. Within
each top-level service, all mapping protocols MUST return the same each top-level service, all mapping protocols MUST return the same
set of mappings. Section 3 describes how DNS NAPTR records are set of mappings. Section 4 describes how the S-NAPTR mechanism is
used to find an instance of a mapping service. used to find an instance of a mapping 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: There are no special considerations.
Validation mechanism: The RDS mechanism is also used to validate the Conformance with URN Syntax: The BNF in the 'Declaration of syntactic
existence of a resource. As noted, by its design, the structure' above constrains the syntax for this URN scheme.
availability of a resource may depend on where service is desired
and there may not be service available in all or most locations. Validation mechanism: Validation determines whether a given string is
(For example, roadside assistance service is unlikely to be currently a validly-assigned URN [15]. The S-NAPTR mechanism also
available on about 70% of the earth's surface.) allows to determine if a mapping protocol for a particular top-
level service exists. The mapping protocol itself would then
answer the question whether the service identifier exists. (The
issue of whether a particular combination of service and location
yields a usable answer is beyond the scope of this specification.)
Scope: The scope for this URN is public and global. Scope: The scope for this URN is public and global.
3. Finding the Mapping Server 4. Finding the Mapping Server
When a network entity receives a service URN, it uses the S-NAPTR [6] When a network entity receives a service URN, it uses the S-NAPTR [6]
mechanism to determine how to map the service URN, possibly using mechanism to determine how to map the service URN, possibly using
other information such as geographic location, to a routable URI. other information such as geographic location, to a routable URI.
Each top-level service may define one or more such mapping protocols Each top-level service may define one or more such mapping protocols
and mapping protocol servers may be operated by a range of providers. and mapping protocol servers may be operated by a range of providers.
Thus, the network entity that needs to resolve the service URN Thus, the network entity that needs to resolve the service URN
queries an appropriate domain, typically its home or service provider queries an appropriate domain, typically its home or service provider
domain, for NAPTR records and then selects records that match the domain, for NAPTR records and then selects records that match the
service and the mapping protocols it supports. The application service and the mapping protocols it supports. The application
service for this URN is registered in IANA Considerations (Section 4) service for this URN is registered in IANA Considerations (Section 5)
of this document; the application protocols are registered in the of this document; the application protocols are registered in the
appropriate protocol document. appropriate protocol document.
try until a working server has been found DNS name provided by DHCP
(option X) reverse DNS lookup for all ICE derived addresses [20]
application service provider
The S-NAPTR entry MAY contain the "s" flag if the resolving client The S-NAPTR entry MAY contain the "s" flag if the resolving client
needs to perform an SRV resolution on the replacement string. needs to perform an SRV resolution on the replacement string.
The first entry in the following example indicates that 'sos' service The first entry in the following example indicates that 'sos' service
URNs should be mapped to URIs using the LoST [20] protocol server at URNs should be mapped to URIs using the LoST [21] protocol server at
lost.example.com, a DNS A record. The second entry is for an lost.example.com, a DNS A record. The second entry is for an
imaginary top-level service 'pizza', using the equally imagined imaginary top-level service 'pizza', using the equally imagined
'Pizza Location Protocol', offered by the pizzahouse.example.net 'Pizza Location Protocol', offered by the pizzahouse.example.net
server, which should be queried for the appropriate DNS SRV record. server, which should be queried for the appropriate DNS SRV record.
Note that these NAPTR records are maintained by example.com, i.e., Note that these NAPTR records are maintained by example.com, i.e.,
example.com does not actually provide the mapping service itself. example.com does not actually provide the mapping service itself.
example.com. example.com.
; order pref flags service regexp ; order pref flags service regexp
IN NAPTR 50 50 "a" "SURN.sos:LoST" "" IN NAPTR 50 50 "a" "SURN.sos:LoST" ""
; replacement ; replacement
lost.example.org lost.example.org
IN NAPTR 10 50 "s" "SURN.pizza:PLP" "" IN NAPTR 10 50 "s" "SURN.pizza:PLP" ""
skipping to change at page 7, line 17 skipping to change at page 8, line 5
example.com. example.com.
; order pref flags service regexp ; order pref flags service regexp
IN NAPTR 50 50 "a" "SURN.sos:LoST" "" IN NAPTR 50 50 "a" "SURN.sos:LoST" ""
; replacement ; replacement
lost.example.org lost.example.org
IN NAPTR 10 50 "s" "SURN.pizza:PLP" "" IN NAPTR 10 50 "s" "SURN.pizza:PLP" ""
_plp._tcp.pizzahouse.example.net _plp._tcp.pizzahouse.example.net
4. IANA Considerations 5. IANA Considerations
4.1 New Service-Identifying Tokens 5.1 New Service-Identifying Labels
New service-identifying tokens and sub-registrations are to be New service-identifying labels and sub-services are to be managed by
managed by IANA, according to the processes outlined in [4]. The IANA, according to the processes outlined in [4]. The policy for
policy for top-level service names is 'IETF Consensus'. The policy top-level service names is 'IETF Consensus'. The policy for
for assigning names to sub-services may differ for each top-level assigning labels to sub-services may differ for each top-level
service designation and MUST be defined by the document describing service designation and MUST be defined by the document describing
the top-level service. the top-level service.
To allow use within the constraints of S-NAPTR [6], all top-level To allow use within the constraints of S-NAPTR [6], all top-level
service names MUST NOT exceed 27 characters. service names MUST NOT exceed 27 characters.
4.2 S-NAPTR Application Service Label 5.2 S-NAPTR Application Service Tag
Since each top-level service could use one or more different Since each top-level service could use one or more different
resolution protocols, we need to indicate the top-level service in resolution protocols, we need to indicate the top-level service in
the S-NAPTR application service label. To indicate the URN-to- the S-NAPTR application service tag. To indicate the URN-to-service
service mapping service, all such services start with the string mapping service, all such services start with the string "SURN." (for
"SURN." (for "service URN"), followed by the top-level service "service URN"), followed by the top-level service identifier. Note
identifier. Note that application service labels are case- that application service tags are case-insensitive and rendered here
insensitive and rendered here in mixed case purely for readability. in mixed case purely for readability.
This document effectively creates a sub-registry of labels under
SURN, but the contents of that registry are exactly the same as those
defined in Section 5.1 and thus no separate IANA action is needed.
This document registers the label "SURN.sos" as the S-NAPTR This document registers the label "SURN.sos" as the S-NAPTR
application service label according to [6] for emergency services and application service tag according to [6] for emergency services and
defines the intended usage, interoperability considerations and defines the intended usage, interoperability considerations and
security considerations (Section 5). security considerations (Section 7).
4.3 sos Service Types 5.3 Sub-Services for the 'sos' Service
The 'sos' service type describes emergency services and services The 'sos' service type describes emergency services requiring an
related to public safety and health, typically offered by various immediate response, typically offered by various branches of the
branches of the government or other public institutions. Additional government or other public institutions. Additional sub-services can
sub-services can be added after expert review and should be of be added after expert review and should be of general public interest
general public interest. and have a similar emergency nature. The expert review should take
into account whether these emergency services 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 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), that in turn dispatches aid appropriate to answering point (PSAP) which in turn dispatches aid appropriate to
the emergency. It encompasses all of the services listed below. 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 urn:service:sos.animal-control Animal control is defined as control
of dogs, cats, and domesticated or undomesticated animals. of dogs, cats, and domesticated or undomesticated animals.
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 natural urn:service:sos.gas The 'gas' service allows the reporting of natural
gas (and other flammable gas) leaks or other natural gas gas (and other flammable gas) leaks or other natural gas
skipping to change at page 8, line 38 skipping to change at page 9, line 36
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.
urn:service:sos.suicide The 'suicide' service refers to the suicide urn:service:sos.suicide The 'suicide' service refers to the suicide
prevention hotline. prevention hotline.
urn:service:sos.mental-health The 'mental-health' service refers to
the "Diagnostic, treatment, and preventive care that helps improve 5.4 Sub-Services for the 'counseling' Service
how persons with mental illness feel both physically and
emotionally as well as how they interact with other persons." 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 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.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) (U.S. Department of Health and Human Services)
5. Security Considerations 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.
6. International Considerations
The service labels are protocol elements and not normally seen by
users. Thus, the character set for these elements is restricted, as
described in Section 3.
7. 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 [21]. detailed in [22].
6. References 8. References
6.1 Normative References 8.1 Normative References
[1] Braden, R., "Requirements for Internet Hosts - Application and [1] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989. Support", STD 3, RFC 1123, October 1989.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Sollins, K., "Architectural Principles of Uniform Resource Name [3] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998. Resolution", RFC 2276, January 1998.
skipping to change at page 9, line 36 skipping to change at page 11, line 14
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[6] Daigle, L. and A. Newton, "Domain-Based Application Service [6] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005. Service (DDDS)", RFC 3958, January 2005.
6.2 Informative References 8.2 Informative References
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[8] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [8] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
[9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
skipping to change at page 10, line 33 skipping to change at page 12, line 11
[17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace [17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace
for the Common Language Equipment Identifier (CLEI) Code", for the Common Language Equipment Identifier (CLEI) Code",
RFC 4152, August 2005. RFC 4152, August 2005.
[18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform [18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform
Resource Names (URN)", RFC 4179, October 2005. Resource Names (URN)", RFC 4179, October 2005.
[19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the [19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the
TV-Anytime Forum", RFC 4195, October 2005. TV-Anytime Forum", RFC 4195, October 2005.
[20] Hardie, T., "LoST: A Location-to-Service Translation Protocol", [20] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in
progress), March 2006.
[21] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-hardie-ecrit-lost-00 (work in progress), March 2006. draft-hardie-ecrit-lost-00 (work in progress), March 2006.
[21] Taylor, T., "Security Threats and Requirements for Emergency [22] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-00 Call Marking and Mapping", draft-ietf-ecrit-security-threats-01
(work in progress), March 2006. (work in progress), April 2006.
[23] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-09 (work in progress), May 2006.
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
Appendix A. Alternative Approaches Considered Appendix A. Alternative Approaches Considered
The "sos" SIP URI reserved user name proposed here follows the The discussions of ways to identify emergency calls has yielded a
convention of RFC 2142 [8] and the "postmaster" convention documented number of proposals. Since these are occasionally brought up during
in RFC 2822 [10]. The approach has the advantage that only the home discussions, we briefly summarize why this document chose not to
proxy for a user needs to understand the convention and that the pursue these solutions.
mechanism is likely backwards-compatible with most SIP user agents,
with the only requirement that they have to be able to generate
alphanumeric URLs. One drawback is that it may conflict with locally
assigned addresses of the form "sos@domain". Also, if proxies not
affiliated with the domain translate the URL, they violate the
current SIP protocol conventions.
There are a number of possible alternatives, each with their own set
of advantages and problems:
tel:NNN;context=+C This approach uses tel URIs [16]. Here, NNN is tel:NNN;context=+C This approach uses tel URIs [16]. Here, NNN is
the national emergency number, where the country is identified by the national emergency number, where the country is identified by
the context C. This approach is easy for user agents to implement, the context C. This approach is easy for user agents to implement,
but hard for proxies and other SIP elements to recognize, as it but hard for proxies and other SIP elements to recognize, as it
would have to know about all number-context combinations in the would have to know about all number-context combinations in the
world and track occasional changes. In addition, many of these world and track occasional changes. In addition, many of these
numbers are being used for other services. For example, the numbers are being used for other services. For example, the
emergency number in Paraguay (00) is also used to call the emergency number in Paraguay (00) is also used to call the
international operator in the United States. A number of international operator in the United States. As another example,
countries, such as Italy, use 118 as an emergency number, but it A number of countries, such as Italy, use 118 as an emergency
also connects to directory assistance in Finland. number, but it also connects to directory assistance in Finland.
tel:sos This solution avoids name conflicts, but is not a valid "tel" tel:sos This solution avoids name conflicts, but is not a valid "tel"
[16] URI. It also only works if every outbound proxy knows how to [16] URI. It also only works if every outbound proxy knows how to
route requests to a proxy that can reach emergency services since route requests to a proxy that can reach emergency services since
tel URIs. The SIP URI proposed here only requires a user's home tel URIs. The SIP URI proposed here only requires a user's home
domain to be appropriately configured. domain to be appropriately configured.
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. This approach had the advantage that dial sip:sos@example.com. Such a user identifier follows the
plans in existing user agents could probably be converted to convention of RFC 2142 [8] and the "postmaster" convention
documented in RFC 2822 [10]. 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 generate such a URI and that only the home proxy for the domain
has to understand the user naming convention. However, it has to understand the user naming convention. However, it
overloads the user part of the URI with specific semantics rather overloads the user part of the URI with specific semantics rather
than being opaque, makes routing by the outbound proxy a special than being opaque, makes routing by the outbound proxy a special
case that does not conform to normal SIP request-URI handling case that does not conform to normal SIP request-URI handling
rules and is SIP-specific. The mechanism also does not extend rules and is SIP-specific. The mechanism also does not extend
readily to other services. readily to other services.
SIP URI user parameter: One could create a special URI, such as "aor- SIP URI user parameter: One could create a special URI, such as "aor-
domain;user=sos". This avoids the name conflict problem, but 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.
Special domain: A special domain, such as "sip:fire@sos.int" could be Special domain: A special domain, such as "sip:fire@sos.int" could be
used to identify emergency calls. This has similar properties as used to identify emergency calls. This has similar properties as
the "tel:sos" URI, except that it is indeed a valid URI. To make 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 this usable, the special domain would have to be operational and
point to an appropriate emergency services proxy. Having a 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
skipping to change at page 12, line 36 skipping to change at page 14, line 4
used to identify emergency calls. This has similar properties as used to identify emergency calls. This has similar properties as
the "tel:sos" URI, except that it is indeed a valid URI. To make 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 this usable, the special domain would have to be operational and
point to an appropriate emergency services proxy. Having a 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
benefitted from the comments of Leslie Daigle, Benja Fallenstein, benefited from the comments of Leslie Daigle, Keith Drage, Benja
Paul Kyzivat, Andrew Newton, Jonathan Rosenberg and Martin Thomas. Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan
Rosenberg, Martin Thomson and Hannes Tschofenig.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 55 change blocks. 
116 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/