GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Corporation
Expires: January 9, 2011 July 8, 2010
Specifying Location Quality Requirements in Location Protocols
draft-thomson-geopriv-location-quality-06
Abstract
Parameters that define the expected quality of location information
are defined for use in location protocols. These parameter can be
used by a requester to indicate to a Location Server quality
requirements for the location information it requests. If
applicable, the Location Server is able to use this information to
control how location information is determined. An optional
indication of whether the quality requirements were met is defined to
be provided by the Location Server alongside location information.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 9, 2011.
Copyright Notice
Copyright (c) 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. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Thomson & Winterbottom Expires January 9, 2011 [Page 1]
Internet-Draft Location Quality July 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 4
2. Location Quality Operation . . . . . . . . . . . . . . . . . . 4
3. Location Quality Objects . . . . . . . . . . . . . . . . . . . 5
3.1. Location Quality Request . . . . . . . . . . . . . . . . . 5
3.1.1. Maximum Uncertainty . . . . . . . . . . . . . . . . . 5
3.1.2. Required Civic Elements . . . . . . . . . . . . . . . 7
3.1.3. Maximum Age . . . . . . . . . . . . . . . . . . . . . 8
3.2. Location Quality Indication . . . . . . . . . . . . . . . 8
4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 11
6.2. XML Schema Registration for Location Quality Schema . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Thomson & Winterbottom Expires January 9, 2011 [Page 2]
Internet-Draft Location Quality July 2010
1. Introduction
Location determination methods produce results of varying accuracy.
In general, the accuracy of location information increases as the
effort expended in generating the information increases. Accuracy is
the primary aspect of the quality of location information that is
relevant to a Location Recipient (LR). Other aspects of quality can
also be significant, such as the currency of the data.
Means for expressing the quality of location information is outlined
in [RFC5491] and [I-D.thomson-geopriv-uncertainty]. An entity
requesting location information of a Location Server (LS) is unable
to specify the quality of the location that it ultimately receives.
This is inefficient because an LS either provides location
information that is inadequate for the intended task; or the LS could
waste resources generating location information that is of
eccessively high quality.
This document defines XML objects that can be added to any protocol
that provides location information. These elements provide the
ability to communicate location quality requirements to an LS. These
requirements specify a desired uncertainty at a certain confidence,
plus the maximum acceptable age where location information is stored.
Guidelines for deterministically evaluating location information
against these rules are provided.
This document provides semantics, examples and security
considerations for the HELD protocol
[I-D.ietf-geopriv-http-location-delivery]. The parameters and
procedures described in this document are applicable to HELD when
used either as a location configuration protocol (LCP) [RFC5687] or
as a location dereference protocol [RFC5808]. Application of the
parameters described in this document to other protocols is not
described, but is relatively trivial for protocols that are able to
convey XML.
Location quality requirements provide information that an LS can use
in deciding how to generate location information, if the LS has that
capacity, directly or otherwise. This is the case for a Location
Information Server (LIS) and the HELD protocol.
Specifying location quality requirements ensures that a Location
Receipient (LR) receives information that is suited to their needs.
It also provides information that any Location Generator (LG) can use
to better decide how location information is generated. This
provides advantages to both requester and source of the information.
In one example, a LIS that is able to provide a location estimate
with uncertainty that matches the requested requirements might be
Thomson & Winterbottom Expires January 9, 2011 [Page 3]
Internet-Draft Location Quality July 2010
able to provide that response before the time indicated within the
time indicated in the request (the "responseTime").
This document also defines an object that can be used by the LS to
indicate if the location quality meets the requirements. These
parameters can be used by a Location Recipient to ensure that the
location is of adequate quality without requiring specific checking
without having to examine the location object. Response parameters
are an optional optimisation; the presence of a quality indication in
the response also indicates that the LS has understood the location
quality requirements.
1.1. Conventions used in this document
Terms and procedures relating to uncertainty and confidence are taken
from [I-D.thomson-geopriv-uncertainty]. Familiarity with terminology
outlined in [RFC5687] and [I-D.ietf-geopriv-arch] is also assumed.
The term Location Server (LS) is used as a generic label, since these
paramters apply in all cases where location information is served to
a requesting entity. From the perspective of this document, the LS
could be a Location Information Server (LIS). Similarly, the term
Location Recipient (LR) is used to refer to the requester of location
information, which could be a Device or Target for HELD.
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 [RFC2119].
2. Location Quality Operation
Location quality parameters are provided by a Location Recipient in a
location request message. Figure 1 shows an example HELD message
where a Device requests location information of a specified quality.
See RFCXXXX.
END 6.2. XML Schema Registration for Location Quality Schema This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:geopriv:lq Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). Schema: The XML for this schema can be found in Section 4 of this document. 7. References 7.1. Normative References [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-16 (work in progress), August 2009. Thomson & Winterbottom Expires January 9, 2011 [Page 12] Internet-Draft Location Quality July 2010 [I-D.thomson-geopriv-confidence] Thomson, M., "Expressing Confidence in a Location Object", draft-thomson-geopriv-confidence-02 (work in progress), January 2010. [I-D.thomson-geopriv-uncertainty] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", draft-thomson-geopriv-uncertainty-05 (work in progress), May 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. 7.2. Informative References [I-D.ietf-geopriv-arch] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", draft-ietf-geopriv-arch-02 (work in progress), May 2010. [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. [RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010. [W3C.REC-xpath20-20070123] Fernandez, M., Berglund, A., Robie, J., Chamberlin, D., Boag, S., Kay, M., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC-xpath20-20070123, January 2007,