GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Corporation
Expires: July 10, 2011 January 6, 2011
Specifying Location Quality Requirements in Location Protocols
draft-thomson-geopriv-location-quality-07
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 that is requested. 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 July 10, 2011.
Copyright Notice
Copyright (c) 2011 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 July 10, 2011 [Page 1]
Internet-Draft Location Quality January 2011
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 . . . . . . . . . . . . . . . . . . . 6
3.1. Location Quality Request . . . . . . . . . . . . . . . . . 6
3.1.1. Strict Quality Constraints . . . . . . . . . . . . . . 6
3.1.2. Maximum Uncertainty . . . . . . . . . . . . . . . . . 6
3.1.3. Required Civic Elements . . . . . . . . . . . . . . . 8
3.1.4. Maximum Age . . . . . . . . . . . . . . . . . . . . . 9
3.2. Location Quality Indication . . . . . . . . . . . . . . . 9
4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 12
6.2. XML Schema Registration for Location Quality Schema . . . 13
6.3. Registration of HELD 'lowQuality' Error Code . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Thomson & Winterbottom Expires July 10, 2011 [Page 2]
Internet-Draft Location Quality January 2011
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.
Location quality requirements provide information that a LS is able
to use in deciding how to generate location information, if the LS
has that capacity, directly or otherwise.
This document provides semantics, examples and security
considerations for the HELD protocol [RFC5985] and the SIP presence
event package [RFC3856]. 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.
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 LS might be able to meet quality constraints more
quickly than allowed for (for instance, using the HELD "responseTime"
parameter).
Thomson & Winterbottom Expires July 10, 2011 [Page 3]
Internet-Draft Location Quality January 2011
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 that 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 when
it requests location information. These parameters identify a
minimum quality for parameters.
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. 6.3. Registration of HELD 'lowQuality' Error Code This section registers the "lowQuality" error code in the "Geopriv HELD Registries, Error codes for HELD" IANA registry. Thomson & Winterbottom Expires July 10, 2011 [Page 13] Internet-Draft Location Quality January 2011 lowQuality: This error code indicates that the location information that was available did not meet the strict quality constraints specified in the request. 7. References 7.1. Normative References [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. [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Requena, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", RFC 4661, September 2006. [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. [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 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. [I-D.thomson-geopriv-confidence] Thomson, M., "Expressing Confidence in a Location Object", draft-thomson-geopriv-confidence-03 (work in progress), October 2010. Thomson & Winterbottom Expires July 10, 2011 [Page 14] Internet-Draft Location Quality January 2011 7.2. Informative References [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006. [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. [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-03 (work in progress), October 2010. [W3C.REC-xpath20-20070123] Robie, J., Kay, M., Berglund, A., Fernandez, M., Simeon, J., Chamberlin, D., and S. Boag, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC-xpath20-20070123, January 2007,