draft-ietf-ecrit-requirements-11.txt   draft-ietf-ecrit-requirements-12.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: December 3, 2006 R. Marshall, Ed. Expires: February 27, 2007 R. Marshall, Ed.
TCS TCS
August 26, 2006
Requirements for Emergency Context Resolution with Internet Requirements for Emergency Context Resolution with Internet
Technologies Technologies
draft-ietf-ecrit-requirements-11 draft-ietf-ecrit-requirements-12
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 34 skipping to change at page 1, line 36
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 December 3, 2006. This Internet-Draft will expire on February 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines terminology and enumerates requirements for the This document defines terminology and enumerates requirements for the
context resolution of emergency calls placed by the public using context resolution of emergency calls placed by the public using
voice-over-IP (VoIP) and general Internet multimedia systems, where voice-over-IP (VoIP) and general Internet multimedia systems, where
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 5 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Emergency Services . . . . . . . . . . . . . . . . . . . . 6 3.1 Emergency Services . . . . . . . . . . . . . . . . . . . . 6
3.2 Service Providers . . . . . . . . . . . . . . . . . . . . 6 3.2 Service Providers . . . . . . . . . . . . . . . . . . . . 6
3.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Call Routing Entities . . . . . . . . . . . . . . . . . . 7 3.4 Call Routing Entities . . . . . . . . . . . . . . . . . . 7
3.5 Location . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Location . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Identifiers, Numbers and Dial Strings . . . . . . . . . . 8 3.6 Identifiers, Numbers and Dial Strings . . . . . . . . . . 8
3.7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . 11
5. High-Level Requirements . . . . . . . . . . . . . . . . . . 14 5. High-Level Requirements . . . . . . . . . . . . . . . . . . 13
6. Identifying the Caller's Location . . . . . . . . . . . . . 16 6. Identifying the Caller's Location . . . . . . . . . . . . . 15
7. Emergency Service Identifier . . . . . . . . . . . . . . . . 19 7. Emergency Service Identifier . . . . . . . . . . . . . . . . 18
8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . 22 8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1 Normative References . . . . . . . . . . . . . . . . . . 31 13.1 Normative References . . . . . . . . . . . . . . . . . . 30
13.2 Informative References . . . . . . . . . . . . . . . . . 31 13.2 Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . 32
1. Introduction 1. Introduction
Users of both voice-centric (telephone-like) and non-voice services Users of both voice-centric (telephone-like) and non-voice services
such as text communication for hearing disabled users (RFC 3351 [3]) such as text communication for hearing disabled users (RFC 3351 [3])
expect to be able to initiate a request for help in case of an expect to be able to initiate a request for help in case of an
emergency. emergency.
Unfortunately, the existing mechanisms to support emergency calls Unfortunately, the existing mechanisms to support emergency calls
that have evolved within the public circuit-switched telephone that have evolved within the public circuit-switched telephone
skipping to change at page 3, line 37 skipping to change at page 3, line 37
We first define terminology in Section 3. The document then outlines We first define terminology in Section 3. The document then outlines
various functional issues which relate to placing an IP-based various functional issues which relate to placing an IP-based
emergency call, including a description of baseline requirements emergency call, including a description of baseline requirements
(Section 5), identification of the emergency caller's location (Section 5), identification of the emergency caller's location
(Section 6), use of a service identifier to declare a call to be an (Section 6), use of a service identifier to declare a call to be an
emergency call (Section 7), and finally, the mapping function emergency call (Section 7), and finally, the mapping function
required to route the call to the appropriate PSAP (Section 8). required to route the call to the appropriate PSAP (Section 8).
The primary purpose of the mapping protocol is to produce a PSAP URI The primary purpose of the mapping protocol is to produce a PSAP URI
drawn from a preferred set of URI schemes such as SIP or SIPS URIs, drawn from a preferred set of URI schemes such as SIP or SIPS URIs,
based on both location information [9] and a service identifier in based on both location information [8] and a service identifier in
order to facilitate the IP end-to-end completion of an emergency order to facilitate the IP end-to-end completion of an emergency
call. call.
Aside from obtaining a PSAP URI, the mapping protocol is useful for Aside from obtaining a PSAP URI, the mapping protocol is useful for
obtaining other information as well. There may be a case, for obtaining other information as well. There may be a case, for
example, where an appropriate emergency number is not known, only example, where an appropriate emergency number is not known, only
location. The mapping protocol can then return a geographically location. The mapping protocol can then return a geographically
appropriate emergency number based on the input. appropriate emergency number based on the input.
Since some PSAPs may not immediately support IP, or because some user Since some PSAPs may not immediately support IP, or because some user
skipping to change at page 8, line 37 skipping to change at page 8, line 37
string of digits used to reach the (emergency) service. The string of digits used to reach the (emergency) service. The
emergency service number is often just called the emergency emergency service number is often just called the emergency
number. It is the number typically dialed on devices directly number. It is the number typically dialed on devices directly
connected to the PSTN and the number reserved for emergency calls connected to the PSTN and the number reserved for emergency calls
by national or regional numbering authorities. It only contains by national or regional numbering authorities. It only contains
the digits 0 through 9, # and *. The service number may depend on the digits 0 through 9, # and *. The service number may depend on
the location of the caller. For example, the general emergency the location of the caller. For example, the general emergency
service number in the United States is 911 and the poison control service number in the United States is 911 and the poison control
service number is 18002221222. In most cases, the service number service number is 18002221222. In most cases, the service number
and dial string are the same; they may differ in some private and dial string are the same; they may differ in some private
phone networks. A service number may be carried in tel URLs [7], phone networks. A service number may be carried in tel URLs [6],
along with a context identifier. In the North American numbering along with a context identifier. In the North American numbering
plan, some service numbers are also three-digit N11 or service plan, some service numbers are also three-digit N11 or service
codes, but not all emergency numbers have three digits. A caller codes, but not all emergency numbers have three digits. A caller
may have to dial a service dial string (below) that differs from may have to dial a service dial string (below) that differs from
the service number when using a PBX. the service number when using a PBX.
(Emergency) service dial string: The service dial string identifies (Emergency) service dial string: The service dial string identifies
the string of digits that a caller must dial to reach a particular the string of digits that a caller must dial to reach a particular
(emergency) service. In devices directly connected to the PSTN, (emergency) service. In devices directly connected to the PSTN,
the service dial string is the same as the service number and may the service dial string is the same as the service number and may
skipping to change at page 9, line 14 skipping to change at page 9, line 14
emergency services in the United States might be 9911. Dial emergency services in the United States might be 9911. Dial
strings may contain indications of pauses or wait-for-secondary- strings may contain indications of pauses or wait-for-secondary-
dial-tone indications. Service dial strings are outside the scope dial-tone indications. Service dial strings are outside the scope
of this document. of this document.
(Emergency) service identifier: The (emergency) service identifier (Emergency) service identifier: The (emergency) service identifier
describes the emergency service, independent of the user interface describes the emergency service, independent of the user interface
mechanism, the signaling protocol that is used to reach the mechanism, the signaling protocol that is used to reach the
service, or the caller's geographic location. It is a protocol service, or the caller's geographic location. It is a protocol
constant and used within the mapping and signaling protocols. An constant and used within the mapping and signaling protocols. An
example is the service URN [12]. example is the service URN [11].
(Emergency) service URL: The service URL is a protocol-specific (Emergency) service URL: The service URL is a protocol-specific
(e.g., SIP) or protocol-agnostic (e.g., im: [6]) contains the (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the
address of the PSAP or other emergency service. It depends on the address of the PSAP or other emergency service. It depends on the
specific signaling or data transport protocol used to reach the specific signaling or data transport protocol used to reach the
emergency service. emergency service.
Service URN: A service URN is an implementation of a service Service URN: A service URN is an implementation of a service
identifier, which can be applied to both emergency and non- identifier, which can be applied to both emergency and non-
emergency contexts, e.g., urn:service:sos or emergency contexts, e.g., urn:service:sos or
urn:service:counseling. Within this document, service URNs are urn:service:counseling. Within this document, service URNs are
referred to as 'emergency service URNs' [12]. referred to as 'emergency service URNs' [11].
Home emergency number: A home emergency number is the emergency Home emergency number: A home emergency number is the emergency
number valid at the caller's customary home location, e.g., his number valid at the caller's customary home location, e.g., his
permanent residence. The home location may or may not coincide permanent residence. The home location may or may not coincide
with the service area of the caller's VSP. with the service area of the caller's VSP.
Home emergency dial string: A home dial string is the dial string Home emergency dial string: A home dial string is the dial string
valid at the caller's customary home location, e.g., his permanent valid at the caller's customary home location, e.g., his permanent
residence. residence.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
|Service | |Service |
|Provider | |Provider |
+---------------------+ +---------------------+
Figure 1: Framework for emergency call routing Figure 1: Framework for emergency call routing
Figure 1 shows the interaction between the entities involved in the Figure 1 shows the interaction between the entities involved in the
call. There are a number of different deployment choices, as can be call. There are a number of different deployment choices, as can be
easily seen from the figure. easily seen from the figure.
How is location information provided to the end host? It might
either be known to the end host itself via manual configuration,
provided via GPS, made available via DHCP ([5], [14]) or some other
mechanism. Alternatively, location information is inserted by
intermediaries.
Is the Internet Attachment Provider also the Application/Voice Is the Internet Attachment Provider also the Application/Voice
Service Provider? In the Internet today these roles are typically Service Provider? In the Internet today these roles are typically
provided by different entities. As a consequence, the Application/ provided by different entities. As a consequence, the Application/
Voice Service Provider is typically not able to directly determine Voice Service Provider is typically not able to directly determine
the physical location of the emergency caller. the physical location of the emergency caller.
The overlapping squares in the figure indicate that some functions The overlapping squares in the figure indicate that some functions
can be collapsed into a single entity. As an example, the can be collapsed into a single entity. As an example, the
Application/Voice Service Provider might be the same entity as the Application/Voice Service Provider might be the same entity as the
Internet Attachment Provider. There is, however, no requirement that Internet Attachment Provider. There is, however, no requirement that
this must be the case. Additionally, we consider that end systems this must be the case. Additionally, we consider that end systems
might act as their own ASP/VSP, e.g., either for enterprises or for might act as their own ASP/VSP, e.g., either for enterprises or for
residential users. residential users.
Various potential interactions between the entities depicted in Various potential interactions between the entities depicted in
Figure 1 are described below: Figure 1 are described below:
1. Location information might be available to the end host itself. 1. Location information might be available to the end host itself.
2. Location information might, however, also be obtained from the 2. Location information might, however, also be obtained from the
Internet Attachment Provider (e.g., using DHCP or application Internet Attachment Provider.
layer signaling protocols).
3. The emergency caller might need to consult a mapping service to 3. The emergency caller might need to consult a mapping service to
determine the PSAP (or other relevant information) that is determine the PSAP (or other relevant information) that is
appropriate for the physical location of the emergency caller, appropriate for the physical location of the emergency caller,
possibly considering other attributes such as appropriate possibly considering other attributes such as appropriate
language support by the emergency call taker. language support by the emergency call taker.
4. The emergency caller might get assistance for emergency call 4. The emergency caller might get assistance for emergency call
routing by infrastructure elements that are emergency call routing by infrastructure elements that are emergency call
routing support entities, such as an Emergency Service Routing routing support entities, such as an Emergency Service Routing
skipping to change at page 15, line 4 skipping to change at page 14, line 4
PSAPs, ASP/VSPs, IAPs or other participants. PSAPs, ASP/VSPs, IAPs or other participants.
Re4. Multi-mode communication: IP-based emergency calls MUST support Re4. Multi-mode communication: IP-based emergency calls MUST support
multiple communication modes, including, for example, audio, video multiple communication modes, including, for example, audio, video
and text. and text.
Motivation: Within the PSTN, voice and text telephony (often Motivation: Within the PSTN, voice and text telephony (often
called TTY or text-phone in North America) are the only commonly called TTY or text-phone in North America) are the only commonly
supported media. Emergency calling must support a variety of supported media. Emergency calling must support a variety of
media. Such media should include voice, conversational text (RFC media. Such media should include voice, conversational text (RFC
4103 [8]), instant messaging and video. 4103 [7]), instant messaging and video.
Re5. Mapping result usability: The mapping protocol MUST return one Re5. Mapping result usability: The mapping protocol MUST return one
or more URIs that are usable within a standard signaling protocol or more URIs that are usable within a standard signaling protocol
(i.e., without special emergency extensions). (i.e., without special emergency extensions).
Motivation: For example, a SIP URI which is returned by the Motivation: For example, a SIP URI which is returned by the
mapping protocol needs to be usable by any SIP capable phone mapping protocol needs to be usable by any SIP capable phone
within a SIP initiated emergency call. This is in contrast to a within a SIP initiated emergency call. This is in contrast to a
"special purpose" URI, which may not be recognizable by a legacy "special purpose" URI, which may not be recognizable by a legacy
SIP device. SIP device.
skipping to change at page 16, line 7 skipping to change at page 15, line 7
Re8. Anonymous mapping: The mapping protocol MUST NOT require the Re8. Anonymous mapping: The mapping protocol MUST NOT require the
true identity of the target for which the location information is true identity of the target for which the location information is
attributed. attributed.
Motivation: Ideally, no identity information is provided via the Motivation: Ideally, no identity information is provided via the
mapping protocol. Where identity information is provided, it may mapping protocol. Where identity information is provided, it may
be in the form of an unlinked pseudonym (RFC 3693 [4]). be in the form of an unlinked pseudonym (RFC 3693 [4]).
6. Identifying the Caller's Location 6. Identifying the Caller's Location
Location can either be provided directly (by value), or via a poiner Location can either be provided directly (by value), or via a pointer
(by reference), and represents either a civic location, or a (by reference), and represents either a civic location, or a
geographic location. An important question is how and when to attach geographic location. An important question is how and when to attach
location information to the VoIP emergency signaling messages. In location information to the VoIP emergency signaling messages. In
general, we can distinguish three modes of operation of how a general, we can distinguish three modes of operation of how a
location is associated with an emergency call: location is associated with an emergency call:
UA-inserted: The caller's user agent inserts the location information UA-inserted: The caller's user agent inserts the location information
into the call signaling message. The location information is into the call signaling message.
derived from sources such as GPS, DHCP (see [5] for geographic
location information and [14] for civic location information) or
utilizing the Link Layer Discovery Protocol (LLDP) [16].
UA-referenced: The caller's user agent provides a pointer (i.e., a UA-referenced: The caller's user agent provides a pointer (i.e., a
location reference), via a permanent or temporary identifier, to location reference), via a permanent or temporary identifier, to
the location information, which is stored by a location server the location information, which is stored by a location server
somewhere else and then retrieved by the PSAP, ESRP, or other somewhere else and then retrieved by the PSAP, ESRP, or other
authorized entity. authorized entity.
Proxy-inserted: A proxy along the call path inserts the location or Proxy-inserted: A proxy along the call path inserts the location or
location reference. location reference.
skipping to change at page 16, line 51 skipping to change at page 15, line 48
Lo2. Location delivery by-value: The mapping protocol MUST support Lo2. Location delivery by-value: The mapping protocol MUST support
the delivery of location information using a by-value method, the delivery of location information using a by-value method,
though it MAY also support de-referencing a URL that references a though it MAY also support de-referencing a URL that references a
location object. location object.
Motivation: The mapping protocol is not required to support the Motivation: The mapping protocol is not required to support the
ability to de-reference specific location references. ability to de-reference specific location references.
Lo3. Alternate community names: The mapping protocol MUST support Lo3. Alternate community names: The mapping protocol MUST support
both the jurisdictional community name and the postal community both the jurisdictional community name and the postal community
name fields within the PIDF-LO [9] data. name fields within the PIDF-LO [8] data.
Motivation: The mapping protocol must accept queries with either Motivation: The mapping protocol must accept queries with either
a postal or jurisdictional community name field, or both, and a postal or jurisdictional community name field, or both, and
provide appropriate responses. If a mapping query contains only provide appropriate responses. If a mapping query contains only
one community name and the database contains both jurisdictional one community name and the database contains both jurisdictional
and postal community names, the mapping protocol response SHOULD and postal community names, the mapping protocol response SHOULD
return both community names. return both community names.
Lo4. Validation of civic location: The mapping protocol MUST support Lo4. Validation of civic location: The mapping protocol MUST support
location validation for civic locations (street addresses). location validation for civic locations (street addresses).
skipping to change at page 19, line 13 skipping to change at page 18, line 13
Street Address Guide (MSAG) or commercial map data providers. Street Address Guide (MSAG) or commercial map data providers.
7. Emergency Service Identifier 7. Emergency Service Identifier
Emergency service identifiers are protocol constants that allow Emergency service identifiers are protocol constants that allow
protocol entities such as SIP proxy servers to distinguish emergency protocol entities such as SIP proxy servers to distinguish emergency
calls from non-emergency calls and to identify the specific emergency calls from non-emergency calls and to identify the specific emergency
service desired. Emergency service identifiers are a subclass of service desired. Emergency service identifiers are a subclass of
service identifiers that more generally identify services reachable service identifiers that more generally identify services reachable
by callers. An example of a service identifier is the service URN by callers. An example of a service identifier is the service URN
[12], but other identifiers, such as tel URIs [7], may also serve [11], but other identifiers, such as tel URIs [6], may also serve
this role during a transition period. this role during a transition period.
Since this document only addresses emergency services, we use the Since this document only addresses emergency services, we use the
terms "emergency service identifier" and "service identifier" terms "emergency service identifier" and "service identifier"
interchangeably. Requirements for these identifiers include: interchangeably. Requirements for these identifiers include:
Id1. Multiple emergency services: The mapping protocol MUST be able Id1. Multiple emergency services: The mapping protocol MUST be able
to distinguish between different emergency services, to distinguish between different emergency services,
differentiated by different service identifiers. differentiated by different service identifiers.
skipping to change at page 20, line 34 skipping to change at page 19, line 34
emergency service identifiers. emergency service identifiers.
Id6. Emergency service identifier marking: Signaling protocols MUST Id6. Emergency service identifier marking: Signaling protocols MUST
support emergency service identifiers to mark a call as an support emergency service identifiers to mark a call as an
emergency call. emergency call.
Motivation: Marking ensures proper handling as an emergency call Motivation: Marking ensures proper handling as an emergency call
by downstream elements that may not recognize, for example, a by downstream elements that may not recognize, for example, a
local variant of a logical emergency address. This marking local variant of a logical emergency address. This marking
mechanism is related to, but independent of, marking calls for mechanism is related to, but independent of, marking calls for
prioritized call handling [10]. prioritized call handling [9].
Id7. Handling unrecognized emergency service identifiers: There MUST Id7. Handling unrecognized emergency service identifiers: There MUST
be support for calls which are initiated as emergency calls even be support for calls which are initiated as emergency calls even
if the specific emergency service requested is not recognized by if the specific emergency service requested is not recognized by
the ESRP. Such calls will then be routed to a generic emergency the ESRP. Such calls will then be routed to a generic emergency
service. service.
Motivation: Fallback routing allows new emergency services to be Motivation: Fallback routing allows new emergency services to be
introduced incrementally, while avoiding non-routable emergency introduced incrementally, while avoiding non-routable emergency
calls. For example, a call for marine rescue services would be calls. For example, a call for marine rescue services would be
skipping to change at page 21, line 12 skipping to change at page 20, line 12
be able to report back the actual service mapped if the mapping be able to report back the actual service mapped if the mapping
protocol substitutes another service for the one requested. protocol substitutes another service for the one requested.
Motivation: A mapping server may be configured to automatically Motivation: A mapping server may be configured to automatically
look up the PSAP for another service if the user-requested service look up the PSAP for another service if the user-requested service
is not available for that location. For example, if there is no is not available for that location. For example, if there is no
marine rescue service, the mapping protocol might return the PSAP marine rescue service, the mapping protocol might return the PSAP
URL for general emergencies and include the "urn:service.sos" URL for general emergencies and include the "urn:service.sos"
identifier in the response to alert the querier to that fact. identifier in the response to alert the querier to that fact.
Id9. Discovery of visited emergency dial strings: There MUST be a Id9. Discovery of visited emergency numbers: There MUST be a
mechanism to allow the end device to learn visited emergency mechanism to allow the end device to learn visited emergency
numbers. numbers.
Motivation: Travelers visiting a foreign country may observe the Motivation: Travelers visiting a foreign country may observe the
local emergency number, e.g., seeing it painted on the side of a local emergency number, e.g., seeing it painted on the side of a
fire truck, and then rightfully expect to be able to dial that fire truck, and then rightfully expect to be able to dial that
emergency number. Similarly, a local "good Samaritan" may use a emergency number. Similarly, a local "good Samaritan" may use a
tourist's cell phone to summon help. tourist's cell phone to summon help.
8. Mapping Protocol 8. Mapping Protocol
There are two basic approaches to invoke the mapping protocol. We There are two basic approaches to invoke the mapping protocol. We
refer to these as caller-based and mediated. In each case, the refer to these as caller-based and mediated. In each case, the
mapping client initiates a request to a mapping server via a mapping mapping client initiates a request to a mapping server via a mapping
protocol. A proposed mapping protocol, LoST, is outlined in [13]. protocol. A proposed mapping protocol, LoST, is outlined in [12].
For caller-based resolution, the caller's user agent invokes the For caller-based resolution, the caller's user agent invokes the
mapping protocol to determine the appropriate PSAP based on the mapping protocol to determine the appropriate PSAP based on the
location provided. The resolution may take place well before the location provided. The resolution may take place well before the
actual emergency call is placed, or at the time of the call. actual emergency call is placed, or at the time of the call.
For mediated resolution, an emergency call routing support entity, For mediated resolution, an emergency call routing support entity,
such as a SIP (outbound) proxy or redirect server invokes the mapping such as a SIP (outbound) proxy or redirect server invokes the mapping
service. service.
skipping to change at page 22, line 40 skipping to change at page 21, line 40
Motivation: An over-abundance of similarly-capable choices appears Motivation: An over-abundance of similarly-capable choices appears
undesirable for interoperability. undesirable for interoperability.
Ma2. Extensible protocol: The mapping protocol MUST be designed to Ma2. Extensible protocol: The mapping protocol MUST be designed to
support the extensibility of location data elements, both for new support the extensibility of location data elements, both for new
and existing fields. and existing fields.
Motivation: This is needed, for example, to accommodate future Motivation: This is needed, for example, to accommodate future
extensions to location information that might be included in the extensions to location information that might be included in the
PIDF-LO ([9]). PIDF-LO ([8]).
Ma3. Incrementally deployable: The mapping protocol MUST be designed Ma3. Incrementally deployable: The mapping protocol MUST be designed
to support its incremental deployment. to support its incremental deployment.
Motivation: It must not be necessary, for example, to have a Motivation: It must not be necessary, for example, to have a
global street level database before deploying the system. It is global street level database before deploying the system. It is
acceptable to have some misrouting of calls when the database does acceptable to have some misrouting of calls when the database does
not (yet) contain accurate PSAP service area information. not (yet) contain accurate PSAP service area information.
Ma4. Any time mapping: The mapping protocol MUST support the ability Ma4. Any time mapping: The mapping protocol MUST support the ability
skipping to change at page 25, line 16 skipping to change at page 24, line 16
county may handle different streets within that city or county. county may handle different streets within that city or county.
Ma14. URL for error reporting: The mapping protocol MUST support the Ma14. URL for error reporting: The mapping protocol MUST support the
ability to return a URL that can be used to report a suspected or ability to return a URL that can be used to report a suspected or
known error within the mapping database. known error within the mapping database.
Motivation: If an error is returned, for example, there needs to Motivation: If an error is returned, for example, there needs to
be a URL which points to a resource which can explain or be a URL which points to a resource which can explain or
potentially help resolve the error. potentially help resolve the error.
Ma15. Resiliance to failure: The mapping protocol MUST support a Ma15. Resilience to failure: The mapping protocol MUST support a
mechanism which enables the client to fail over to different mechanism which enables the client to fail over to different
(replica) mapping server. (replica) mapping server.
Motivation: The failure of a mapping server should not preclude Motivation: The failure of a mapping server should not preclude
the mapping client from receiving an answer to its query. the mapping client from receiving an answer to its query.
Ma16. Traceable resolution: The mapping protocol SHOULD support the Ma16. Traceable resolution: The mapping protocol SHOULD support the
ability of the mapping client to be able to determine the entity ability of the mapping client to be able to determine the entity
or entities that provided the emergency address resolution or entities that provided the emergency address resolution
information. information.
skipping to change at page 27, line 8 skipping to change at page 26, line 8
Motivation: This is especially useful when an alternate mapping is Motivation: This is especially useful when an alternate mapping is
requested, and alternative sources of mapping data may not have requested, and alternative sources of mapping data may not have
been created or updated with the same set of information or within been created or updated with the same set of information or within
the same timeframe. Differences in currency between mapping data the same timeframe. Differences in currency between mapping data
contained within mapping sources should be minimized. contained within mapping sources should be minimized.
9. Security Considerations 9. Security Considerations
Threats and security requirements are discussed in a separate Threats and security requirements are discussed in a separate
document [11]. document [10].
10. IANA Considerations 10. IANA Considerations
This document does not require actions by the IANA. This document does not require actions by the IANA.
11. Contributors 11. Contributors
The information contained in this document is a result of a several The information in this document is partially derived from text
original joint contributions of text, which was then discussed and written by the following contributors:
refined by those and many others within the working group. These
contributors to the early text include, Nadine Abbott, Hideki Arai,
Martin Dawson, Motoharu Kawanishi, Brian Rosen, Richard Stastny,
Martin Thomson, James Winterbottom.
The contributors can be reached at:
Nadine Abbott nabbott@telcordia.com Nadine Abbott nabbott@telcordia.com
Hideki Arai arai859@oki.com Hideki Arai arai859@oki.com
Martin Dawson Martin.Dawson@andrew.com Martin Dawson Martin.Dawson@andrew.com
Motoharu Kawanishi kawanishi381@oki.com Motoharu Kawanishi kawanishi381@oki.com
Brian Rosen br@brianrosen.net Brian Rosen br@brianrosen.net
skipping to change at page 30, line 15 skipping to change at page 29, line 15
12. Acknowledgments 12. Acknowledgments
In addition to thanking those listed above, we would like to also In addition to thanking those listed above, we would like to also
thank Guy Caron, Barry Dingle, Keith Drage, Tim Dunn, Patrik thank Guy Caron, Barry Dingle, Keith Drage, Tim Dunn, Patrik
Faltstrom, Clive D.W. Feather, Raymond Forbes, Randall Gellens, Faltstrom, Clive D.W. Feather, Raymond Forbes, Randall Gellens,
Michael Haberler, Michael Hammer, Ted Hardie, Gunnar Hellstrom, Michael Haberler, Michael Hammer, Ted Hardie, Gunnar Hellstrom,
Cullen Jennings, Marc Linsner, Rohan Mahy, Patti McCalmont, Don Cullen Jennings, Marc Linsner, Rohan Mahy, Patti McCalmont, Don
Mitchell, John Morris, Andrew Newton, Steve Norreys, Jon Peterson, Mitchell, John Morris, Andrew Newton, Steve Norreys, Jon Peterson,
James Polk, Benny Rodrig, John Rosenberg, Jonathan Rosenberg, John James Polk, Benny Rodrig, John Rosenberg, Jonathan Rosenberg, John
Schnizlein, Shida Schubert, James Seng, Byron Smith, Barbara Stark, Schnizlein, Shida Schubert, James Seng, Byron Smith, Barbara Stark,
Tom Taylor, Hannes Tschofenig, and Nate Wilcox for their helpful Richard Stastny, Tom Taylor, Hannes Tschofenig, and Nate Wilcox for
input. their helpful input.
13. References 13. References
13.1 Normative References 13.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] 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.
13.2 Informative References 13.2 Informative References
skipping to change at page 31, line 26 skipping to change at page 30, line 26
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van [3] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van
Wijk, "User Requirements for the Session Initiation Protocol Wijk, "User Requirements for the Session Initiation Protocol
(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
Individuals", RFC 3351, August 2002. Individuals", RFC 3351, August 2002.
[4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[5] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [5] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[6] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
RFC 3860, August 2004. RFC 3860, August 2004.
[7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [6] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[8] Hellstrom, G. and P. Jones, "RTP Payload for Text [7] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[9] Peterson, J., "A Presence-based GEOPRIV Location Object [8] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[10] Schulzrinne, H. and J. Polk, "Communications Resource Priority [9] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412, for the Session Initiation Protocol (SIP)", RFC 4412,
February 2006. February 2006.
[11] Taylor, T., "Security Threats and Requirements for Emergency [10] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
(work in progress), July 2006. (work in progress), July 2006.
[12] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [11] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-03 (work in progress), May 2006. draft-ietf-ecrit-service-urn-04 (work in progress),
August 2006.
[13] Hardie, T., "LoST: A Location-to-Service Translation Protocol", [12] 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.
[14] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [13] Wijk, A. and G. Gybels, "Framework for real-time text over IP
and DHCPv6) Option for Civic Addresses Configuration
Information", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), January 2006.
[15] Wijk, A. and G. Gybels, "Framework for real-time text over IP
using the Session Initiation Protocol (SIP)", using the Session Initiation Protocol (SIP)",
draft-ietf-sipping-toip-05 (work in progress), June 2006. draft-ietf-sipping-toip-06 (work in progress), August 2006.
[16] Institute of Electrical and Electronics Engineers, "Station and
Media Access Control Connectivity Discovery", IEEE Standard
802.1 AB, April 2005.
Authors' Addresses Authors' Addresses
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
 End of changes. 35 change blocks. 
77 lines changed or deleted 51 lines changed or added

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