< draft-ietf-ecrit-rough-loc-02.txt   draft-ietf-ecrit-rough-loc-03.txt >
Internet Engineering Task Force R. Barnes Internet Engineering Task Force R. Barnes
Internet-Draft M. Lepinski Internet-Draft M. Lepinski
Intended status: Standards Track BBN Technologies Intended status: Standards Track BBN Technologies
Expires: January 28, 2011 July 27, 2010 Expires: February 17, 2011 August 16, 2010
Using Imprecise Location for Emergency Context Resolution Using Imprecise Location for Emergency Context Resolution
draft-ietf-ecrit-rough-loc-02.txt draft-ietf-ecrit-rough-loc-03.txt
Abstract Abstract
Emergency calling works best when precise location is available for Emergency calling works best when precise location is available for
emergency call routing. However, there are situations in which a emergency call routing. However, there are situations in which a
location provider is unable or unwilling to provide precise location, location provider is unable or unwilling to provide precise location,
yet still wishes to enable subscribers to make emergency calls. This yet still wishes to enable subscribers to make emergency calls. This
document describes the level of location accuracy that providers must document describes the level of location accuracy that providers must
provide to enable emergency call routing. In addition, we descibe provide to enable emergency call routing. In addition, we descibe
how emergency services and non-emergency services can be invoked by how emergency services and non-emergency services can be invoked by
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 28, 2011. This Internet-Draft will expire on February 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Determining sufficient location precision . . . . . . . . . . 4 3. Location Precision Requirements . . . . . . . . . . . . . . . 5
3.1. Location filtering . . . . . . . . . . . . . . . . . . . . 6 4. Location Filtering . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Constructing location filters . . . . . . . . . . . . . . 10 4.1. Filter Region for a Known Location . . . . . . . . . . . . 6
3.2.1. Civic address considerations . . . . . . . . . . . . . 11 4.2. Constructing a Location Filter . . . . . . . . . . . . . . 8
3.3. Maintaining location filters . . . . . . . . . . . . . . . 12 4.3. Civic Address Considerations . . . . . . . . . . . . . . . 11
3.4. Applying location filters . . . . . . . . . . . . . . . . 12 4.4. Maintaining Location Filters . . . . . . . . . . . . . . . 12
4. Requesting emergency and non-emergency services . . . . . . . 13 4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12
4.1. Emergency calling . . . . . . . . . . . . . . . . . . . . 13 5. Requesting Emergency and Non-emergency Services . . . . . . . 14
4.2. Non-emergency services . . . . . . . . . . . . . . . . . . 14 5.1. Emergency Calling . . . . . . . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Non-emergency Services . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Information about the location of an emergency caller is a critical Information about the location of an emergency caller is a critical
input to the process of emergency call establshment. Endpoint input to the process of emergency call establshment. Endpoint
location is used to determine which Public Safety Answering Point location is used to determine which Public Safety Answering Point
(PSAP) should be the destination of the call. (The entire emergency (PSAP) should be the destination of the call. (The entire emergency
calling process is described in detail in [6] and [1].) This process calling process is described in detail in [6] and [1].) This process
is most likely to work properly when the endpoint is provided with is most likely to work properly when the endpoint is provided with
the most accurate and precise information available about its the most accurate and precise information available about its
location. Using location information with maximal precision and location. Using location information with maximal precision and
accuracy minimizes the chance that a call will be mis-routed. In accuracy minimizes the chance that a call will be mis-routed.
addition, when that location is provided to the endpoint, the
endpoint is able to verify that the location is correct (to the When location is provided to the endpoint, the endpoint is able to
extent of the endpoint's knowledge of its own location) prior to an verify that the location is correct (to the extent of the endpoint's
emergency call, and is able to perform emergency call routing knowledge of its own location) prior to an emergency call, and is
functions on its own, providing redundancy for network-provided able to perform emergency call routing functions on its own,
functions. providing redundancy for network-provided functions. Moreover, when
endpoints have access to location information, they can look up PSAP
contact information themselves, reducing dependence on other call-
routing elements in the network, and increasing the overall
resilience of the system.
However, there may be situations in which it is not feasible for However, there may be situations in which it is not feasible for
endpoints to be provided with maximally precise and accurate endpoints to be provided with maximally precise and accurate
location. These cases may arise when computing precise location is location. These cases may arise when computing precise location is
an expensive or time-consuming operation (e.g., in the case of an expensive or time-consuming operation (e.g., in the case of
wireless triangulation), and location is needed quickly, as is often wireless triangulation), and location is needed quickly, as is often
the case in emergency situations. Or they may arise because the the case in emergency situations. Or they may arise because the
policy of a location provider does not allow precise location to be policy of a location provider does not allow precise location to be
provided to the endpoint. While it is undesirable to use imprecise provided to the endpoint. While it is undesirable to use imprecise
location for emergency call routing, the possibility that precise location for emergency call routing, the possibility that precise
location may not be available to the calling device must be location may not be available to the calling device must be
accomodated in order to make emergency calling possible in the accomodated in order to make emergency calling possible in the
largest possible set of circumstances. largest possible set of circumstances.
To put it another way, a need for emergency calling with imprecise
location can arise in two ways. Either the location of the endpoint
is not known to the location provider with a high degree of
precision, or the endpoint's precise location is known and the
location provider chooses to provide location with lower precision.
In the former case, the techniques described in this document can be
used to determine whether a given positioning mechanism provides
sufficient precision to support emergency calling. In the latter
case, such techniques can be used to determine how much a location
value can be "fuzzed" before it becomes unusable for emergency
services.
This document is concerned with imprecise location only in the This document is concerned with imprecise location only in the
context of routing emergency calls, i.e., for determining the correct context of routing emergency calls, i.e., for determining the correct
PSAP to receive a given call (e.g., via a LoST query [2]). Depending PSAP to receive a given call (e.g., via a LoST query [2]). Depending
on the the structure of the local emergency service network, the on the the structure of the local emergency service network, the
location information provided to the endpoint may also be used to location information provided to the endpoint may also be used to
route the call to an entity that is authorized to request precise route the call to an entity that is authorized to request precise
location, e.g., an Emergency Services Routing Proxy. The location, e.g., an Emergency Services Routing Proxy. The
requirements and processes described in this document are the same requirements and processes described in this document are the same
for both cases. for both cases. Detailed requirements are discussed in [7]
Location information may also be used in the emergency calling Location information may also be used in the emergency calling
framework to direct the dispatch of emergency responders. This usage framework to direct the dispatch of emergency responders. This usage
is treated separately from call routing for purposes of this is treated separately from call routing for purposes of this
document, and this document does not place requirements on the document, and this document does not place requirements on the
location provided for dispatch, although it should obviously be as location provided for dispatch, although it should obviously be as
precise as possible. The only provision for dispatch in this precise as possible. The only provision for dispatch in this
document is a recommendation that the location provider supply document is a recommendation that the location provider supply
endpoints with a URI that can be used by a PSAP or other emergency endpoints with a URI that can be used by a PSAP or other emergency
authority to obtain a different location for use in dispatch, authority to obtain a different location for use in dispatch,
hopefully more precise than the one used for routing. hopefully more precise than the one used for routing.
This document describes the use of imprecise location information in This document describes the use of imprecise location information in
the emergency call routing system. Section 3 describes how location the emergency call routing system. Section 3 describes how location
providers can determine the precision necessary to support emergency providers can determine the precision necessary to support emergency
call routing, and how they can use this information to optimize call routing, and how they can use this information to optimize
location delivery. Section 4 describes how emergency calls are location delivery. Section 5 describes how emergency calls are
placed in such an environment, and how non-emergency services can be placed in such an environment, and how non-emergency services can be
invoked when precise location is not available to the endpoint by invoked when precise location is not available to the endpoint by
value. value.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3]. document are to be interpreted as described in [3].
We consider in this document patterns of interaction as described in We consider in this document patterns of interaction as described in
[6]. The two main parties of interest are endpoints and location [6]. The two main parties of interest are endpoints and location
providers. Endpoints are hosts connected to the Internet that providers. Endpoints are hosts connected to the Internet that
originate emergency calls in the emergency calling architecture, originate emergency calls in the emergency calling architecture,
while location providers are entities that supply location while location providers are entities that supply location
information that is used for emergency calling. In addition, we will information that is used for emergency calling. In addition, we will
discuss how these parties interact with the LoST mapping discuss how these parties interact with the LoST mapping
infrastructure [7], and with emergency and non-emergency location- infrastructure [8], and with emergency and non-emergency location-
based service providers. based service providers.
For convenience, we say that location information, either in LoST For convenience, we say that location information, either in LoST
queries or in service boundaries, is provided "in geodetic form" if queries or in service boundaries, is provided "in geodetic form" if
it is provided in the "geodetic-2d" LoST location profile, and "in it is provided in the "geodetic-2d" LoST location profile, and "in
civic form" if it is provided in the "civic" profile. civic form" if it is provided in the "civic" profile.
3. Determining sufficient location precision The term "precision" is not used in a quantitative sense in this
document. In general, the "precision" of a location value is
determined by the size of its uncertainty region. [9] Higher
precision values have small uncertainty regions and lower precision
values have larger uncertainty regions. The notion of "sufficient
precision for emergency services is defined in Section 3
3. Location Precision Requirements
A location provider wishing to provide location information usable A location provider wishing to provide location information usable
for emergency call routing requires a mechanism for determining when for emergency call routing requires a mechanism for determining when
a description of location (e.g., a polygon) is precise enough to be a description of location (e.g., a polygon) is precise enough to be
used for emergency call routing. This mechanism might be used to used for emergency call routing. This mechanism might be used to
decide when to terminate a positioning process that converges over decide when to terminate a positioning process that converges over
time, or to choose a polygon larger than the known location of the time, or to choose a polygon larger than the known location of the
endpoint (in order to obscure the known location of the endpoint), endpoint (in order to obscure the known location of the endpoint),
while preserving the utility of the location for emergency call while preserving the utility of the location for emergency call
routing. routing.
There are three basic requirements for a location to be usable for There are three basic requirements for a location to be usable for
emergency call routing: emergency call routing:
1. The location SHOULD be sufficiently precise that a LoST request 1. The location SHOULD be sufficiently precise that a LoST request
with the location and any service URN will return a unique URI with the location and any emergency service URN will return a
mapping value. This may not be possible in all cases, e.g., unique URI mapping value. This may not be possible in all cases,
because of overlapping service boundaries creating areas with e.g., because of overlapping service boundaries creating areas
non-unique mappings, or because of positioning limitations that with non-unique mappings, or because of positioning limitations
prevent sufficiently precise positioning. that prevent sufficiently precise positioning.
2. When the location of the endpoint is known by the provider to 2. When the location of the endpoint is known by the provider to
greater precision than is being provided, the provided location greater precision than is being provided, the provided location
MUST return the same mappings from LoST, for all service URNs, as MUST return the same mappings from LoST, for all emergency
the known location. service URNs, as the known location.
3. When the location of the endpoint is known by the provider to 3. When the location of the endpoint is known by the provider to
greater precision than is being provided, the provided location greater precision than is being provided, the provided location
MUST contain the precise location (as a geographic subset). MUST contain the precise location (as a geographic subset).
These requirements lead naturally to the idea of a "location filter". 4. Location Filtering
In effect, the first of these rules divide the world into regions
where each point is served by the same set of emergency services
(i.e., the LoST mappings are the same). We call this division of
space a "location filter" and the consituent regions of uniformity
"filter regions". The second rule says that the rough location must
be in the same filter region as the precise location. (The third
rule is unrelated to filtering.)
A location filter is a collection of geographical regions satisfying A location filter is a collection of geographical regions satisfying
the following criteria: the following criteria:
1. For any location value that is a subset of a filter region, a 1. For any location value that is a subset of a filter region, a
LoST request for any service will return a unique mapping result. LoST request for any service will return a unique mapping result.
2. Any two locations within the same filter region receive the same 2. Any two locations within the same filter region receive the same
LoST results for all services LoST results for all services
Given a location filter, it is easy to determine when a given Given a location filter, it is easy to determine when a given
location value is sufficiently precise, or to create a less precise location value is sufficiently precise, or to create a less precise
version of location that is still precise enough. Namely, a location version of location that is still precise enough. Namely, a location
value is precise enough when if fits within a given filter region, value is precise enough when if fits within a given filter region,
and any superset of a location value (e.g., a polygon containing a and any superset of a location value (e.g., a polygon containing a
point) can be used as a less precise version of the location value as point) can be used as a less precise version of the location value,
long as it still fits within the same filter region. as long as it still fits within the same filter region.
For example, a simple fuzzing algorithm that maintains sufficient
precision for emergency services is to replace a given location value
with the filter region that contains it. This way, the server can
compute the filter off-line (as described below), then provision the
location of each possible target by storing a pointer to the filter
region that contains the target's location.
The remainder of this section discusses the concept of location 4.1. Filter Region for a Known Location
filtering in more detail, and describes how a location server can
construct and maintain a location filter based on information from
the LoST mapping infrastructure.
3.1. Location filtering A simple fuzzing algorithm that maintains sufficient precision for
emergency services is to replace a given location value with the
filter region that contains it. Given a known location, a location
server can compute a filter region using a series of LoST queries.
With each service-to-URI mapping, a LoST query provides a service With each service-to-URI mapping, a LoST query provides a service
boundary that represents the set of locations in which that mapping boundary that represents the set of locations in which that mapping
is valid. A consequence of this is that given a set of service is valid. A consequence of this is that given a set of service
boundaries for different services, the intersection of those service boundaries for different services, the intersection of those service
boundaries is the region in which two mappings are valid. If one boundaries is the region in which all of the corresponding mappings
service boundary corresponds to the area where "urn:service:sos.fire" are valid. If one service boundary corresponds to the area where
is served by "sip:fire@example.com" and another maps "urn:service:sos.fire" is served by "sip:fire@example.com" and
"urn:service:sos.police" to "sip:police@example.com", then the another maps "urn:service:sos.police" to "sip:police@example.com",
intersection is the are where both of these mappings are valid then the intersection is the area where both of these mappings are
("urn:service:sos.fire" maps to "sip:fire@example.com" and valid ("urn:service:sos.fire" maps to "sip:fire@example.com" and
"urn:service:sos.police" maps to "sip:police@example.com"). Outside "urn:service:sos.police" maps to "sip:police@example.com"). Outside
that area, one or more of the mappings is invalid. So as was that area, one or more of the mappings is invalid. So as was
suggested above, the intersection of two service boundaries defines a suggested above, the intersection of two service boundaries defines a
set of mappings, and any two locations within that intersection are set of mappings, and any two locations within that intersection are
equivalent for the purpose of LoST mapping (i.e., emergency call equivalent for the purpose of LoST mapping (i.e., emergency call
routing). routing).
Filter regions can be deduced constructed from LoST mappings for a
sample location by intersecting all the service boundaries for
services available at that point. Figure 1 illustrates how the
filter region containing the point X is the intersection of the
service boundaries for police and fire services that serve X.
sos.police sos.fire sos.ambulance
+-------+ +---------------+
| A | | B |
| | | | +-------+
| X | | X | | X |
+-------+ +---------------+ | |
| C |
+-------+
| | |
| | |
+-------------------+-------------------+
|
V
+-------+-------+
| A | B |
| +-------+ |
| | X | | |
+-------+-------+
| C |
+-------+
|
|
V
+---+
| X |
+---+
Resulting filter region
(police=>A, fire=>B, ambulance=>C)
Figure 1: Generating a Filter Region from a Sample Point
In pseudocode form, algorithm for constructing a filter region from a
point is as follows:
function filterRegion(X):
Set REGION = the world
Perform a LoST <listServicesByLocation> query for X
Set SL = <serviceList> from LoST <listServicesByLocationResponse>
If SL == NULL or LoST returned an error
Return the empty set
For each service URN S in SL
Perform a LoST <findService> query for Y and S
If LoST returned an error
Continue
Set SB = <serviceBoundary> from LoST <findServiceResponse>
If SB is not provided, throw an error
Else set REGION = intersection( REGION, SB )
If <listServicesByLocationResponse> has a <serviceListBoundary>
Set SLB = <serviceListBoundary>
from LoST <listServicesByLocationResponse>
Set REGION = intersection( REGION, SLB )
Return REGION
The final intersection with the serviceListBoundary is necessary
because if some parts of the region receive a different set of
services, they have different LoST routing properties, and thus need
to be excluded from the filter region. [4]
It is important that the filter take into account all emergency
services available in over the coverage area of the LIS. (That is,
the services listed in the LoST serviceList elements.) The feature
is necessary in order to ensure that calls to all available emergency
services can be routed correctly using rough location values provided
by the filter.
While in principle, a location server could execute this algorithm to
compute a fresh filter region on each query, it is much more
efficient to use the offline algorithm for computing an entire
location filter, described in the next section.
4.2. Constructing a Location Filter
When a location server knows ahead of time that it will be providing
rough location values, it can pre-compute a location filter that
contains all the filter regions for locations it's concerned with.
Once the filter has been computed (as an off-line computation), the
filter region for a given precise location can be found by searching
for the pre-computed region that contains the precise location. When
precise location is not known, a complete filter can be used to test
evaluate the utility of an imprecise location by determining the
degree to which it overlaps with each filter region.
For example, a simple fuzzing algorithm that maintains sufficient
precision for emergency services is to replace a given location value
with the filter region that contains it. This way, the server can
compute the filter off-line (as described below), then provision the
location of each possible device by storing a pointer to the filter
region that contains the device's location.
Service boundaries for individual services Service boundaries for individual services
urn:service:sos.police urn:service:sos.fire urn:service:sos.police urn:service:sos.fire
+-------+ +-------+ +-------+ +-------+
| A | | C | | A | | C |
| +---+ | +---+---+ | +---+ | +---+---+
| | | | X | | | | | | | |
+---+---+ | +---+ | +---+---+ | +---+ |
| B | | D | | B | | D |
+-------+ +-------+ +-------+ +-------+
| | | |
| | | |
+-----------+------------+ +-----------+------------+
| |
V V
skipping to change at page 7, line 35 skipping to change at page 9, line 42
| +---+ | +---+
| | +---+ | | +---+
+---+ |A,D| +---+ +---+ |A,D| +---+
+---+ | | +---+ | |
+---+ | +---+ |
| B,D | | B,D |
+-------+ +-------+
Resulting Location Filter Regions Resulting Location Filter Regions
Figure 1: Generating a filter from service boundaries Figure 2: Generating a Filter from Service Boundaries
The regions in a location filter can thus be constructed by taking The filter regions in a filter can are constructed by taking
intersections of service boundaries. Figure 1 shows a simple intersections of service boundaries. Figure 2 shows a simple
location filter: Starting with a set of four service boundaries for location filter: Starting with a set of four service boundaries for
two different services. The filter that results from taking two different services. The filter that results from taking
intersections of these boundaries has three regions: intersections of these boundaries has three regions:
1. A region where police calls are directed to A and fire calls are 1. A region where police calls are directed to A and fire calls are
directed to C. directed to C.
2. A region where police calls are directed to A and fire calls are 2. A region where police calls are directed to A and fire calls are
directed to D. directed to D.
skipping to change at page 8, line 11 skipping to change at page 10, line 19
directed to D. directed to D.
These regions satisfy the criteria for a location filter because each These regions satisfy the criteria for a location filter because each
one has a unique set of mappings and those mappings are valid across one has a unique set of mappings and those mappings are valid across
the entire region. The service regions for B and C do not overlap -- the entire region. The service regions for B and C do not overlap --
there is no place where police calls go to B and fire calls to C -- there is no place where police calls go to B and fire calls to C --
so there is no (B,C) region. so there is no (B,C) region.
More generally, a filter region is the intersection of the service More generally, a filter region is the intersection of the service
boundaries for all services available within the region. A filter boundaries for all services available within the region. A filter
can used to determine whether a location is usable for emergency call can be used to determine whether a location is usable for emergency
routing in the following way: call routing in the following way:
1. The location SHOULD be contained in exactly one of the regions in 1. The location SHOULD be contained in exactly one of the regions in
the filter. This guarantees that LoST mappings are unique. the filter. This guarantees that LoST mappings are unique.
2. When the precise location of the endpoint is known, the provided 2. When the precise location of the endpoint is known, the provided
location MUST be contained in the same region(s) of the filter as location MUST be contained in the same region(s) of the filter as
the known location. This guarantees that LoST queries with the the known location. This guarantees that LoST queries with the
provided location return the same results as those done with the provided location return the same results as those done with the
known location. known location.
3. When the precise location of the endpoint is known, the provided 3. When the precise location of the endpoint is known, the provided
location MUST contain the precise location (as a geographic location MUST contain the precise location (as a geographic
subset). subset).
Filter regions can be deduced constructed from LoST mappings for a Practically speaking, a location filter is built up by computing
sample location by intersecting all the service boundaries for filter regions for sample points, using the algorithm described
services available at that point. Figure 2 illustrates how the above. In the example of Figure 2, one would need to sample three
filter region containing the point X is the intersection of the points: One in the (A,C) region, one in the (A,D) region and one in
service boundaries for police and fire services that serve X. the (B,D) region. The overall algorithm thus samples random points
until the computed filter regions cover the desired area. (For
simplicity, we assume that the entity performing filtering will only
be using the filter to test locations contained within a particular
geographic "coverage area". In principle, this coverage area could
be the entire world, but assuming a more limited coverage area allows
for a filter to be built more quickly)
function filter(LS_AREA):
Set FILTER = the empty set
Set COVERAGE = the empty set
Set ERR_COUNT = 0
While COVERAGE < LS_AREA && ERR_COUNT < 100
Choose a random uncovered point X in LS_AREA
Compute R = filterRegion(X)
If R != the empty set
Add R to FILTER
Set COVERAGE = union(COVERAGE, R)
Else
ERR_COUNT += 1
Return FILTER
If the server also stores the lists of URN-URI mappings for each If the server also stores the lists of URN-URI mappings for each
region, x then the filter can also be used as a cache for LoST region, then the filter can also be used as a cache for LoST
mappings; the LoST mappings for a location are the mappings bound to mappings; the LoST mappings for a location are the mappings bound to
the region(s) containing it. the region(s) containing it.
sos.police sos.fire sos.ambulance
+-------+ +---------------+
| A | | B |
| | | | +-------+
| X | | X | | X |
+-------+ +---------------+ | |
| C |
+-------+
| | |
| | |
+-------------------+-------------------+
|
V
+-------+-------+
| A | B |
| +-------+ |
| | X | | |
+-------+-------+
| C |
+-------+
|
|
V
+---+
| X |
+---+
Resulting filter region
(police=>A, fire=>B, ambulance=>C)
Figure 2: Generating a filter region from a sample point
When the location of the endpoint is known to more precision than the
location provided to the endpoint, although any location meeting the
two criteria above is equivalent to the known location for purposes
of LoST, the provided location MUST contain the known location in
order to avoid errors if the location is used for other purposes in
the course of an emergency (e.g., if the location is provided to
first responders for dispatch). This guarantee also allows the
endpoint to do some course verification that the provided location is
correct (in order to prevent very gross errors in routing). Thus,
any location that (1) contains the known location and (2) is
contained in the same filter region as the known location is
allowable. Locations that also are contained in only one filter
region are preferred. Adding randomness to the provided locations
may have privacy benefits in some cases, as discussed in the security
considerations below.
3.2. Constructing location filters
For simplicity, we assume that the entity performing filtering will
only be using the filter to test locations contained within a
particular geographic "coverage area". In principle, this coverage
area could be the entire world, but assuming a more limited coverage
area allows for a filter to be built more quickly.
Given a coverage area and the ability to act as a LoST client, a
location service provider can autonomously compute a location filter
by constructing regions around sample points until it has a
collection of filter regions that collectively cover its service
region. (The process for an individual point is illustrated in
Figure 2.)
In order to ensure that all services boundaries are taken into
account, the server starts by issuing a <listServicesByLocation>
query, and caching the list of services that it returns, along with
the corresponding service list boundary [4]. The server then samples
points within that service list boundary, retrieving mappings with
service boundaries for each service in the service list and
intersecting the service boundaries to obtain a new filter region.
In pseudocode, the algorithm is as follows:
Set FILTER = the empty set
While filter does not cover LS coverage area
Choose a random uncovered point X in the LS coverage area
Perform a LoST <listServicesByLocation> query for X
Set SL = <serviceList> from LoST response
Set SLB = <serviceListBoundary> from LoST response
If SLB is not provided, choose new point X and re-query
If more than 100 points X have been tried
Set R = uncovered area
Add R to FILTER
END
While filter does not cover SLB
Choose a random uncovered point Y in SLB
Set R = SLB
For each service S in SL
Perform a LoST <findService> query for Y and S
Set SB = <serviceBoundary> from LoST response
If SB is not provided, return an error
Else set R = intersection( R, SB(S,Y) )
Add R to FILTER
If the LoST servers have been provisioned properly then this If the LoST servers have been provisioned properly then this
algorithm will terminate successfully. If LoST mapping do not cover algorithm will terminate successfully. If LoST mappings do not cover
part of the service region, then the <serviceListBoundary> will not a point X, then the filterRegion(X) will return the empty set, and
be returned, and the algorithm will give up after 100 queries. This the algorithm will give up after 100 such queries. This limit on
limit on queries introduces some risk that a small covered area will queries introduces some risk that a small covered area will be left
be left out of the filter and marked as uncovered; if this is a out of the filter and marked as uncovered; if this is a concern, then
concern, then the query limit can be increased. the query limit can be increased, or the algorithm can be explicitly
directed to sample certain specific points.
Of course, if the location server operator has information about Of course, if the location server operator has information about
service boundaries through some channel other than LoST, then the service boundaries through some channel other than LoST, then the
LoST queries above can be replaced by queries to a local store of LoST queries above can be replaced by queries to a local store of
mapping information. The choice of random points can also be guided mapping information. The choice of random points can also be guided
to ensure that all mapped areas are covered even if there are some to ensure that all mapped areas are covered even if there are some
uncovered areas. The location server can also cache service uncovered areas. The location server can also cache service
boundaries acquired during the algorithm to avoid unnecessary LoST boundaries acquired during the algorithm to avoid unnecessary LoST
queries. queries.
3.2.1. Civic address considerations 4.3. Civic Address Considerations
This algorithm actually results in two filters -- one for geodetic This algorithm actually results in two filters -- one for geodetic
service boundaries and one for civic service boundaries -- since service boundaries and one for civic service boundaries -- since
civic and geodetic boundaries cannot be directly compared or civic and geodetic boundaries cannot be directly compared or
intersected. It is RECOMMENDED that location servers always compute intersected. It is RECOMMENDED that location servers always compute
a geodetic filter for use with emergency services, since the notion a geodetic filter for use with emergency services, since the notion
of civic service boundaries have some inherent ambiguity. of civic service boundaries have some inherent ambiguity.
Considerations around civic service boundaries are discussed in
detail in [10]
Indeed, the notion of intersection of civic service boundaries has Indeed, the notion of intersection of civic service boundaries has
some dependence on the jurisdiction within which the service some dependence on the jurisdiction within which the service
boundaries are defined. Civic service boundaries are comprised of a boundaries are defined. Civic service boundaries are comprised of a
set of <civicAddress> elements, each defining a set of civic set of <civicAddress> elements, each defining a set of civic
addresses that are within the boundary, namely those that match the addresses that are within the boundary, namely those that match the
civic elements provided. civic elements provided.
When computing the intersection of two civic service boundaries, any When computing the intersection of two civic service boundaries, any
<civicAddress> elements that are shared between the two service <civicAddress> elements that are shared between the two service
boundaries MUST be included in the resulting intersection. When two boundaries MUST be included in the resulting intersection. When two
skipping to change at page 12, line 7 skipping to change at page 12, line 26
according to local addressing standards. according to local addressing standards.
Note that the resulting filter regions SHOULD still cover the Note that the resulting filter regions SHOULD still cover the
location server's coverage area, i.e., there should be a filter location server's coverage area, i.e., there should be a filter
region that contains every civic address within the coverage area. region that contains every civic address within the coverage area.
In particular, the server SHOULD NOT use a specific address to In particular, the server SHOULD NOT use a specific address to
represent a filter region: Such an address would not include many represent a filter region: Such an address would not include many
points in the service region (i.e., it would not meet the third rules points in the service region (i.e., it would not meet the third rules
from the lists of rules above). If the server creates a PIDF-LO from the lists of rules above). If the server creates a PIDF-LO
document describing a civic address that does not contain the precise document describing a civic address that does not contain the precise
location of the target, then it MUST set the 'method' element of the location of the device, then it MUST set the 'method' element of the
PIDF-LO it returns to value 'area-representative' registered in PIDF-LO it returns to value 'area-representative' registered in
Section 7. Section 8.
3.3. Maintaining location filters 4.4. Maintaining Location Filters
As the LoST mappings that underlie the filter change, the filter will As the LoST mappings that underlie the filter change, the filter will
need to be updated. The entity maintaining the filter MUST obtain a need to be updated. The entity maintaining the filter MUST obtain a
new mapping for a region when an existing mapping expires. The new mapping for a region when an existing mapping expires. The
service boundary from the new mapping is compared to the service service boundary from the new mapping is compared to the service
boundary from the old mapping: If they are the same, then the filter boundary from the old mapping: If they are the same, then the filter
need not be updated. If they differ, then regions in the filter that need not be updated. If they differ, then regions in the filter that
intersect either the old service boundary or the new service boundary intersect either the old service boundary or the new service boundary
will need to be recomputed. Note that since this operation only will need to be recomputed. Note that since this operation only
requires the server to determine if two service boundaries are requires the server to determine if two service boundaries are
identical, the server need only store a hash of the old boundary to identical, the server need only store a hash of the old boundary to
which it can compare a hash of the new boundary. which it can compare a hash of the new boundary.
3.4. Applying location filters 4.5. Applying Location Filters
After constructing a location filter, a location server can use it to After constructing a location filter, a location server can use it to
optimize how it delivers location. When the location server is using optimize how it delivers location. How this is done depends on
a positioning algorithm that grows more accurate with time, the whether the location server is trying to reduce the precision of a
filter tells it how long to run the algorithm. Namely, the algorithm known precise location, or trying to determine whether an imprecise
can be terminated when the estimated location (that is, an position is good enough for emergency services.
uncertainty region containing the target's location) is within one of
the regions in the filter.
When the location provider knows the precise location of the caller, When the location provider knows the precise location of the caller,
a location filter can also be used as a "location cache". That is, a location filter can also be used as a "location cache". That is,
the location provider can simply look up which of the filter regions the location provider can simply look up which of the filter regions
contains the caller's precise location and return that region as the contains the caller's precise location and return that region as the
caller's location, or some subset that contains the precise location. caller's location, or some subset that contains the precise location.
This caching strategy allows an additional optimization in some This caching strategy allows an additional optimization in some
cases: If the location server knows that the caller's precise cases: If the location server knows that the caller's precise
location will be within the same region for a period of time, it can location will be within the same region for a period of time, it can
instruct the client not to re-query in that time. For instance, if instruct the client not to re-query in that time. For instance, if
the server is delivering location over HELD, then it can use the HTTP the server is delivering location over HELD, then it can use the HTTP
cache-control headers (e.g., Expires). However, the location server cache-control headers (e.g., Expires). However, the location server
MUST NOT instruct the client to wait for longer than the current MUST NOT instruct the client to wait for longer than the current
filter is valid; the expiry time of the location MUST be before the filter is valid; the expiry time of the location MUST be before the
earliest expiry of a LoST mapping used in the filter. earliest expiry of a LoST mapping used in the filter.
4. Requesting emergency and non-emergency services When the location server starts with imprecise location, there are
different ways to apply the filter, depending on the positioning
technique being used. For example with a positioning algorithm that
grows more accurate with time, the filter can tell the server how
long to run the algorithm -- the algorithm can be terminated when the
estimated location (that is, an uncertainty region containing the
device's location) is within one of the regions in the filter.
A location filter can also be used to test whether a database of
rough locations for IP addresses (as is commonly used for web
localization today) contains precise enough values for use with
emergency services. To make this determination, each value in the
database woud be tested to see if it falls mostly or entirely within
a given filter region. Note, however, that this test does not
address concerns about the accuracy of location information, i.e.,
the probability that the caller is actually contained within the
specified uncertainty region.
Note that the requirements for containment in a filter region differ
between these two use cases. When precise location is known, the
rough location that is returned MUST be contained within a single
filter region; otherwise, there will be an increased risk of mis-
routing. When the location server starts with imprecise location, it
may choose location values that are not entirely within one filter
region. The distribution of the imprecise location value among
filter regions corresponds to the risk that LoST routing will provide
incorrect information, so the choice of location value should balance
the risk of incorrect routing against the additional time needed to
obtain more precise location (which can translate to a delay in call
setup). Actually, in this case, it may not even be possible for a
location server to return a location value that is entirely within a
single filter region.
5. Requesting Emergency and Non-emergency Services
When a location provider wishes to deliver endpoints location When a location provider wishes to deliver endpoints location
information that is below its maximum available precision while still information that is below its maximum available precision while still
supporting emergency calling, it MUST provide to the endpoint both a supporting emergency calling, it MUST provide to the endpoint both a
location (by value) that is sufficient for emergency call routing (as location (by value) that is sufficient for emergency call routing (as
defined above) and a location reference (i.e., a URI) that can defined above) and a location reference (i.e., a URI) that can
subsequently be used by authorized parties to obtain more precise subsequently be used by authorized parties to obtain more precise
information about the location of the endpoint. The endpoint then information about the location of the endpoint. The endpoint then
can then use both the location value and the location reference to can then use both the location value and the location reference to
request emergency services and other location-based services (LBS). request emergency services and other location-based services (LBS).
4.1. Emergency calling This arrangement allows the client to provide rough location (by
value) to any entity, and to provide precise location (by reference)
to authorized parties. An assumption of this model, of course, is
that emergency authorities are authorized by the location provider to
receive precise location. Location providers may also authorize
other entities to receive precise location information (e.g.,
commercial services that have agreed to pay for location).
Authorization policy for location URIs is set by the referenced
location server; a mechanism for clients to request information about
this policy is described in [11].
5.1. Emergency Calling
The overall procedure for placing an emergency call is identical to The overall procedure for placing an emergency call is identical to
that described in [6]. In particular, the endpoint requirements in that described in [6]. In particular, the endpoint requirements in
Sections 8 and 9 of [1] still apply to an endpoint that receives Sections 8 and 9 of [1] still apply to an endpoint that receives
imprecise location. imprecise location.
In addition, an endpoint that receives location both by value and by In addition, an endpoint that receives location both by value and by
reference from its location provider MUST include both the location reference from its location provider MUST include both the location
value and the location reference in the SIP INVITE message that value and the location reference in the SIP INVITE message that
initiates an emergency call, as specified in [8]. When the endpoint initiates an emergency call, as specified in [12]. When the endpoint
supports LoST, it MUST use the location value to obtain a PSAP URI supports LoST, it MUST use the location value to obtain a PSAP URI
for LoST queries before attempting to dereference the location for LoST queries before attempting to dereference the location
reference. Note that the caller would also have to add the "used- reference. Note that the caller would also have to add the "used-
for-routing" parameter to the geolocation header that points to the for-routing" parameter to the geolocation header that points to the
location value as inserted into the INVITE message. Note that this location value as inserted into the INVITE message. Note that this
process crucially relies on the location value having sufficient process crucially relies on the location value having sufficient
precision for routing emergency calls (see Section 3 for techniques precision for routing emergency calls (see Section 3 for techniques
to ensure the location value is suitable for emergency call routing). to ensure the location value is suitable for emergency call routing).
When a PSAP receives a SIP INVITE that contains both a location value When a PSAP receives a SIP INVITE that contains both a location value
skipping to change at page 14, line 5 skipping to change at page 15, line 15
that either the provider must supply a reference that can be that either the provider must supply a reference that can be
dereferenced by any party, or else the provider must establish dereferenced by any party, or else the provider must establish
explicit authentication and authorization relationships with all explicit authentication and authorization relationships with all
PSAPs in its service area. It is RECOMMENDED that location providers PSAPs in its service area. It is RECOMMENDED that location providers
establish similar relationships with other PSAPs in adjoining establish similar relationships with other PSAPs in adjoining
jursidictions -- even if their service regions do not overlap with jursidictions -- even if their service regions do not overlap with
the location provider's -- in case such a PSAP needs access to the location provider's -- in case such a PSAP needs access to
precise location information, for example, if it is acting as a precise location information, for example, if it is acting as a
backup for one of the location provider's normal PSAPs. backup for one of the location provider's normal PSAPs.
4.2. Non-emergency services 5.2. Non-emergency Services
Non-emergency LBSs may require more precise information than is Non-emergency LBSs may require more precise information than is
required for emergency call routing. Therefore, when requesting a required for emergency call routing. Therefore, when requesting a
non-emergency LBS, the endpoint SHOULD include the location reference non-emergency LBS, the endpoint SHOULD include the location reference
provided by its location provider, and MAY additionally provide the provided by its location provider, and MAY additionally provide the
location value. If the provided location value is not sufficiently location value. If the provided location value is not sufficiently
precise to deliver the requested service, then the LBS provider precise to deliver the requested service, then the LBS provider
should then dereference the location value to request location should then dereference the location value to request location
information of sufficient precision from the location provider. If information of sufficient precision from the location provider. If
the dereference fails, then the request for service may fail as well. the dereference fails, then the request for service may fail as well.
skipping to change at page 14, line 30 skipping to change at page 15, line 40
provider and the location provider. In such a case, the endpoint may provider and the location provider. In such a case, the endpoint may
not know whether a given non-emergency service is authorized to not know whether a given non-emergency service is authorized to
obtain the endpoint's precise location using the location reference. obtain the endpoint's precise location using the location reference.
The endpoint is always capable of requesting services without knowing The endpoint is always capable of requesting services without knowing
whether they are authorized; in this way, the endpoint can discover whether they are authorized; in this way, the endpoint can discover
authorized services by trial and error. In order to simplify this authorized services by trial and error. In order to simplify this
process, a location provider may supply the endpoint with references process, a location provider may supply the endpoint with references
to authorized service providers, although there is currently no to authorized service providers, although there is currently no
standard protocol for this transaction. standard protocol for this transaction.
5. Acknowledgements 6. Acknowledgements
This document generalizes the concept of "rough location" that was This document generalizes the concept of "rough location" that was
originally discussed in the context of the location hiding problem. originally discussed in the context of the location hiding problem.
This concept was put forward by Henning Schulzrinne and Andy Newton, This concept was put forward by Henning Schulzrinne and Andy Newton,
among many others, in a long-running ECRIT discussion. among many others, in a long-running ECRIT discussion. Thanks to
Hannes Tschofenig and Martin Thomson for detailed reviews of this
document.
6. Security Considerations 7. Security Considerations
The use of imprecise location provides a security trade-off for The use of imprecise location provides a security trade-off for
location providers. When location providers are required to provide location providers. When location providers are required to provide
location in support of emergency services, they have to balance that location in support of emergency services, they have to balance that
requirement against the risk that location information will be requirement against the risk that location information will be
disclosed to an unauthorized party. The use of location disclosed to an unauthorized party. The use of location
configuration protocols inherently introduces some risk that an configuration protocols inherently introduces some risk that an
entity other than the target will be able to masquerade as the target entity other than the device will be able to masquerade as the device
(e.g., another host behind the same NAT or malicious software on the (e.g., another host behind the same NAT or malicious software on the
host) [9]. In some cases, the location provider may not authorize host) [13]. In some cases, the location provider may not authorize
the target itself to access precise location. At the same time, the device itself to access precise location. At the same time,
because endpoints can roam between networks, it is not generally because endpoints can roam between networks, it is operationally
possible to have strong client authentication for LCPs. difficult to have strong client authentication for LCPs.
Using of rough location to support emergency calling enables a Using of rough location to support emergency calling enables a
location provider to provide low-precision location with low location provider to provide low-precision location with low
assurance (e.g., without client authentication)and high-precision assurance (e.g., without client authentication)and high-precision
location with higher assurance. Because lower-precision location location with higher assurance. Because lower-precision location
generally has lower value -- to location providers and LBS providers generally has lower value -- to location providers and LBS providers
as a commercial asset, and to targets as private information -- this as a commercial asset, and to devices as private information -- this
trade-off allows a location provider to avoid the cost of protecting trade-off allows a location provider to avoid the cost of protecting
location with high-assurance access controls when this location has location with high-assurance access controls when this location has
low value. low value.
However, in order to support emergency services, location providers However, in order to support emergency services, location providers
cannot provide only low-precision location; they also have to provide cannot provide only low-precision location; they also have to provide
PSAPs with access to high-precision location information. Because PSAPs with access to high-precision location information. Because
PSAPs require high-precision location for emergency response, a PSAPs require high-precision location for emergency response, a
location provider that normally provides imprecise location to location provider that normally provides imprecise location to
clients MUST also provide them a location URI that a PSAP can use to clients MUST also provide them a location URI that a PSAP can use to
obtain high-precision location. This constraint means that the obtain high-precision location. This constraint means that the
provided URI MUST have either no access control at all or a policy provided URI MUST have either no access control at all or a policy
that allows access by appropriate PSAPs and other emergency response that allows access by appropriate PSAPs and other emergency response
systems, e.g., ESRPs. That is, if such a location URI is access systems, e.g., ESRPs. That is, if such a location URI is access
controlled, then the location provider MUST be able to authenticate controlled, then the location provider MUST be able to authenticate
requests from PSAPs. requests from PSAPs.
The use of location by reference introduces some risk that the The use of location by reference introduces some risk that the
reference will be used by an attacker to gain unauthorized access to reference will be used by an attacker to gain unauthorized access to
the target's location. These risks are not specific to emergency the device's location. These risks are not specific to emergency
service, however; general risks and mitigations for location by service, however; general risks and mitigations for location by
reference are discussed in [10] reference are discussed in [14]
As described in Section 3.1 above, the location provider choosing to As described in Section 4 above, the location provider choosing to
provide a less precise location than a known location has a provide a less precise location than a known location has a
significant amount of choice in deciding which location to provide: significant amount of choice in deciding which location to provide:
Any location that contains the known location and is in the same Any location that contains the known location and is in the same
filter region will do. When the provider is reducing precision for filter region will do. When the provider is reducing precision for
privacy purposes, there is a some privacy benefit to choosing a privacy purposes, there is a some privacy benefit to choosing a
random location meeting these criteria. If a watcher is interested random location meeting these criteria. If a watcher is interested
in whether or not the endpoint is moving, an imprecise location may in whether or not the endpoint is moving, an imprecise location may
still reveal that fact if it is constant when the endpoint is at still reveal that fact if it is constant when the endpoint is at
rest. If the provided location is randomized each time it is rest. If the provided location is randomized each time it is
provided, then the watcher is unable to obtain even this level of provided, then the watcher is unable to obtain even this level of
information. An algorithm for securely fuzzing a target's location information. An algorithm for securely fuzzing a device's location
can be found in [11]; for emergency services, the additional can be found in [15]; for emergency services, the additional
constraint must be added that the fuzzed location must remain in the constraint must be added that the fuzzed location must remain in the
same filter region as the original. same filter region as the original.
7. IANA Considerations 8. IANA Considerations
This document requests that IANA register a new PIDF-LO 'method' This document requests that IANA register a new PIDF-LO 'method'
token in the registry defined by RFC 4119 [5] token in the registry defined by RFC 4119 [5]
area-representative: Location chosen as a representative of a region area-representative: Location chosen as a representative of a region
in which the target is located; may not be the target's location. in which the device is located; may not be the device's location.
8. References 9. References
8.1. Normative References 9.1. Normative References
[1] Rosen, B. and J. Polk, "Best Current Practice for [1] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-15 (work in progress), July 2010. draft-ietf-ecrit-phonebcp-15 (work in progress), July 2010.
[2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
"LoST: A Location-to-Service Translation Protocol", RFC 5222, "LoST: A Location-to-Service Translation Protocol", RFC 5222,
August 2008. August 2008.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] 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.
[4] Wolf, K., "LoST Service List Boundary Extension", [4] Wolf, K., "LoST Service List Boundary Extension",
draft-ietf-ecrit-lost-servicelistboundary-03 (work in draft-ietf-ecrit-lost-servicelistboundary-04 (work in
progress), February 2010. progress), August 2010.
[5] Peterson, J., "A Presence-based GEOPRIV Location Object [5] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
8.2. Informative References 9.2. Informative References
[6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
for Emergency Calling using Internet Multimedia", for Emergency Calling using Internet Multimedia",
draft-ietf-ecrit-framework-11 (work in progress), July 2010. draft-ietf-ecrit-framework-11 (work in progress), July 2010.
[7] Schulzrinne, H., "Location-to-URL Mapping Architecture and [7] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements",
draft-ietf-ecrit-location-hiding-req-04 (work in progress),
February 2010.
[8] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. Framework", RFC 5582, September 2009.
[8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for [9] Thomson, M. and J. Winterbottom, "Representation of Uncertainty
and Confidence in PIDF-LO",
draft-thomson-geopriv-uncertainty-05 (work in progress),
May 2010.
[10] Thomson, M. and K. Wolf, "Describing Boundaries for Civic
Addresses", draft-thomson-ecrit-civic-boundary-01 (work in
progress), July 2010.
[11] Barnes, R., Thomson, M., and J. Winterbottom, "Location
Configuration Extensions for Policy Management",
draft-barnes-geopriv-policy-uri-01 (work in progress),
May 2010.
[12] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-03 (work in progress), draft-ietf-sipcore-location-conveyance-03 (work in progress),
July 2010. July 2010.
[9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [13] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol: Problem Statement and Requirements", Configuration Protocol: Problem Statement and Requirements",
RFC 5687, March 2010. RFC 5687, March 2010.
[10] Marshall, R., "Requirements for a Location-by-Reference [14] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and [15] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
J. Polk, "Geolocation Policy: A Document Format for Expressing J. Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information", Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress), January 2010. draft-ietf-geopriv-policy-21 (work in progress), January 2010.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Pkwy, Suite 400 9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046 Columbia, MD 21046
 End of changes. 58 change blocks. 
216 lines changed or deleted 328 lines changed or added

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