Internet Engineering Task Force                                R. Barnes
Internet-Draft                                               M. Lepinski
Intended status: Standards Track                        BBN Technologies
Expires: April 10, July 24, 2010                                  January 20, 2010                                  October 7, 2009

       Using Imprecise Location for Emergency Context Resolution
                   draft-ietf-ecrit-rough-loc-00.txt
                   draft-ietf-ecrit-rough-loc-01.txt

Abstract

   Emergency calling works best when precise location is available for
   emergency call routing.  However, there are situations in which a
   location provider is unable or unwilling to provide precise location,
   yet still wishes to enable subscribers to make emergency calls.  This
   document describes the level of location accuracy that providers must
   provide to enable emergency call routing.  In addition, we descibe
   how emergency services and non-emergency services can be invoked by
   an endpoint that does not have access to its precise location.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 10, July 24, 2010.

Copyright Notice

   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   Emergency calling works best when precise location is available for
   emergency call routing.  However, there are situations in which a
   location provider is unable or unwilling to provide precise location,
   yet still wishes to enable subscribers to make emergency calls.  This  Code Components extracted from this document describes the level of location accuracy that providers must
   provide to enable emergency call routing.  In addition, we descibe
   how emergency services
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and non-emergency services can be invoked by
   an endpoint that does not have access to its precise location. are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Determining sufficient location precision  . . . . . . . . . .  4
     3.1.  Location filtering . . . . . . . . . . . . . . . . . . . .  5  6
     3.2.  Constructing location filters  . . . . . . . . . . . . . .  7 10
       3.2.1.  Geodetic service boundaries  . . . . . . . . . . . . .  8
       3.2.2.  Civic service boundaries . . address considerations . . . . . . . . . . . . .  9 11
     3.3.  Maintaining location filters . . . . . . . . . . . . . . .  9 12
     3.4.  Applying location filters  . . . . . . . . . . . . . . . .  9 12
   4.  Requesting emergency and non-emergency services  . . . . . . . 10 13
     4.1.  Emergency calling  . . . . . . . . . . . . . . . . . . . . 10 13
     4.2.  Non-emergency services . . . . . . . . . . . . . . . . . . 11 14
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 17

1.  Introduction

   Information about the location of an emergency caller is a critical
   input to the process of emergency call establshment.  Endpoint
   location is used to determine which Public Safety Answering Point
   (PSAP) should be the destination of the call.  (The entire emergency
   calling process is described in detail in [1] [6] and [2].) [1].)  This process
   is most likely to work properly when the endpoint is provided with
   the most accurate and precise information available about its
   location.  Using location information with maximal precision and
   accuracy minimizes the chance that a call will be mis-routed.  And  In
   addition, when that location is provided to the endpoint, the
   endpoint is able to 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 able to perform emergency call routing
   functions on its own, providing redundancy for network-provided
   functions.

   However, there may be situations in which it is not feasible for
   endpoints to be provided with maximally precise and accurate
   location.  These cases may arise when computing precise location is
   an expensive or time-consuming operation (e.g., in the case of
   wireless triangulation), and location is needed quickly (as quickly, as is often
   the case in emergency situations). situations.  Or they may arise because the
   policy of the a location provider does not allow precise location to be
   provided to the endpoint (e.g. due to privacy considerations). endpoint.  While it is undesirable to use imprecise
   location for emergency call routing, the possibility that precise
   location may not be available to the calling device must be
   accomodated in order to make emergency calling possible in the
   largest possible set of circumstances.

   This document is concerned with imprecise location only in the
   context of routing emergency calls, i.e., for determining the correct
   PSAP to receive a given call (e.g., via a LoST query [3]).  (More generally, [2]).  Depending
   on the provided location information will be needed to the structure of the local emergency service network, the
   location information provided to the endpoint may also be used to
   route the call to an entity that is authorized to request precise
   location, e.g., an Emergency Services Routing Proxy.) Proxy.  The
   requirements and processes described in this document are the same
   for both cases.

   Location information may also be used in the emergency calling
   framework to direct the dispatch of emergency responders.  This usage
   is treated separately from call routing for purposes of this
   document, and this document does not place requirements on the
   location provided for dispatch (although dispatch, although it should obviously be as
   precise as possible). possible.  The only provision for dispatch in this
   document is a recommendation that the location provider supply
   endpoints with a URI that can be used by a PSAP or other emergency
   authority to obtain a different location for use in dispatch,
   hopefully more precise than the one used for routing.

   This document describes the use of imprecise location information in
   the emergency call routing system.  Section 3 describes how location
   providers can determine the precision necessary to support emergency
   call routing, and how they can use this information to optimize
   location delivery.  Section 4 describes how emergency calls are
   placed in such an environment, and how non-emergency services can be
   invoked when precise location is not available to the endpoint by
   value.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [4]. [3].

   We consider in this document patterns of interaction as described in
   [1].
   [6].  The two main parties of interest are endpoints and location
   providers.  Endpoints are hosts connected to the Internet that
   originate emergency calls in the emergency calling architecture,
   while location providers are entities that supply location
   information that is used for emergency calling.  In addition, we will
   discuss how these parties interact with the LoST mapping
   infrastructure [7], and with emergency and non-emergency location-
   based service providers.

   For convenience, we say that location information (either information, either in LoST
   queries or in service boundaries) boundaries, is provided "in geodetic form" if
   it is provided in the "geodetic-2d" LoST location profile, and "in
   civic form" if it is provided in the "civic" profile.

3.  Determining sufficient location precision

   A location provider wishing to provide location information usable
   for emergency call routing requires a mechanism for determining when
   a description of location (e.g., a polygon) is precise enough to be
   used for emergency call routing.  This mechanism might be used to
   decide when to terminate a positioning mechanism process that converges over
   time, or to choose a polygon larger than the known location of the
   endpoint (in order to obscure the known location of the endpoint),
   while preserving the utility of the location for emergency call
   routing.

   There are two base three basic requirements for a location to be usable for
   emergency call routing:

   1.  The location SHOULD be sufficiently precise that a LoST request
       with the location and any service URN will return a unique URI
       mapping value.  This may not be possible in all cases, e.g.,
       because of overlapping service boundaries (leading to creating areas that
       do not have a unique mapping) with
       non-unique mappings, or because of positioning limitations (leading
       to insufficient precision). that
       prevent sufficiently precise positioning.

   2.  When the location of the endpoint is known by the provider to
       greater precision than is being provided, the provided location
       MUST return the same mappings from LoST (for LoST, for all service URNs) URNs, as
       the known location.

   3.  When the location of the endpoint is known by the provider to
       greater precision than is being provided, the provided location
       MUST contain the precise location (as a geographic subset).

   In this section, we describe how

   These requirements lead naturally to use the idea of a "location filter" to
   determine whether a given filter".
   A location filter is usable for emergency call
   routing, and how to construct and maintain such a filter.

3.1.  Location filtering

   With each service-to-URI mapping, a LoST query provides a service
   boundary that represents the set collection of locations in which geographical regions satisfying
   the following criteria:

   1.  For any location value that mapping is valid.  A consequence of this is that given a set of service
   boundaries for difference services (say, one mapping
   "urn:service:sos.fire" to "sip:fire@example.com" and one mapping
   "urn:service:sos.police" to "sip:police@example.com"), the
   intersection of those service boundaries is the region in which two
   mappings are valid ("urn:service:sos.fire" maps to
   "sip:fire@example.com" and "urn:service:sos.police" maps to
   "sip:police@example.com").  Outside that area, one or more subset of the
   mappings is invalid.  Said differently, any region contained in an
   intersection uniquely determines mappings a filter region, a
       LoST request for the services used in
   the intersection, and any service will return a unique mapping result.

   2.  Any two locations within the same intersection
   are equivalent for filter region receive the purpose of same
       LoST mapping (i.e., emergency call
   routing).

   A results for all services

   Given a location filter filter, it is thus easy to determine when a set of regions (optionally, each region
   may be assigned given
   location value is sufficiently precise, or to create a list less precise
   version of LoST mappings), as illustrated in Figure 1.
   Each region is the intersection of the service boundaries for all
   services available within the region, and the lists represent the
   mappings that are valid within location that region.  A filter is used to
   determine whether still precise enough.  Namely, a location
   value is useable for emergency call routing in
   the following way:

   1.  The precise enough when if fits within a given filter region,
   and any superset of a location SHOULD value (e.g., a polygon containing a
   point) can be contained in exactly one of the regions in
       the filter.  This guarantees that LoST mappings are unique.

   2.  When the used as a less precise location version of the endpoint is known, the provided location MUST be contained in value as
   long as it still fits within the same region(s) of the filter as
       the known location.  This guarantees region.

   For example, a simple fuzzing algorithm that LoST queries maintains sufficient
   precision for emergency services is to replace a given location value
   with the
       provided location return filter region that contains it.  This way, the same results as those done with server can
   compute the
       known location.

   3.  When filter off-line (as described below), then provision the precise
   location of each possible target by storing a pointer to the endpoint is known, filter
   region that contains the provided
       location MUST contain target's location.

   The remainder of this section discusses the precise concept of location (as
   filtering in more detail, and describes how a geographic
       subset).

   When the regions are bound to lists of URN-URI mappings, the
   resulting filter location server can also be used as
   construct and maintain a cache for LoST mappings; location filter based on information from
   the LoST mappings for mapping infrastructure.

3.1.  Location filtering

   With each service-to-URI mapping, a location are the mappings bound to LoST query provides a service
   boundary that represents the region(s)
   containing it. set of locations in which that mapping
   is valid.  A consequence of this is that given a set of service
   boundaries for different services, the intersection of those service
   boundaries is the region in which two mappings are valid.  If one
   service boundary corresponds to the area where "urn:service:sos.fire"
   is served by "sip:fire@example.com" and another maps
   "urn:service:sos.police" to "sip:police@example.com", then the
   intersection is the are where both of these mappings are valid
   ("urn:service:sos.fire" maps to "sip:fire@example.com" and
   "urn:service:sos.police" maps to "sip:police@example.com").  Outside
   that area, one or more of the mappings is invalid.  So as was
   suggested above, the intersection of two service boundaries defines a
   set of mappings, and any two locations within that intersection are
   equivalent for the purpose of LoST mapping (i.e., emergency call
   routing).

                  Service boundaries for individual services

                urn:service:sos.police    urn:service:sos.fire

                     +-------+                +-------+
                     | A     |                | C     |
                     |       +---+            |   +---+---+
                     |       |   |            | X |       |
                     +---+---+   |            +---+       |
                         |     B |                |     D |
                         +-------+                +-------+

                           |                        |
                           |                        |
                           +-----------+------------+
                                       |
                                       V

                               +-------+
                               | A,C   |
                               |   +---+
                               |   | +---+
                               +---+ |A,D| +---+
                                     +---+ |   |
                                       +---+   |
                                       |   B,D |
                                       +-------+

                        Resulting Location Filter Regions

           Figure 1: Generating a filter from service boundaries

   When the

   The regions in a location filter can thus be constructed by taking
   intersections 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 service boundaries.  Figure 1 shows a simple
   location for purposes filter: Starting with a set of LoST, the provided location MUST contain the known location in
   order to avoid errors if the location is used four service boundaries for other purposes in
   the course
   two different services.  The filter that results from taking
   intersections of an emergency (e.g., if the location is provided these boundaries has three regions:

   1.  A region where police calls are directed to
   first responders for dispatch).  This guarantee also allows the
   endpoint A and fire calls are
       directed to do some course verification that the provided location is
   correct (in order C.

   2.  A region where police calls are directed to prevent very gross errors in routing).  Thus,
   any location that (1) contains the known location A and (2) is
   contained in the same filter region as the known location is
   allowable.  Locations that also fire calls are contained in only one filter
       directed to D.

   3.  A region where police calls are preferred.  Adding randomness directed to B and fire calls are
       directed to D.

   These regions satisfy the provided locations
   may have privacy benefits in some cases, as discussed in the security
   considerations below.

3.2.  Constructing criteria for a location filters

   For simplicity, we assume that the entity performing filtering will
   only be using the filter to test locations contained within because each
   one has a
   particular geographic "coverage area".  (In principle, this coverage
   area could be unique set of mappings and those mappings are valid across
   the entire world, but assuming a more limited coverage
   area allows region.  The service regions for a filter B and C do not overlap --
   there is no place where police calls go to be built more quickly) Given a coverage
   area B and the ability fire calls to act as a LoST client, a location service
   provider can autonomously compute C --
   so there is no (B,C) region.

   More generally, a location filter using region is the
   following algorithm:

   First, intersection of the server must obtain mappings and service
   boundaries for all services and for all points available within the coverage area.  For each
   emergency service URN, the server goes through the following process region.  A filter
   can used to build determine whether a service map: First, the server queries LoST for the
   complete coverage map location is usable for emergency call
   routing in the desired service.  This can following way:

   1.  The location SHOULD be done with
   a LoST <findService> query contained in exactly one of the following form:

           <?xml version="1.0" encoding="UTF-8"?>
           <findService
                xmlns="urn:ietf:params:xml:ns:lost1"
                serviceBoundary="value">
             <location>
               <!-- Coverage Area -->
             </location>
             <service>
               <!-- Service URN -->
             </service>
           </findService>

   If regions in
       the filter.  This guarantees that LoST returns a set of mappings whose service boundaries cover the
   coverage area (i.e., if LoST is configured to return all possible
   matches for the queried location), then the process termintes here.
   The coverage map for this service is are unique.

   2.  When the set precise location of returned service
   boundaries.

   If service boundaries in the LoST response to the above query do not
   cover the location provider's coverage area, then endpoint is known, the provided
       location server
   must perform further queries.  The location included MUST be contained in each query is the difference between same region(s) of the coverage area and filter as
       the current coverage
   map, known location.  This guarantees that is, LoST queries with the coverage area
       provided location return the same results as those done with all currently-known service
   boundaries removed.  The server repeats this process (query, then
   remove service boundaries from the query location, then query again)
   until either (1)
       known location.

   3.  When the coverage area precise location of the endpoint is covered by known, the collected
   service boundaries or (2) LoST returns a <notFound> error.

   After provided
       location MUST contain the precise location server has performed this procedure for each
   service, it will have (as a set of geographic
       subset).

   Filter regions can be deduced constructed from LoST mappings for each service, a
   sample location by intersecting all the service boundaries for
   every point in its coverage region where
   services available at that service is offered.

   The regions in point.  Figure 2 illustrates how the location
   filter are computed separately for region containing the point X is the intersection of the
   service boundaries provided in civic form for police and in geodetic form. fire services that serve X.

   If
   all service boundaries are provided in one form (e.g., if all
   boundaries are provided in geodetic form, even if some are also
   provided in civic form), the server MAY perform also stores the algorithm lists of URN-URI mappings for
   that form.  If both algorithms are being performed, and some each
   region, x then the filter can also be used as a cache for LoST
   mappings; the LoST mappings
   provide both civic for a location are the mappings bound to
   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 geodetic service boundaries, caching the list of services that it returns, along with
   the corresponding service list boundary [4].  The server MUST
   input those then samples
   points within that service list boundary, retrieving mappings to both with
   service boundaries for each service in the civic service list and geodetic computations.

3.2.1.  Geodetic
   intersecting the service boundaries

   The regions in to obtain a new filter region.
   In pseudocode, the location algorithm is as follows:

   Set FILTER = the empty set
   While filter are computed 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 these mappings
   by iterating over URI tuples: 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 URN, let uris(urn) be
   the set of PSAP URIs S in SL
               Perform a LoST <findService> query for that service URN (collected Y and S
                   Set SB = <serviceBoundary> from the
   mappings).  The set of URI tuples LoST response
               If SB is then not provided, return an error
               Else set R = intersection( R, SB(S,Y) )

           Add R to FILTER

   If the cartesian product LoST servers have been provisioned properly then this
   algorithm will terminate successfully.  If LoST mapping do not cover
   part of
   these sets; if the set of servuce URNs is {urn1,...,urnN}, service region, then the
   set <serviceListBoundary> will not
   be returned, and the algorithm will give up after 100 queries.  This
   limit on queries introduces some risk that a small covered area will
   be left out of URI tuples the filter and marked as uncovered; if this is uris(urn1) x ... x uris(urnN).  The server
   computes a
   concern, then the regions in query limit can be increased.

   Of course, if the filter by iterating location server operator has information about
   service boundaries through some channel other than LoST, then the set of
   URI tuples, either
   LoST queries above can be replaced by constructing the set queries to a local store of URI tuples and directly
   iterating, or by using nested iteration through
   mapping information.  The choice of random points can also be guided
   to ensure that all the sets
   uris(urn).

   For each URI tuple, the mapped areas are covered even if there are some
   uncovered areas.  The location server MUST compute the intersection of the can also cache service
   boundaries for the URIs in acquired during the tuple. algorithm to avoid unnecessary LoST
   queries.

3.2.1.  Civic address considerations

   This becomes an entry algorithm actually results in the location filter: The stored region is the intersection of the two filters -- one for geodetic
   service boundaries, boundaries and the corresponding mapping table one for civic service boundaries -- since
   civic and geodetic boundaries cannot be directly compared or
   intersected.  It is RECOMMENDED that location servers always compute
   a geodetic filter for use with emergency services, since the list notion
   of (URN, URI) pairs, where the URIs are the URIs from civic service boundaries have some inherent ambiguity.

   Indeed, the tuple and notion of intersection of civic service boundaries has
   some dependence on the URNs are jurisdiction within which the services used to obtain them from LoST.  (Empty
   filter regions, corresponding to URIs in a tuple with disjoint service boundaries, can of course be discarded.)

3.2.2.
   boundaries are defined.  Civic service boundaries

   As in the case are comprised of geodetic location, regions a
   set of <civicAddress> elements, each defining a set of civic address
   filter
   addresses that are computed based on URI-tuples.  For tuples where all
   mappings have within the same service boundary, namely those that service boundary MUST
   be used as match the filter region for that type.  For all other cases
   (i.e., tuples with different
   civic locations), elements provided.

   When computing the regions intersection of two civic service boundaries, any
   <civicAddress> elements that are shared between the
   filter must two service
   boundaries MUST be computed as included in the intersections of resulting intersection.  When two
   <civicAddress> elements in the locations service boundaries being compared are
   different from each other, then their intersection must be computed
   according to an algorithm that is determined by local addressing standards.

   Note that the resulting filter regions SHOULD still cover the
   location server's coverage area, i.e., there should be a filter
   region that contains every civic address within the coverage area.
   In particular, the server SHOULD NOT use a specific address to
   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
   from both the lists of rules above).  If the server chooses to return creates a PIDF-LO
   document describing a civic address that does not, not contain the precise
   location of the target, then it MUST set the 'method' element of the
   PIDF-LO it returns to value 'area-representative' registered in
   Section 7.

3.3.  Maintaining location filters

   As the LoST mappings that underlie the filter change, the filter will
   need to be updated.  The entity maintaining the filter MUST obtain a
   new mapping for a region when an existing mapping expires.  The
   service boundary from the new mapping is compared to the service
   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
   intersect either the old service boundary or the new service boundary
   will need to be recomputed.  Note that since this operation only
   requires the server to determine if two service boundaries are
   identical, the server need only store a hash of the old boundary (to to
   which it can compare a hash of the new boundary). boundary.

3.4.  Applying location filters

   After constructing a location filter, a location server can use it to
   optimize how it delivers location.  When the location server is using
   a positioning algorithm that grows more accurate with time, the
   filter tells it how long to run the algorithm.  Namely, the algorithm
   can be terminated when the estimated location (that is, an
   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,
   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
   contains the caller's precise location and return that region as the
   caller's location (or location, or some subset that contains the precise
   location). location.

   This caching strategy allows an additional optimization in some
   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
   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
   cache-control headers (e.g., Expires).  However, the location server
   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
   earliest expiry of a LoST mapping used in the filter.

4.  Requesting emergency and non-emergency services

   When a location provider wishes to deliver endpoints location
   information that is below its maximum available precision while still
   supporting emergency calling, it MUST provide to the endpoint both a
   location (by value) that is sufficient for emergency call routing
   (see (as
   defined above) and a location reference (i.e., a URI) that can
   subsequently be used by authorized parties to obtain more precise
   information about the location of the endpoint.  The endpoint then
   can then use both the location value and the location reference to
   request emergency services and other location-based services (LBS) as described below. (LBS).

4.1.  Emergency calling

   The overall procedure for placing an emergency call is indentical identical to
   that described in [1]. [6].  In particular, the endpoint requirements in
   Sections 8 and 9 of [2] [1] still apply to an endpoint that receives
   imprecise location.

   In addition, an endpoint that receives location both by value and by
   reference from its location provider MUST include both the location
   value and the location reference in the SIP INVITE message that
   initiates an emergency call, as specified in [5]. [8].  When the endpoint
   supports LoST, it SHOULD MUST use the location value to obtain a PSAP URI
   for LoST queries (as opposed to before attempting to dereference the location reference).
   reference.  Note that the caller would also have to add the
   "used-for-routing" "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
   precision for routing emergency calls (see Section 3 for techniques
   to ensure the location value is suitable for emergency call routing).

   When a PSAP receives a SIP INVITE that contains both a location value
   and a location reference, if and the value is too imprecise for use in
   dispatch then the PSAP SHOULD dereference the LbyR to obtain more
   precise information.  In turn, the location provided by the location
   provider MUST allow access by all PSAPs whose service boundaries
   overlap with the region served by the location provider.  This means
   that either the provider must supply a reference that can be
   dereferenced by any party, or else the provider must establish
   explicit authentication and authorization relationships with all
   PSAPs in its service area.  It is RECOMMENDED that location providers
   establish similar relationships with other PSAPs in adjoining
   jursidictions -- even if their service regions do not overlap with
   the location provider's -- in case such a PSAP needs access to
   precise location information, for example, if it is acting as a
   backup for one of the location provider's normal PSAPs.

4.2.  Non-emergency services

   Non-emergency LBSs will generally 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.

5.  Acknowledgements

   This document generalizes the concept of "rough location" that was
   originally discussed in the context of the location hiding problem.
   This concept was put forward by Henning Schulzrinne and Andy Newton,
   among many others, in a long-running ECRIT discussion.

6.  Security Considerations

   The use of imprecise location provides a security trade-off for
   location providers.  When location providers are required to provide
   location in support of emergency services, they have to balance that
   requirement against the risk that location information will be
   disclosed to an unauthorized party.  The use of location
   configuration protocols inherently introduces some risk that an
   entity other than the target will be able to masquerade as the target
   (e.g., another host behind the same NAT or malicious software on the
   host) [9].  In some cases, the location provider may not authorize
   the target itself to access precise location.  At the same time,
   because endpoints can roam between networks, it is not generally
   possible to have strong client authentication for LCPs.

   Using of rough location to support emergency calling enables a
   location provider to provide low-precision location with low
   assurance (e.g., of requestor identity) and without client authentication)and high-precision
   location with higher assurance.  The fact that  Because lower-precision location
   generally has lower value -- to location providers and LBS providers
   as a commercial asset, and to targets as private information -- this
   trade-off allows a location provider to avoid the cost of protecting
   location with high-assurance access controls when this location has
   low value.

   However, in order to support emergency services, this expense location providers
   cannot
   be avoided entirely. provide only low-precision location; they also have to provide
   PSAPs with access to high-precision location information.  Because
   PSAPs require high-precision location for emergency response planning, response, a
   location provider that normally provides rough imprecise location to
   clients MUST also provide them a location URI that a PSAP can use to
   obtain high-precision location.  This constraint means that the
   provided URI MUST have either no access control at all or a policy
   that allows access by appropriate PSAPs (and and other emergency response
   systems, e.g., ESRPs). ESRPs.  That is, if such a location URI is access
   controlled, then the location provider MUST be able to
   authenticate requests from PSAPs.

   One reason for a location server to provide location information
   below its maximum precision is to protect the privacy of the target.
   Some location provisioning protocols do not enable the location
   provider to obtain strong assurance of the identity of the location
   recipient; in particular, the location provider may be unable to
   verify that the recipient is the target authenticate
   requests from PSAPs.

   The use of the location being
   provided.  Therefore, there is a by reference introduces some risk that a sufisticated attacker
   might be able to spoof the identifier (e.g.  IP address)
   reference will be used by the
   location provider an attacker to gain unauthorized access to identify the target, and obtain
   the target's
   location in this way.  One way to mitigate this risk is to provide
   only imprecise location information location.  These risks are not specific to the end-point (without
   authentication), emergency
   service, however; general risks and to provide precise information only to trusted
   entities that can authenticate themselves to the mitigations for location provider.
   Additionally, by
   reference are discussed in some deployment scenarios, location providers have
   concerns about the comprimise of endpoint devices.  Providing only
   imprecise location to the endpoint, prevents malware on a comprised
   device from obtaining the precise location of the target. [10]

   As described in Section 3.1 above, the location provider choosing to
   provide a less precise location than a known location has a
   significant amount of choice in deciding which location to provide:
   Any location that contains the known location and is in the same
   filter region will do.  When the provider is reducing precision for
   privacy purposes, there is a signficant some privacy benefit to choosing a
   random location meeting these criteria.  If a watcher is interested
   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
   rest.  If the provided location is randomized each time it is
   provided, then the watcher is unable to obtain even this level of
   information.  An algorithm for securely fuzzing a target's location
   can be found in [11]; for emergency services, the additional
   constraint must be added that the fuzzed location must remain in the
   same filter region as the original.

7.  IANA Considerations

   This document requests that IANA register a new PIDF-LO 'method'
   token in the registry defined by RFC 4119 [6] [5]

   area-representative:  Location chosen as a representative of a region
      in which the target is located; may not be the target's location location.

8.  References

8.1.  Normative References

   [1]   Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
        for Emergency Calling using Internet Multimedia",
        draft-ietf-ecrit-framework-10 (work in progress), July 2009.

   [2]  Rosen, B. and J. Polk, "Best Current Practice for
         Communications Services in support of Emergency Calling",
        draft-ietf-ecrit-phonebcp-13
         draft-ietf-ecrit-phonebcp-14 (work in progress), July 2009.

   [3] January 2010.

   [2]   Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
         "LoST: A Location-to-Service Translation Protocol", RFC 5222,
         August 2008.

   [4]

   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [5]  Polk, J. and B. Rosen, "Location Conveyance for the Session
        Initiation Protocol", draft-ietf-sip-location-conveyance-13

   [4]   Wolf, K., "Location-to-Service Translation Protocol (LoST)
         Extension: ServiceListBoundary",
         draft-ietf-ecrit-lost-servicelistboundary-01 (work in
         progress), March November 2009.

   [6]

   [5]   Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

8.2.  Informative References

   [6]   Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
         for Emergency Calling using Internet Multimedia",
         draft-ietf-ecrit-framework-10 (work in progress), July 2009.

   [7]   Schulzrinne, H., "Location-to-URL Mapping Architecture and
         Framework", draft-ietf-ecrit-mapping-arch-04 (work in
         progress), March 2009.

   [8]   Polk, J. and B. Rosen, "Location Conveyance for the Session
         Initiation Protocol", draft-ietf-sipcore-location-conveyance-01
         (work in progress), July 2009.

   [9]   Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
         Configuration Protocol; Problem Statement and Requirements",
         draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009.

   [10]  Marshall, R., "Requirements for a Location-by-Reference
         Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work in
         progress), November 2009.

   [11]  Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
         J. Polk, "Geolocation Policy: A Document Format for Expressing
         Privacy Preferences for Location Information",
         draft-ietf-geopriv-policy-21 (work in progress), January 2010.

Authors' Addresses

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy, Suite 400
   Columbia, MD  21046
   USA

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com

   Matt Lepinski
   BBN Technologies
   10 Moulton St
   Cambridge, MA  02138
   USA

   Phone: +1 617 873 5939
   Email: mlepinski@bbn.com