draft-ietf-ecrit-requirements-07.txt   draft-ietf-ecrit-requirements-08.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: October 21, 2006 R. Marshall, Ed. Expires: November 3, 2006 R. Marshall, Ed.
TCS TCS
April 19, 2006 May 2, 2006
Requirements for Emergency Context Resolution with Internet Requirements for Emergency Context Resolution with Internet
Technologies Technologies
draft-ietf-ecrit-requirements-07.txt draft-ietf-ecrit-requirements-08.txt
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 36 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 October 21, 2006. This Internet-Draft will expire on November 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document enumerates requirements for the context resolution of This document enumerates requirements for the context resolution of
emergency calls placed by the public using voice-over-IP (VoIP) and emergency calls placed by the public using voice-over-IP (VoIP) and
general Internet multimedia systems, where Internet protocols are general Internet multimedia systems, where Internet protocols are
skipping to change at page 4, line 6 skipping to change at page 4, line 6
considered to be outside the scope of the ECRIT charter. considered to be outside the scope of the ECRIT charter.
Location is required for two separate purposes, first, to route the Location is required for two separate purposes, first, to route the
call to the appropriate PSAP and second, to display the caller's call to the appropriate PSAP and second, to display the caller's
location to the call taker for help in dispatching emergency location to the call taker for help in dispatching emergency
assistance to the appropriate location. assistance to the appropriate location.
As used in this document, validation of location does not require As used in this document, validation of location does not require
that we ascertain as to whether or not the location actually exists. that we ascertain as to whether or not the location actually exists.
For example, validation might only check that the house number in a For example, validation might only check that the house number in a
civic address falls within the assigned range, not whether the civic address falls within the assigned range, not whether a
building exists at that location. However, such higher precision building, known by a specific building number, exists at that
validation is desirable. location. However, such higher precision validation is desirable.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
with the qualification that unless otherwise stated these words apply with the qualification that unless otherwise stated these words apply
to the design of the mapping protocol, not its implementation or to the design of the mapping protocol, not its implementation or
application. application.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Emergency caller: The user or user device entity which sends his/her Emergency caller: The user or user device entity which sends his/her
location to another entity in the network. location to another entity in the network.
Emergency identifier: An identifier that marks a call as an emergency Emergency identifier: An identifier that marks a call as an emergency
call. call.
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call
routing support entity that invokes the location-to-PSAP URI routing support entity that invokes the location-to-PSAP URI
mapping, to return either the URI for the appropriate PSAP, or the mapping, to return either the URI for the appropriate PSAP, or the
URL for another ESRP. (In a SIP system, the ESRP would typically URL for another ESRP. (In a SIP system, the ESRP would typically
be a SIP proxy, but may also be a Back-to-back user agent (B2BUA). be a SIP proxy, but may also be a Back-to-back user agent
(B2BUA)).
Enhanced emergency service: Enhanced emergency services add the Enhanced emergency service: Enhanced emergency services add the
ability to identify the caller's identity or location to basic ability to identify the caller's identity or location to basic
emergency services. (Sometimes, only the caller location may be emergency services. (Sometimes, only the caller location may be
known, e.g., when a call is placed from a public access point that known, e.g., when a call is placed from a public access point that
is not owned by an individual.) is not owned by an individual.)
Geographic location: A reference to a locatable point described by a Geographic location: A reference to a locatable point described by a
set of defined coordinates within a geographic coordinate system, set of defined coordinates within a geographic coordinate system,
(e.g., lat/lon within the WGS-84 datum). For example, (2-D) (e.g., lat/lon within the WGS-84 datum). For example, (2-D)
skipping to change at page 15, line 7 skipping to change at page 15, line 7
Re10. Anonymous mapping: The mapping protocol MUST NOT require the Re10. 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 [9]). be in the form of an unlinked pseudonym (RFC 3693 [9]).
5. Identifying the Caller's Location 5. Identifying the Caller's Location
Location can either be provided direct, or by reference, and Location can either be provided directly, or by reference, and
represents either a civic location, or as a geographic location. How represents either a civic location, or as a geographic location. How
does the location (or location reference) become associated with the does the location (or location reference) become associated with the
call? In general, we can distinguish three modes of operation of how call? In general, we can distinguish three modes of operation of how
a location is associated with an emergency call: a 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. The location information is
derived from sources such as GPS, DHCP (RFC 3825 [2]) and derived from sources such as GPS, DHCP (RFC 3825 [2]) and
I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer I-D.ietf-geopriv-dhcp-civil [7]) or utilizing the Link Layer
Discovery Protocol (LLDP) [see IEEE8021AB]. Discovery Protocol (LLDP) [see IEEE8021AB].
skipping to change at page 15, line 32 skipping to change at page 15, line 32
and then retrieved by the PSAP, ESRP, or other authorized service and then retrieved by the PSAP, ESRP, or other authorized service
entity. 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.
Lo1. Reference datum: The mapping protocol MUST support the WGS-84 Lo1. Reference datum: The mapping protocol MUST support the WGS-84
coordinate reference system and MAY support other coordinate coordinate reference system and MAY support other coordinate
reference systems. reference systems.
Lo2. Location provided: The mapping protocol MUST retain any Lo2. Location object/info preservation: The mapping protocol MUST
location information which is provided to it, even after mapping retain any location information which is provided to it, even
is performed. after mapping is performed.
Motivation: The ESRP and the PSAP use the same location Motivation: The ESRP and the PSAP use the same location
information object, but for a different purpose. Therefore, it is information object, but for a different purpose. Therefore, it is
imperative that the mapping protocol not remove location imperative that the mapping protocol not remove location
Information so that the PSAP can still receive the caller Information so that the PSAP can still receive the caller
location. location.
Lo3. Location delivery by-value: The mapping protocol MUST support Lo3. 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
skipping to change at page 16, line 16 skipping to change at page 16, line 16
both the jurisdictional community name and the postal community both the jurisdictional community name and the postal community
name fields within the PIDF-LO data. name fields within the PIDF-LO data.
Motivation: A mapping query must be accepted with either or both Motivation: A mapping query must be accepted with either or both
community name fields, and provide appropriate responses. If a community name fields, and provide appropriate responses. If a
mapping query is made with only one field present, and if the mapping query is made with only one field present, and if the
database contains both jurisdictional and postal, the mapping database contains both jurisdictional and postal, the mapping
protocol response should return both. protocol response should return both.
Lo5. Validation of civic location: The mapping protocol MUST support Lo5. Validation of civic location: The mapping protocol MUST support
civic address validation, based on location, prior to initiating location validation for civic location (street addresses), prior
an emergency call. to initiating an emergency call.
Motivation: Location validation provides an opportunity to help Motivation: Location validation provides an opportunity to help
assure ahead of time, whether or not successful mapping to the assure ahead of time, whether or not successful mapping to the
appropriate PSAP will likely occur when it is required. appropriate PSAP will likely occur when it is required.
Validation may also help to avoid delays during emergency call Validation may also help to avoid delays during emergency call
setup due to invalid locations. setup due to invalid locations.
Lo6. Validation resolution: The mapping protocol MUST support the Lo6. Validation resolution: The mapping protocol MUST support the
ability to provide ancillary information about the resolution of ability to provide ancillary information about the resolution of
location data used to retrieve a PSAP URI. location data used to retrieve a PSAP URI.
skipping to change at page 18, line 5 skipping to change at page 17, line 19
Lo9. 3D sensitive mapping: The mapping protocol MUST implement Lo9. 3D sensitive mapping: The mapping protocol MUST implement
support for both 2D and 3D location information, and may accept support for both 2D and 3D location information, and may accept
either a 2D or 3D mapping request as input. either a 2D or 3D mapping request as input.
Motivation: It is expected that provisioning systems will accept Motivation: It is expected that provisioning systems will accept
both 2D and 3D data. When a 3D request is presented to an area both 2D and 3D data. When a 3D request is presented to an area
only defined by 2D data, the mapping result would be the same as only defined by 2D data, the mapping result would be the same as
if the height/altitude dimension was omitted in the request. if the height/altitude dimension was omitted in the request.
Lo10. Location validation indicator: The mapping protocol MAY
support a mechanism which indicates whether a civic location does
or does not fall within an existing range of addresses listed
within a referenced address database.
Motivation: It is helpful to get an indication of whether the
validation process worked or not.
Lo11. Matched element indication: The mapping protocol MAY support a
mechanism which returns an indication of specific data elements
which were matched as a result of a validation query.
Motivation: Given a query using "123 Main St. Anytown"
(represented, as A1, A2, A3, A5 in this example) it may be helpful
to receive an indication that the validation process matched only
elements A2, A3, A5 (but not A1).
Lo12. Database type indicator: The mapping protocol MAY support a
mechanism which provides an indication describing a specific
"type" of location database used.
Motivation: It is useful to know the source of the data stored in
the database used for location validation. This is applicable for
either civic or geographic location matching (e.g., USPS, MSAG,
GDT, etc.).
6. Emergency Identifier 6. Emergency Identifier
Id1. Emergency identifier support: The mapping protocol MUST support Id1. Emergency identifier support: The mapping protocol MUST support
one or more emergency identifiers for delivery back to mapping one or more emergency identifiers for delivery back to mapping
clients to be used for call setup purposes. clients to be used for call setup purposes.
Motivation: Since there is a need for any device or network Motivation: Since there is a need for any device or network
element to recognize an emergency call throughout the call setup, element to recognize an emergency call throughout the call setup,
there is also a need to have the mapping protocol provide support there is also a need to have the mapping protocol provide support
for such an identifier. This is regardless of the device location for such an identifier. This is regardless of the device location
 End of changes. 10 change blocks. 
14 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/