draft-ietf-ecrit-rough-loc-03.txt   draft-ietf-ecrit-rough-loc-04.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: February 17, 2011 August 16, 2010 Expires: September 30, 2011 March 29, 2011
Using Imprecise Location for Emergency Context Resolution Using Imprecise Location for Emergency Context Resolution
draft-ietf-ecrit-rough-loc-03.txt draft-ietf-ecrit-rough-loc-04.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 February 17, 2011. This Internet-Draft will expire on September 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Location Precision Requirements . . . . . . . . . . . . . . . 5 3. Location Precision Requirements . . . . . . . . . . . . . . . 5
4. Location Filtering . . . . . . . . . . . . . . . . . . . . . . 5 4. Location Filtering . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Filter Region for a Known Location . . . . . . . . . . . . 6 4.1. Filter Region for a Known Location . . . . . . . . . . . . 6
4.2. Constructing a Location Filter . . . . . . . . . . . . . . 8 4.2. Constructing a Location Filter . . . . . . . . . . . . . . 8
4.3. Civic Address Considerations . . . . . . . . . . . . . . . 11 4.3. Civic Address Considerations . . . . . . . . . . . . . . . 11
4.4. Maintaining Location Filters . . . . . . . . . . . . . . . 12 4.4. Maintaining Location Filters . . . . . . . . . . . . . . . 12
4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12 4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12
5. Requesting Emergency and Non-emergency Services . . . . . . . 14 5. Requesting Emergency and Non-emergency Services . . . . . . . 13
5.1. Emergency Calling . . . . . . . . . . . . . . . . . . . . 14 5.1. Emergency Calling . . . . . . . . . . . . . . . . . . . . 14
5.2. Non-emergency Services . . . . . . . . . . . . . . . . . . 15 5.2. Non-emergency Services . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 [5] 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. accuracy minimizes the chance that a call will be mis-routed.
When location is provided to the endpoint, the endpoint is able to When location is provided to the endpoint, the endpoint is able to
verify that the location is correct (to the extent of the endpoint's verify that the location is correct (to the extent of the endpoint's
knowledge of its own location) prior to an emergency call, and is knowledge of its own location) prior to an emergency call, and is
able to perform emergency call routing functions on its own, able to perform emergency call routing functions on its own,
providing redundancy for network-provided functions. Moreover, when providing redundancy for network-provided functions. Moreover, when
skipping to change at page 4, line 11 skipping to change at page 4, line 11
services. 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. Detailed requirements are discussed in [7] for both cases. Detailed requirements are discussed in [6]
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,
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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 [5]. 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 [8], and with emergency and non-emergency location- infrastructure [7], 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.
The term "precision" is not used in a quantitative sense in this The term "precision" is not used in a quantitative sense in this
document. In general, the "precision" of a location value is document. In general, the "precision" of a location value is
determined by the size of its uncertainty region. [9] Higher determined by the size of its uncertainty region. [8] Higher
precision values have small uncertainty regions and lower precision precision values have small uncertainty regions and lower precision
values have larger uncertainty regions. The notion of "sufficient values have larger uncertainty regions. The notion of "sufficient
precision for emergency services is defined in Section 3 precision for emergency services is defined in Section 3
3. Location Precision Requirements 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
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Resulting filter region Resulting filter region
(police=>A, fire=>B, ambulance=>C) (police=>A, fire=>B, ambulance=>C)
Figure 1: Generating a Filter Region from a Sample Point Figure 1: Generating a Filter Region from a Sample Point
In pseudocode form, algorithm for constructing a filter region from a In pseudocode form, algorithm for constructing a filter region from a
point is as follows: point is as follows:
function filterRegion(X): function filterRegion(X):
Set REGION = the world Set REGION = the world
Perform a LoST <listServicesByLocation> query for X For each service URN S in the urn:service:sos namespace
Set SL = <serviceList> from LoST <listServicesByLocationResponse> Perform a LoST <findService> query for Y and S
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 If LoST returned an error
Continue Continue
Set SB = <serviceBoundary> from LoST <findServiceResponse> Set SB = <serviceBoundary> from LoST <findServiceResponse>
If SB is not provided, throw an error If SB is not provided, throw an error
Else set REGION = intersection( REGION, SB ) Else set REGION = intersection( REGION, SB )
If <listServicesByLocationResponse> has a <serviceListBoundary>
Set SLB = <serviceListBoundary>
from LoST <listServicesByLocationResponse>
Set REGION = intersection( REGION, SLB )
Return REGION 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 It is important that the filter take into account all emergency
services available in over the coverage area of the LIS. (That is, services available in over the coverage area of the LIS. (That is,
the services listed in the LoST serviceList elements.) The feature the services listed in the LoST serviceList elements.) The feature
is necessary in order to ensure that calls to all available emergency is necessary in order to ensure that calls to all available emergency
services can be routed correctly using rough location values provided services can be routed correctly using rough location values provided
by the filter. by the filter.
While in principle, a location server could execute this algorithm to While in principle, a location server could execute this algorithm to
compute a fresh filter region on each query, it is much more compute a fresh filter region on each query, it is much more
efficient to use the offline algorithm for computing an entire efficient to use the offline algorithm for computing an entire
skipping to change at page 11, line 50 skipping to change at page 11, line 39
4.3. 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 Considerations around civic service boundaries are discussed in
detail in [10] detail in [9]
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 14, line 26 skipping to change at page 14, line 16
This arrangement allows the client to provide rough location (by This arrangement allows the client to provide rough location (by
value) to any entity, and to provide precise location (by reference) value) to any entity, and to provide precise location (by reference)
to authorized parties. An assumption of this model, of course, is to authorized parties. An assumption of this model, of course, is
that emergency authorities are authorized by the location provider to that emergency authorities are authorized by the location provider to
receive precise location. Location providers may also authorize receive precise location. Location providers may also authorize
other entities to receive precise location information (e.g., other entities to receive precise location information (e.g.,
commercial services that have agreed to pay for location). commercial services that have agreed to pay for location).
Authorization policy for location URIs is set by the referenced Authorization policy for location URIs is set by the referenced
location server; a mechanism for clients to request information about location server; a mechanism for clients to request information about
this policy is described in [11]. this policy is described in [10].
5.1. Emergency Calling 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 [5]. 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 [12]. When the endpoint initiates an emergency call, as specified in [11]. 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 16, line 15 skipping to change at page 16, line 4
7. 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 device will be able to masquerade as the device 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) [13]. In some cases, the location provider may not authorize host) [12]. In some cases, the location provider may not authorize
the device 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 operationally because endpoints can roam between networks, it is operationally
difficult 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 devices as private information -- this as a commercial asset, and to devices as private information -- this
skipping to change at page 16, line 47 skipping to change at page 16, line 36
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 device'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 [14] reference are discussed in [13]
As described in Section 4 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 device's location information. An algorithm for securely fuzzing a device's location
can be found in [15]; for emergency services, the additional can be found in [14]; 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.
8. 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 [4]
area-representative: Location chosen as a representative of a region area-representative: Location chosen as a representative of a region
in which the device is located; may not be the device's location. in which the device is located; may not be the device's location.
9. References 9. References
9.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-17 (work in progress), March 2011.
[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] Peterson, J., "A Presence-based GEOPRIV Location Object
draft-ietf-ecrit-lost-servicelistboundary-04 (work in
progress), August 2010.
[5] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
9.2. Informative References 9.2. Informative References
[6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework [5] 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-12 (work in progress), October 2010.
[7] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. [6] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements", Kuett, "Location Hiding: Problem Statement and Requirements",
draft-ietf-ecrit-location-hiding-req-04 (work in progress), draft-ietf-ecrit-location-hiding-req-04 (work in progress),
February 2010. February 2010.
[8] Schulzrinne, H., "Location-to-URL Mapping Architecture and [7] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. Framework", RFC 5582, September 2009.
[9] Thomson, M. and J. Winterbottom, "Representation of Uncertainty [8] Thomson, M. and J. Winterbottom, "Representation of Uncertainty
and Confidence in PIDF-LO", and Confidence in PIDF-LO",
draft-thomson-geopriv-uncertainty-05 (work in progress), draft-thomson-geopriv-uncertainty-06 (work in progress),
May 2010. March 2011.
[10] Thomson, M. and K. Wolf, "Describing Boundaries for Civic [9] Thomson, M. and K. Wolf, "Describing Boundaries for Civic
Addresses", draft-thomson-ecrit-civic-boundary-01 (work in Addresses", draft-thomson-ecrit-civic-boundary-02 (work in
progress), July 2010. progress), January 2011.
[11] Barnes, R., Thomson, M., and J. Winterbottom, "Location [10] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig,
Configuration Extensions for Policy Management", "Location Configuration Extensions for Policy Management",
draft-barnes-geopriv-policy-uri-01 (work in progress), draft-barnes-geopriv-policy-uri-02 (work in progress),
May 2010. November 2010.
[12] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for [11] 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-06 (work in progress),
July 2010. February 2011.
[13] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [12] 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.
[14] Marshall, R., "Requirements for a Location-by-Reference [13] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[15] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and [14] 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-23 (work in progress), March 2011.
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
USA USA
Phone: +1 410 290 6169 Phone: +1 410 290 6169
 End of changes. 38 change blocks. 
61 lines changed or deleted 45 lines changed or added

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