draft-ietf-ecrit-rough-loc-04.txt   draft-ietf-ecrit-rough-loc-05.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: September 30, 2011 March 29, 2011 Expires: January 17, 2013 July 16, 2012
Using Imprecise Location for Emergency Context Resolution Using Imprecise Location for Emergency Context Resolution
draft-ietf-ecrit-rough-loc-04.txt draft-ietf-ecrit-rough-loc-05.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 describe
how emergency services and non-emergency services can be invoked by additional rules for networks and endpoints to enable emergency
an endpoint that does not have access to its precise location. calling by endpoints that do not have access to precise location.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 30, 2011. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
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. Privileged LoST Servers . . . . . . . . . . . . . . . . . 12
4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12 4.5. Maintaining Location Filters . . . . . . . . . . . . . . . 13
5. Requesting Emergency and Non-emergency Services . . . . . . . 13 4.6. Applying Location Filters . . . . . . . . . . . . . . . . 13
5.1. Emergency Calling . . . . . . . . . . . . . . . . . . . . 14 5. Additional Requirements for Networks and Endpoints . . . . . . 14
5.2. Non-emergency Services . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 [5] 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
skipping to change at page 11, line 38 skipping to change at page 11, line 38
queries. queries.
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
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
skipping to change at page 12, line 19 skipping to change at page 12, line 17
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 device, 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 8. Section 8.
4.4. Maintaining Location Filters If the above procedures are not workable for a given scenario, then
the server MAY fall back to geocoding of service boundaries, in which
case the above procedures for geodetic location can be used.
Geocoding may also be necessary in cases where the location of the
target is known as a civic address with limited granularity, with
which service boundaries do not align. For instance, the target's
location may be known to the level of a postal code, but postal code
regions may span multiple PSAP service areas or filter regions. In
such cases, the server MAY geocode the target's location to obtain a
rough geodetic position, which can be dealt with as discussed in
Section 4.6 below.
4.4. Privileged LoST Servers
In certain scenarios, it may be possible that some LoST servers are
authorized to access more precise location information than networks
are willing to reveal to endpoints. For example, a network operator
might allow a LoST server operated by a national authority to access
an endpoint's precise location, even if it does not allow the
endpoint access to this information.
In these situations, the precision required for emergency services
routing is different than in the base case considered above. Rather
than needing location precise enough to identify a given PSAP, the
location value provided to the endpoint only needs to be precise
enough to route the LoST request through the mapping infrastructure
to a LoST server that is authorized to access the endpoint's precise
location. Once the request reaches that server, the server can
request more precise location information and use that information to
route the request further.
Indeed, such privileged LoST server could even be operated by the
network itself. In this case, if an endpoint complies with
requirement ED-52 in [1], it will send its LoST request directly to
the network-provided LoST server, which can look up the client's
location and return mappings. However, it is possible that clients
will use an alternative LoST resolver, so it is still beneficial to
provide a rough location that can route the request to a nearby
privileged LoST server.
In cases where a network allows one or more privileged LoST servers
to access precise location information, the network MAY designate a
location that is precise enough to reach one of these LoST servers as
precise enough for emergency call routing.
This document does not specify how these privileged LoST servers
could obtain more precise location information from network
operators. One possible solution is to extend LoST to carry a
location reference in addition to a location by value.
4.5. 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.
4.5. Applying Location Filters 4.6. 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. How this is done depends on optimize how it delivers location. How this is done depends on
whether the location server is trying to reduce the precision of a whether the location server is trying to reduce the precision of a
known precise location, or trying to determine whether an imprecise known precise location, or trying to determine whether an imprecise
position is good enough for emergency services. position is good enough for emergency services.
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
skipping to change at page 13, line 38 skipping to change at page 14, line 38
between these two use cases. When precise location is known, the between these two use cases. When precise location is known, the
rough location that is returned MUST be contained within a single rough location that is returned MUST be contained within a single
filter region; otherwise, there will be an increased risk of mis- filter region; otherwise, there will be an increased risk of mis-
routing. When the location server starts with imprecise location, it routing. When the location server starts with imprecise location, it
may choose location values that are not entirely within one filter may choose location values that are not entirely within one filter
region. The distribution of the imprecise location value among region. The distribution of the imprecise location value among
filter regions corresponds to the risk that LoST routing will provide filter regions corresponds to the risk that LoST routing will provide
incorrect information, so the choice of location value should balance incorrect information, so the choice of location value should balance
the risk of incorrect routing against the additional time needed to the risk of incorrect routing against the additional time needed to
obtain more precise location (which can translate to a delay in call 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 setup). In this case, it may not even be possible for a location
location server to return a location value that is entirely within a server to return a location value that is entirely within a single
single filter region. filter region.
5. Requesting Emergency and Non-emergency Services 5. Additional Requirements for Networks and Endpoints
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 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 MUST provide a location reference (i.e., a URI)
subsequently be used by authorized parties to obtain more precise that can subsequently be used by authorized parties to obtain more
information about the location of the endpoint. The endpoint then precise information about the location of the endpoint. The endpoint
can then use both the location value and the location reference to then can then use both the location value and the location reference
request emergency services and other location-based services (LBS). to request emergency services and other location-based services
(LBS).
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 [10]. this policy is described in [9].
5.1. Emergency Calling ED-84: When an endpoint has access to location both by value and by
reference, it MUST include both forms of geolocation in the SIP
INVITE message initiating an emergency call, each in a separate
Geolocation header. The endpoint SHOULD include a Geolocation-
Routing header with the value "yes".
AN-30: Networks providing imprecise location MUST also provide
location by reference.
AN-31: Networks providing imprecise location SHOULD provide DHCP-
based LoST discovery, advertising a LoST server that is authorized
to dereference location URIs issued by the network's LIS.
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 [5]. 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, with the above modification (use of the location
URI in LoST).
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 [11]. When the endpoint initiates an emergency call, as specified in [10]. Note that this
supports LoST, it MUST use the location value to obtain a PSAP URI
for LoST queries before attempting to dereference the location
reference. Note that the caller would also have to add the "used-
for-routing" parameter to the geolocation header that points to the
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
and a location reference, and the value is too imprecise for use in and a location reference, and the value is too imprecise for use in
dispatch then the PSAP SHOULD dereference the LbyR to obtain more dispatch then the PSAP SHOULD dereference the LbyR to obtain more
precise information. In turn, the location provided by the location precise information. In turn, the location provided by the location
provider MUST allow access by all PSAPs whose service boundaries provider SHOULD allow access by all PSAPs whose service boundaries
overlap with the region served by the location provider. This means overlap with the region served by the location provider. This means
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.
5.2. Non-emergency Services
Non-emergency LBSs may require more precise information than is
required for emergency call routing. Therefore, when requesting a
non-emergency LBS, the endpoint SHOULD include the location reference
provided by its location provider, and MAY additionally provide the
location value. If the provided location value is not sufficiently
precise to deliver the requested service, then the LBS provider
should then dereference the location value to request location
information of sufficient precision from the location provider. If
the dereference fails, then the request for service may fail as well.
Note that when the location reference provided by the location
provider is access-controled, this dereference may require a pre-
existing authentication and authorization agreement between the LBS
provider and the location provider. In such a case, the endpoint may
not know whether a given non-emergency service is authorized to
obtain the endpoint's precise location using the location reference.
The endpoint is always capable of requesting services without knowing
whether they are authorized; in this way, the endpoint can discover
authorized services by trial and error. In order to simplify this
process, a location provider may supply the endpoint with references
to authorized service providers, although there is currently no
standard protocol for this transaction.
6. 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. Thanks to among many others, in a long-running ECRIT discussion. Thanks to
Hannes Tschofenig and Martin Thomson for detailed reviews of this Hannes Tschofenig and Martin Thomson for detailed reviews of this
document. document.
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) [12]. In some cases, the location provider may not authorize host) [11]. 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 36 skipping to change at page 17, line 19
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 [13] reference are discussed in [12]
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 [14]; for emergency services, the additional can be found in [13]; 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 [4] 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.
skipping to change at page 17, line 15 skipping to change at page 18, line 4
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 [4] 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-17 (work in progress), March 2011. draft-ietf-ecrit-phonebcp-20 (work in progress),
September 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] Peterson, J., "A Presence-based GEOPRIV Location Object [4] 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
[5] 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", RFC 6443,
draft-ietf-ecrit-framework-12 (work in progress), October 2010. December 2011.
[6] 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), RFC 6444, January 2012.
February 2010.
[7] 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.
[8] 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-06 (work in progress), draft-thomson-geopriv-uncertainty-07 (work in progress),
March 2011. March 2012.
[9] Thomson, M. and K. Wolf, "Describing Boundaries for Civic
Addresses", draft-thomson-ecrit-civic-boundary-02 (work in
progress), January 2011.
[10] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, [9] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig,
"Location Configuration Extensions for Policy Management", "Location Configuration Extensions for Policy Management",
draft-barnes-geopriv-policy-uri-02 (work in progress), draft-barnes-geopriv-policy-uri-02 (work in progress),
November 2010. November 2010.
[11] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for [10] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", the Session Initiation Protocol", RFC 6442, December 2011.
draft-ietf-sipcore-location-conveyance-06 (work in progress),
February 2011.
[12] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [11] 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.
[13] Marshall, R., "Requirements for a Location-by-Reference [12] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[14] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and [13] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris,
J. Polk, "Geolocation Policy: A Document Format for Expressing J., and M. Thomson, "Geolocation Policy: A Document Format for
Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-23 (work in progress), March 2011. draft-ietf-geopriv-policy-26 (work in progress), June 2012.
[14] Thomson, M. and K. Wolf, "Describing Boundaries for Civic
Addresses", draft-thomson-ecrit-civic-boundary-02 (work in
progress), January 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. 33 change blocks. 
93 lines changed or deleted 121 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/