draft-ietf-ecrit-rough-loc-01.txt   draft-ietf-ecrit-rough-loc-02.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: July 24, 2010 January 20, 2010 Expires: January 28, 2011 July 27, 2010
Using Imprecise Location for Emergency Context Resolution Using Imprecise Location for Emergency Context Resolution
draft-ietf-ecrit-rough-loc-01.txt draft-ietf-ecrit-rough-loc-02.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
an endpoint that does not have access to its precise location. an endpoint that does not have access to its precise location.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 28, 2011.
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 July 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Determining sufficient location precision . . . . . . . . . . 4 3. Determining sufficient location precision . . . . . . . . . . 4
3.1. Location filtering . . . . . . . . . . . . . . . . . . . . 6 3.1. Location filtering . . . . . . . . . . . . . . . . . . . . 6
3.2. Constructing location filters . . . . . . . . . . . . . . 10 3.2. Constructing location filters . . . . . . . . . . . . . . 10
3.2.1. Civic address considerations . . . . . . . . . . . . . 11 3.2.1. Civic address considerations . . . . . . . . . . . . . 11
3.3. Maintaining location filters . . . . . . . . . . . . . . . 12 3.3. Maintaining location filters . . . . . . . . . . . . . . . 12
skipping to change at page 16, line 19 skipping to change at page 16, line 19
area-representative: Location chosen as a representative of a region area-representative: Location chosen as a representative of a region
in which the target is located; may not be the target's location. in which the target is located; may not be the target's location.
8. References 8. References
8.1. Normative References 8.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-14 (work in progress), January 2010. draft-ietf-ecrit-phonebcp-15 (work in progress), July 2010.
[2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
"LoST: A Location-to-Service Translation Protocol", RFC 5222, "LoST: A Location-to-Service Translation Protocol", RFC 5222,
August 2008. August 2008.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Wolf, K., "Location-to-Service Translation Protocol (LoST) [4] Wolf, K., "LoST Service List Boundary Extension",
Extension: ServiceListBoundary", draft-ietf-ecrit-lost-servicelistboundary-03 (work in
draft-ietf-ecrit-lost-servicelistboundary-01 (work in progress), February 2010.
progress), November 2009.
[5] Peterson, J., "A Presence-based GEOPRIV Location Object [5] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
8.2. Informative References 8.2. Informative References
[6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework [6] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
for Emergency Calling using Internet Multimedia", for Emergency Calling using Internet Multimedia",
draft-ietf-ecrit-framework-10 (work in progress), July 2009. draft-ietf-ecrit-framework-11 (work in progress), July 2010.
[7] Schulzrinne, H., "Location-to-URL Mapping Architecture and [7] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-04 (work in Framework", RFC 5582, September 2009.
progress), March 2009.
[8] Polk, J. and B. Rosen, "Location Conveyance for the Session [8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
Initiation Protocol", draft-ietf-sipcore-location-conveyance-01 the Session Initiation Protocol",
(work in progress), July 2009. draft-ietf-sipcore-location-conveyance-03 (work in progress),
July 2010.
[9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements", Configuration Protocol: Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009. RFC 5687, March 2010.
[10] Marshall, R., "Requirements for a Location-by-Reference [10] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work in Mechanism", RFC 5808, May 2010.
progress), November 2009.
[11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and [11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
J. Polk, "Geolocation Policy: A Document Format for Expressing J. Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information", Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress), January 2010. draft-ietf-geopriv-policy-21 (work in progress), January 2010.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
 End of changes. 13 change blocks. 
29 lines changed or deleted 21 lines changed or added

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