wdiff draft-ietf-ecrit-service-urn-01.txt draft-ietf-ecrit-service-urn-02.txt

SIPPING
ECRIT H. Schulzrinne
Internet-Draft Columbia U.
Expires: September 6, October 4, 2006 March 5, April 2, 2006

A Uniform Resource Name (URN) for Services
draft-ietf-ecrit-service-urn-01
draft-ietf-ecrit-service-urn-02

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 September 6, October 4, 2006.

Abstract

The content of many communication services depend on the context,
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
distributed manner.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Registration Template . . . . . . . . . . . . . . . . . . . . 4
3. SIP Media Feature Tag Registration: Service . . . . . . . . . 6
4. The Service Application Specification . . . . . . . . . . . . 7
4.1 Application Unique String . . . . . . . . . . . . . . . . 7
4.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 8
4.3 Valid Databases . . . . . . . . . . . . . . . . . . . . . 8
4.4 Expected Output . . . . . . . . . . . . . . . . . . . . . 8
4.5 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Services . . . . . . Finding the Mapping Server . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . 8
4.7 Example . . . . . . . . . . . . . . . . . . . . 7
4.1 New Service-Identifying Tokens . . . . . 8
5. IANA Considerations . . . . . . . . . 7
4.2 S-NAPTR Application Service Label . . . . . . . . . . . . 8
5.1 7
4.3 sos Service Types . . . . . . . . . . . . . . . . . . . . 9
5.2 SIP Media Feature Tag Registration: Service . . . . . . . 10
6. 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 11 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 10
A. Alternative Approaches Considered . . . . . . . . . . . . . . 13 11
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12
Intellectual Property and Copyright Statements . . . . . . . . 15 13

1. Introduction

In existing telecommunications systems, there are many well-known
communication and information services that are offered by loosely
coordinated entities across a large geographic region, with well-
known identifiers. Some of the services are operated by governments
or regulated monopolies, others by competing commercial enterprises.
Examples include emergency services (reached by dialing 911 in North
America, 112 in Europe), community services and volunteer
opportunities (211 in some regions of the United States),telephone
directory and repair services (411 and 611 in the United States and
Canada), government information services (311 in some cities in the
United States), lawyer referral services (1-800-LAWYER), car roadside
assistance (automobile clubs) and pizza delivery services.
Unfortunately, almost all of them are limited in scope to a single
country or possibly a group of countries, such as those belonging to
the North American Numbering Plan or the European Union. The same
identifiers are often used for other purposes outside that region,
making accessing such services difficult when users travel or use
devices produced outside their home country.

These services are characterized by long-term stability of user-
visible identifiers, decentralized administration of the underlying
service and a well-defined resolution mechanism. (For example, there
is no national coordination or call center for "9-1-1" in the United
States; rather, various local government organizations cooperate to
provide this service, based on jurisdictions.)

In this document, we propose a URN namespace that, together with
resolution protocols beyond the scope of this document, allows to
define such global, well-known services, while distributing the
actual implementation across a large number of service-providing
entities. While there There are many ways to divide provision of such services, we focus on geography
such as a common way to delineate dividing responsibility by geographic region or by the
service
regions. provider a user chooses. In addition, users can choose
different directory providers that in turn manage how geographic
locations are mapped to service providers.

Availability of such service identifiers simplifies end system
configuration. For example, an IP phone could have a special set of
short cuts or buttons that invoke emergency services, as it would not
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
device. Also, such identifiers allow to delegate routing decisions
to third parties and mark certain requests as having special
characteristics while preventing these characteristics to be
accidentally invoked on inappropriate requests.

This URN allows to identify services independent of a particular
protocol to deliver the services. It may appear in protocols that
allow general URIs, such as the Session Initiation Protocol (SIP) [5]
request URIs, web pages or mapping protocols.

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
the United States to reach emergency services. In some other cases,
speed dial buttons might identify the service, as is common practice
on hotel phones today. (Speed dial buttons for summoning emergency
help are considered inappropriate by most emergency services
professionals, at least for mobile devices, as they are too prone to
being triggered accidentally.) Rather, protocol elements would carry
the service URN described here, allowing universal identification.
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
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
home location and the traveler's visited location, translating both
to the same universal service URN, urn:service:sos.

Existing technologies address the mapping of

Since service identifiers to URNs are not routable, a proxy or user agent has to
translate the service for URN into a particular DNS domain (DNS SRV [13], DNS NAPTR [15]) or
a local area network (SLP [12]).

We discuss alternative approaches in Appendix A. For example, the
tel URI [20] allows to express service codes such as "911" for
emergency services by adding a context parameter, but does not
address the problem of global validity.

Since service URNs are not routable, a proxy or user agent has to
translate the service URN into a routable URL for routable URI for a location-
appropriate service provider, such as a SIP URL. LoST [24] [20] is one
resolution system for mapping service URNs to URLs based on
geographic location. It is anticipated that there will be several
such systems.

For SIP, the service URN will likely appear in either the request URI
or the To header field, depending on which SIP element recognizes the
request as identifying an emergency call. If the mapping is done by
a proxy, the call may no longer be recognizable as an emergency call.
Section 3 uses the service URN systems, possibly with different systems for different services.

We discuss alternative approaches, and why they are unsatisfactory,
in a new SIP feature tag. Appendix A.

2. Registration Template

Below, we include the registration template for the URN scheme
according to RFC 3406 [19]. [15].
Namespace ID: service
Registration Information: Registration version: 1; registration date:
2005-07-10
2006-04-02
Declared registrant of the namespace: TBD
Declaration of syntactic structure: The URN consists of a
hierarchical service identifier, with a sequence of labels
separated by periods. The left-most label is the most significant
one and is called 'top-level service', while names to the right
are called 'sub-services'. The set of allowable characters is the
same as that for domain names [1] except that there is no
restriction on the first character being and a letter; subset of the labels
allowed in [6]; labels are case-insensitive and SHOULD be
specified in all lower-case. Any string of service labels can be
used to request services that are either more generic or more
specific. In other words, if a service 'x.y.z' exists, the URNs
'x' and 'x.y' are also valid service URNs.

"URN:service:" service
service = top-level-service top-level *("." sub-service)
top-level-service service-identifier)
let-dig = service-identifier
sub-service = service-identifier
service-identifier = 1*(ALPHA ALPHA / DIGIT
let-dig-hyp = let-dig / "-") '-'
service-identifier = let-dig [ *let-dig-hyp let-dig ]
top-level = let-dig [ *25let-dig-hyp let-dig ]

Relevant ancillary documentation: None
Community considerations: The service URN is believe to be relevant
to a large cross-section of Internet users, including both
technical and non-technical users, on a variety of devices, but
particularly for mobile and nomadic users. The service URN will
allow Internet users needing services to identify the service by
kind, without having to determine manually who provides the
particular service in the user's current context, e.g., at his
current location. For example, a traveler will be able to use his
mobile device to request emergency services without having to know
the local emergency number. The assignment of identifiers is
described in the IANA Considerations (Section 5). 4). The service URN
does not prescribe a particular resolution mechanism, but it is
assumed that a number of different entities could operate and
offer such mechanisms. The ECRIT working group is currently
discussing several approaches, including solutions based on DNS,
IRIS and a web-services protocol. Software prototypes for some of
these are currently already available and are believed to be
readily developed.
Namespace considerations: There do not appear to be other URN
namespaces that serve the same need of uniquely identifying
widely-available communication and information services. Unlike
most other currently registered URN namespaces, the service URN
does not identify documents and protocol objects (e.g., [17], [13],
[14], [18], [22], [23]), [19]), types of telecommunications equipment [21], [17],
people or organizations [16]. [12]. tel URIs [20] [16] identify telephone
numbers, but numbers commonly identifying services, such as 911 or
112, are specific to a particular region or country.
Identifier uniqueness considerations: A service URN identifies a
logical service, specified in the service registration (see IANA
considerations). Resolution of the URN, if successful, will
return a particular instance of the service, and this instance may
be different even for two users making the same request in the
same place at the same time; the logical service identified by the
URN, however, is persistent and unique. Service URNs MUST be
unique for each unique service; this is guaranteed through the
registration of each service within this namespace, described in
Section 4.

Identifier persistence considerations: The 'service' URN for the same
service is expected to be persisent, although there naturally
cannot be a guarantee that a particular service will continue to
be available globally or at all times.
Process of identifier assignment: Details The process of the service identifier
assignment
depend on the service and national regulations. In general, it is
assumed that providers described in the IANA Considerations (Section 4).
Process for identifier resolution: 'service' identifiers are resolved
by the mapping protocols, an instance of services can register through a Resolution Discovery
System (RDS) as described in RFC 2276 [3]. Each top-level service
can provide its own distinct set of mapping mechanism for a particular service in a particular
geographic area. The provision of some services may be restricted
by local or national regulations. (As a hypothetical example,
providing emergency services may be restricted to government-
authorized entities, which may limit the region where each entity
can advertise its services.) The rules for protocols. Within
each service are
described in a service-specific document.
Process for identifier resolution: 'service' identifiers are resolved
by the mapping protocols, an instance of a Resolution Discovery
System (RDS) as described in RFC 2276 [3]. There could be several
such mapping protocols in concurrent use, as long as there are
reasonable guarantees that all services are available in top-level service, all mapping protocols. protocols MUST return the same
set of mappings. Section 4 3 describes the DDDS service that uses how DNS NAPTR records are
used to find an instance of a mapping service.
Rules for Lexical Equivalence: 'service' identifiers are compared
according to domain name comparison rules. The use of homographic
identifiers is NOT RECOMMENDED. case-insensitive string equality.
Conformance with URN Syntax: There are no special considerations.
Validation mechanism: The RDS mechanism is also used to validate the
existence of a resource. As noted, by its design, the
availability of a resource may depend on where service is desired
and there may not be service available in all or most locations.
(For example, roadside assistance service is unlikely to be
available on about 70% of the earth's surface.)
Scope: The scope for this URN is public and global.

3. SIP Media Feature Tag Registration: Service

This section is specific to SIP.

If a user agent recognizes an emergency call, it inserts the service
URN into the "To" header field of Finding the INVITE request. If Mapping Server

When a proxy
recognizes network entity receives a call as an emergency call, but service URN, it uses the user agent did not, S-NAPTR [6]
mechanism to determine how to map the To header field will contain another URL, service URN, possibly using
other information such as geographic location, to a tel routable URI.
Each top-level service may define one or SIP
URL. As part of the more such mapping process, the request URI will protocols
and mapping protocol servers may be
replaced with the URL operated by a range of providers.
Thus, the network entity providing the service. Thus, that needs to resolve the
INVITE request is no longer recognizable as service URN
queries an emergency call,
although this is desirable to prevent misuse of authorization bypass
for emergency calls and for appropriate policy domain, typically its home or service provider
domain, for NAPTR records and priority handling
of emergency calls.

To address this problem, we propose the use of a new media feature
tag [8], sip.service, then selects records that describe the desired communication
service.

For example, a user agent could request to be routed to marine rescue
by including the following SIP header field:

Accept-Contact: *;sip.service="urn:service:sos.marine"

The IANA registration can be found in Section 5.

4. The Service Application Specification

This template defines match the
service URN DDDS Application according to
the rules and requirements found in [6]. the mapping protocols it supports. The DDDS database used by application
service for this Application URN is found registered in [7] which is the document that defines
the NAPTR DNS Resource Record type.

In summary, a client that wants to resolve a service URN obtains a
domain name through a variety IANA Considerations (Section 4)
of means, looks up the NAPTR record for
the resolution service and used this document; the regular expression application protocols are registered in that record
to transform the service URN into a
appropriate protocol URL that leads to the
mapping service. This approach allows different domains to offer
different instances of the mapping server and to have different
services be handled by different mapping servers.

[Note: An alternative is to map document.

The S-NAPTR entry MAY contain the URN to a set of labels, ENUM-
style, so that urn:service:sos.fire becomes fire.sos.example.com.
This only works "s" flag if the service labels are also valid DNS labels.]

4.1 Application Unique String

The Application Unique String (AUS) is the service URN. This URN
MUST be canonicalized and hex encoded according resolving client
needs to perform an SRV resolution on the "absolute-uri"
production found in the Collected ABNF from RFC 2396.

4.2 First Well Known Rule replacement string.

The first well known rule extracts a key from the AUS. For this
application, the first well known rule extracts entry in the following example indicates that 'sos' service portion
from the URN, i.e., the "service" part described in Declaration of
Syntactic Structure (Section 2).

4.3 Valid Databases

The key resulting from
URNs should be mapped to URIs using the first well known rule is looked up in LoST [20] protocol server at
lost.example.com, a
single database, the DNS [7]. A record. The domain second entry is determined by local
configuration, including through DHCP [10]. For SIP services, for an
imaginary top-level service 'pizza', using the
host part of equally imagined
'Pizza Location Protocol', offered by the address-of-record (AOR) SHOULD pizzahouse.example.net
server, which should be a valid NAPTR
record.

4.4 Expected Output

The result of the application is a DNS record queried for the server to
contact.

4.5 Flags

Since the appropriate DNS SRV record.

Note that these NAPTR record provides a URI, the "u" flag is used.

4.6 Services

The service consists of a token identifying the mapping protocol ,
followed by a transport identifier. The string is defined records are maintained by example.com, i.e.,
example.com does not actually provide the mapping protocol.

4.7 Example

The following example maps service URNs to HTTP URLs of the form
http://example.com/map/[service], using the LoST [24] protocol. itself.

example.com.
; order pref flags service regexp replacement
IN NAPTR 50 50 "u" "LOST+D2T"
"!urn:service:(.*)!http://example.com/map/\1!i" .

5. "a" "SURN.sos:LoST" ""
; replacement
lost.example.org

IN NAPTR 10 50 "s" "SURN.pizza:PLP" ""
_plp._tcp.pizzahouse.example.net

4. IANA Considerations

4.1 New Service-Identifying Tokens

New service-identifying tokens and sub-registrations are to be
managed by IANA, according to the processes outlined in [4]. The
policy for top-level service names is 'IETF Consensus'. The policy
for assigning names to sub-services may differ for each top-level
service designation and MUST be defined by the document describing
the top-level service.

This section also registers a new SIP media feature tag.

5.1 top-level service.

To allow use within the constraints of S-NAPTR [6], all top-level
service names MUST NOT exceed 27 characters.

4.2 S-NAPTR Application Service Label

Since each top-level service could use one or more different
resolution protocols, we need to indicate the top-level service in
the S-NAPTR application service label. To indicate the URN-to-
service mapping service, all such services start with the string
"SURN." (for "service URN"), followed by the top-level service
identifier. Note that application service labels are case-
insensitive and rendered here in mixed case purely for readability.

This document registers the label "SURN.sos" as the S-NAPTR
application service label according to [6] for emergency services and
defines the intended usage, interoperability considerations and
security considerations (Section 5).

4.3 sos Service Types

The 'sos' service type describes emergency services and services
related to public safety and health, typically offered by various
branches of the government or other public institutions. Additional
sub-services can be added after expert review and should be of
general public interest.

urn:service:sos The generic 'sos' service reaches a public safety
answering point (PSAP), that in turn dispatches aid appropriate to
the emergency. It encompasses all of the services listed below.
urn:service:sos.ambulance This service identifier reaches an
ambulance service that provides emergency medical assistance and
transportation.
urn:service:sos.animal-control Animal control is defined as control
of dogs, cats, and domesticated or undomesticated animals.
urn:service:sos.fire The 'fire' service identifier summons the fire
service, also known as the fire brigade or fire department.
urn:service:sos.gas The 'gas' service allows the reporting of natural
gas (and other flammable gas) leaks or other natural gas
emergencies.
urn:service:sos.mountain The 'mountain' service refers to mountain
rescue services, i.e., search and rescue activities that occur in
a mountainous environment, although the term is sometimes also
used to apply to search and rescue in other wilderness
environments.
urn:service:sos.marine The 'marine' service refers to maritime search
and rescue services such as those offered by the coast guard,
lifeboat or surf lifesavers.
urn:service:sos.physician The 'physician' emergency service connects
the caller to a physician referral service.
urn:service:sos.poison The 'poison' service refers to special
information centers set up to inform citizens about how to respond
to potential poisoning. These poison control centers maintain a
database of poisons and appropriate emergency treatment.
urn:service:sos.police The 'police' service refers to the police
department or other law enforcement authorities.
urn:service:sos.suicide The 'suicide' service refers to the suicide
prevention hotline.
urn:service:sos.mental-health The 'mental-health' service refers to
the "[d]iagnostic, "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)

5.2 SIP Media Feature Tag Registration: Service

This specification defines an additional media feature tag, extending
the SIP tree entries described in [8] and following the registration
process in Section 12.1 of that document. This section serves as the
IANA registration for the service feature tags, which are made into
the SIP media feature tag tree.

Media feature tag name: sip.service
ASN.1 Identifier: New assignment by IANA.
Summary of the media feature indicated by this tag: Each feature tag
indicates the type of service requested.
Values appropriate for use with this feature tag: Service URNs, as
described in this specification, with an equality relationship.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a user agent providing a particular
type of communication service.
Examples of typical use: Routing calls to an appropriate service
provider, such as a provider of emergency services.
Related standards or documents: RFC3840.
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC3840.

5. Security Considerations

As an identifier, the service URN does not appear to raise any
particular security issues. The services described by the URN are
meant to be well-known, even if the particular service instant instance is
access-controlled, so privacy considerations do not apply to the URN.
There are likely no specific privacy issues when including a service
URN on a web page, for example. On the other hand, ferrying the URN
in a signaling protocol can give attackers information on the kind of
service desired by the caller. For example, this makes it easier for
the attacker to automatically find all calls for emergency services
or directory assistance. Appropriate, protocol-specific security
mechanisms need to be implemented for protocols carrying service
URNs. The mapping protocol needs to address a number of threats, as
detailed in [25]. Security considerations for the media feature tag
are described in [8].

7. [21].

6. References

7.1

6.1 Normative References

[1] Mockapetris, P., "Domain names Braden, R., "Requirements for Internet Hosts - concepts Application and facilities",
Support", STD 13, 3, RFC 1034, November 1987. 1123, October 1989.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[3] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998.

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.

[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, October 2002.

[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.

[8] Rosenberg, J., Schulzrinne, H., Daigle, L. and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.

[9] Duerst, M. A. Newton, "Domain-Based Application Service
Location Using SRV RRs and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", the Dynamic Delegation Discovery
Service (DDDS)", RFC 3987, 3958, January 2005.

7.2

6.2 Informative References

[10]

[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.

[11]

[8] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.

[12] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.

[13]

[9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.

[14]

[10] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[15]

[11] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.

[16]

[12] Mealling, M., "The Network Solutions Personal Internet Name
(PIN): A URN Namespace for People and Organizations", RFC 3043,
January 2001.

[17]

[13] Rozenfeld, S., "Using The ISSN (International Serial Standard
Number) as URN (Uniform Resource Names) within an ISSN-URN
Namespace", RFC 3044, January 2001.

[18]

[14] Hakala, J. and H. Walravens, "Using International Standard Book
Numbers as Uniform Resource Names", RFC 3187, October 2001.

[19]

[15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.

[20]

[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.

[21]

[17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace
for the Common Language Equipment Identifier (CLEI) Code",
RFC 4152, August 2005.

[22]

[18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform
Resource Names (URN)", RFC 4179, October 2005.

[23]

[19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the
TV-Anytime Forum", RFC 4195, October 2005.

[24]

[20] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-hardie-ecrit-lost-00 (work in progress), March 2006.

[25] Schulzrinne, H.,

[21] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-taylor-ecrit-security-threats-02 draft-ietf-ecrit-security-threats-00
(work in progress), February March 2006.

Author's Address

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US

Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu

Appendix A. Alternative Approaches Considered

The "sos" SIP URI reserved user name proposed here follows the
convention of RFC 2142 [11] [8] and the "postmaster" convention documented
in RFC 2822 [14]. [10]. The approach has the advantage that only the home
proxy for a user needs to understand the convention and that the
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 [20]. [16]. 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. 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"
[20]
[16] URI. It also only works if every outbound proxy knows how to
route requests to a proxy that can reach emergency services since
tel URIs. The SIP URI proposed here only requires a user's home
domain to be appropriately configured.

sip:sos@domain Earlier work had defined a special user identifier,
sos, within the caller's home domain in a SIP URI, for example,
sip:sos@example.com. This approach had the advantage that dial
plans in existing user agents could probably be converted to
generate such a URI and that only the home proxy for the domain
has to understand the user naming convention. However, it
overloads the user part of the URI with specific semantics rather
than being opaque, makes routing by the outbound proxy a special
case that does not conform to normal SIP request-URI handling
rules and is SIP-specific. The mechanism also does not extend
readily to other services.
SIP URI user parameter: One could create a special URI, such as "aor-
domain;user=sos". This avoids the name conflict problem, but
requires mechanism-aware user agents that are capable of emitting
this special URI. Also, the 'user' parameter is meant to describe
the format of the user part of the SIP URI, which this usage does
not do. Adding other parameters still leaves unclear what, if
any, conventions should be used for the user and domain part of
the URL. Neither solution is likely to be backward-compatible
with existing clients.
Special domain: A special domain, such as "sip:fire@sos.int" could be
used to identify emergency calls. This has similar properties as
the "tel:sos" URI, except that it is indeed a valid URI. To make
this usable, the special domain would have to be operational and
point to an appropriate emergency services proxy. Having a
single, if logical, emergency services proxy for the whole world
seems to have undesirable scaling and administrative properties.

Appendix B. Acknowledgments

This document is based on discussions with Jonathan Rosenberg and
benefitted from the comments of Leslie Daigle, Benja Fallenstein and Fallenstein,
Paul Kyzivat. Kyzivat, Andrew Newton, Jonathan Rosenberg and Martin Thomas.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.