GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Corporation
Expires: December 30, 2011 June 28, 2011
Specifying Location Quality Requirements in Location Protocols
draft-thomson-geopriv-location-quality-08.txt
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 December 30, 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 December 30, 2011 [Page 1]
Internet-Draft Location Quality June 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 . . . . . . . . . . . . . . . . . . . . . 13
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 13
6.2. XML Schema Registration for Location Quality Schema . . . 13
6.3. Registration of HELD 'lowQuality' Error Code . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Thomson & Winterbottom Expires December 30, 2011 [Page 2]
Internet-Draft Location Quality June 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 elements that can be added to any protocol
that provides location information. These elements provide the
ability to communicate location quality requirements to a Location
Server. 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 December 30, 2011 [Page 3]
Internet-Draft Location Quality June 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.
geodetic
150
1000
2008-05-27T05:47:55Z
Figure 1: Example HELD Location Request
Thomson & Winterbottom Expires December 30, 2011 [Page 4]
Internet-Draft Location Quality June 2011
A presence application that uses event notification filtering
[RFC4660] and the XML format for expressing event notification
filters [RFC4661] can include this element in the "what" element of
the filter document. A SIP presence application might include this
in a filter document as shown in Figure 2.
ca:RD ca:HNO
Figure 2: Example Filter Document
An LS that supports the location quality element uses the information
contained in the request to choose how it serves the query. If the
LS sources the information from an LG, this information might be
passed to the LG to determine how it generates the information.
The response to a request for location of a particular quality MAY
contain a quality indicator element that includes a list of the
quality requirements that were understood and met. Figure 3 shows a
HELD location response that includes a quality indicator.
maxUncertainty/vertical maxAge
Figure 3: Example HELD Location Response
An LS provides an indication of the requirements that have been met.
The actual quality of the location estimate SHOULD be included in the
actual PIDF-LO document, expressed in the uncertainty inherent in the
location information and tuple timestamp.
Thomson & Winterbottom Expires December 30, 2011 [Page 5]
Internet-Draft Location Quality June 2011
3. Location Quality Objects
This section defines the format and semantics of the location quality
parameters for requests and the indication that is included with
responses.
3.1. Location Quality Request
The "quality" element is included in a HELD request to indicate the
requirements set by the Location Recipient (LR) on the quality of
returned location information. This document defines three elements
that are included.
Extensions to this specification can specify XML elements that are
included as children of the "quality" element. Elements that are not
understood MUST be ignored.
3.1.1. Strict Quality Constraints
The "strict" attribute of the "quality" element contains a Boolean
value that indicates if the constraints are to be followed strictly.
If the "strict" attribute is present and set to "true", the LS is
requested to respond with an error code when it is unable to provide
location information of the requested quality.
A HELD error code, "lowQuality", is registered in Section 6.3. A
code of "lowQuality" indicates that the requested quality couldn't be
provided. The example in Figure 4 shows how the "lowQuality" error
code might be used.
Could not provide location of requested quality.
##none
Figure 4: HELD Error
The "strict" attribute defaults to "false". This indicates that the
LS provides location information even when the quality constraints
aren't met.
3.1.2. Maximum Uncertainty
The "maxUncertainty" element describes an upper limit on uncertainty
at a given confidence. Uncertainty is divided in to horizontal and
Thomson & Winterbottom Expires December 30, 2011 [Page 6]
Internet-Draft Location Quality June 2011
vertical components. Horizontal uncertainty is the maximum distance
from the centroid of the area to the point in the shape furthest from
the centroid on the plane of the horizontal at the centroid.
Vertical uncertainty is the absolute difference in altitude from the
centroid to the point in the shape with the greatest or least
altitude.
The "horizontal" and "vertical" elements are numerical values that
contain a decimal value in metres. Maximum uncertainty values MUST
be greater than zero.
A location estimate that does not contain uncertainty (i.e. a Point
shape), never meets location quality requirements. Where uncertainty
is unknown, it is assumed to be arbitrarily large for any non-zero
confidence. In particular, this applies to vertical uncertainty
where the location estimate is two-dimensional only; location
estimates without a vertical component of uncertainty never meet
vertical uncertainty requirements.
Note: An LS MAY provide location information using the Point shape
and indicate that the requested uncertainty is met, if the LS has
access to uncertainty information and is prevented from sharing
this information due to policy constraints. An LS SHOULD NOT omit
uncertainty in this fashion, because the LR has no way of
independently verifying that the uncertainty meets their
requirements.
The "confidence" attribute of this element includes the confidence
level (expressed as a percentage) that the uncertainty is evaluated
at. Desired confidence has a default value of 95. The definition of
this attribute is taken from [I-D.thomson-geopriv-confidence].
To evaluate uncertainty, the location estimate is first scaled so
that the confidence of the estimate matches or exceeds the requested
confidence. The LS SHOULD convert the shape of the uncertainty to a
circle or a sphere prior to scaling to simply the scaling process.
For consistency - and contrary to the rules in
[I-D.thomson-geopriv-uncertainty] - it is RECOMMENDED that a normal
PDF be assumed for all location information except where confidence
is reduced for a rectangular PDF. Other scaling methods MAY be
applied where better information about the distribution is known.
Horizontal uncertainty is evalulated by removing the altitude and
altitude uncertainty components from the location estimate. While
removing altitude components from a location estimate might normally
increase confidence, confidence MUST NOT be increased at this step;
the confidence value has already been considered. The shape is then
converted to a circle, if it is not already in that shape. The
Thomson & Winterbottom Expires December 30, 2011 [Page 7]
Internet-Draft Location Quality June 2011
radius of the resulting circle is compared to the maximum horizontal
uncertainty.
Vertical uncertainty is evaluated for shapes that contain altitude
uncertainty. The value used for evaluating vertical uncertainty
depends on the shape type: the vertical axis value for the Ellipsoid
shape; the radius of the Sphere shape; half the height of the Prism
shape. A constraint on vertical uncertainty cannot be met if
vertical uncertainty is not known.
The LS MAY use location quality parameters to alter the way that it
generates location information and to provide location information
that more closely matches what is requested. If maximum value is
provided for vertical uncertainty, the LS SHOULD provide a location
estimate that includes altitude and altitude uncertainty if possible.
The LS SHOULD provide location information with the confidence
included in the request, if scaling is possible. Scaling MAY be
avoided if the location information is significantly degraded by the
scaling process.
3.1.3. Required Civic Elements
The "requiredCivic" element represents the requirements of an LR for
civic address information. An LR can specify the address elements
that need to be present in the civic address in order for the
location information to meet their quality requirements.
The "requiredCivic" element contains a whitespace-separated list of
element names. These can be interpreted as XPath
[W3C.REC-xpath20-20070123] expressions that are evaluated in the
context of the "civicAddress" element [RFC5139]. These XPath
statements are restricted to use of qualified names only (using the
response document namespace context) and the "/" separator; that is,
the only permitted axis is the "child::" axis. All child nodes of
elements (including attributes and textual content) are treated as
belonging to an element.
Figure 5 shows an example request where an LR requires country, state
(or equivalent) and post code civic address elements in the location
information provided by the LS.
ca:country ca:A1 ca:PC
Thomson & Winterbottom Expires December 30, 2011 [Page 8]
Internet-Draft Location Quality June 2011
Figure 5: Example Specifying Required Civic Address Fields
This does not force the LS to limit the civic address fields provided
to just those requested. Any additional address fields that are
known can be provided as long as policy permits their inclusion.
3.1.4. Maximum Age
Where location information is stored or cached, an LR can specify a
limit on the age of this information. This is particularly important
if location information is generated in advance. The "age" of
location information is indicated by the the "timestamp" element in
the PIDF tuple. The age parameter specifies the minimum value for
this field; that is, the oldest location information that is
acceptable.
Location information that has greater age than requested SHOULD be
determined anew. A value of "now" can be used to indicate that
stored location information of any age is not acceptable to the LR.
Age is calculated from the time that the LS receives a request.
Location information generated after this time has an effective age
that is less than zero. The age of location information generated
after the request is received is always acceptable.
3.2. Location Quality Indication
The "qualityInd" element is used in responses to indicate which of
the location quality requirements from a request were met. The
presence of this element indicates that a request for a given
location quality was understood and lists the quality requirements
that the accompanying location information meets.
The list of requirements is represented as a whitespace-separated
list of element names. These can be interpreted as XPath
[W3C.REC-xpath20-20070123] expressions that are evaluated in the
context of the original location quality request. These statements
follow the same constraints as the list of elements in Section 3.1.3.
Where elements are nested, such as the "maxUncertainty" element, the
outer element can be included to indicate an entire constraint is
met; or, each individual child element can be identified. Two
quality indications that are roughly equivalent are shown in
Figure 6.
Thomson & Winterbottom Expires December 30, 2011 [Page 9]
Internet-Draft Location Quality June 2011
maxUncertainty
maxUncertainty/horizontal maxUncertainty/vertical
Figure 6: Similar Quality Indications
A LS that is unable to determine if a constraint is met for any
reason MUST NOT list that constraint in this element. This includes
the case where the constraint is not supported by the LS. This list
MAY be empty if none of the requested quality requirements could be
met.
The special value "##all" indicates that all quality requirements
were met. A value of "##all" cannot be used if there are unknown or
unsupported elements in the quality request.
4. Location Quality Schema
Note that the pattern rules in the following schema wrap due to
length constraints in RFC documents. None of the patterns contain
whitespace.
HELD Location Quality
This schema defines a framework for location quality requests
and indications of whether they are met.
Thomson & Winterbottom Expires December 30, 2011 [Page 10]
Internet-Draft Location Quality June 2011
Thomson & Winterbottom Expires December 30, 2011 [Page 11]
Internet-Draft Location Quality June 2011
5. Security Considerations
Location information might be cached by a location server to
alleviate load on location generation functions. A location server
might provide a means for an attacker to increase the location
generation load by forcibly circumventing the cache using the
"maxAge" quality constraint. Where caching is used to reduce
location generation load, a location server needs mechanisms to
control how caching is bypassed.
An entity that is concerned about the privacy implications of making
its preferences known can choose not to specify location quality
requirements.
Thomson & Winterbottom Expires December 30, 2011 [Page 12]
Internet-Draft Location Quality June 2011
6. IANA Considerations
This section registers a schema for the location quality objects and
a HELD error code.
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lq
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lq
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
Location Quality
Namespace for Location Quality
urn:ietf:params:xml:ns:geopriv:lq
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
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).
Thomson & Winterbottom Expires December 30, 2011 [Page 13]
Internet-Draft Location Quality June 2011
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.
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-06 (work in progress),
March 2011.
Thomson & Winterbottom Expires December 30, 2011 [Page 14]
Internet-Draft Location Quality June 2011
[I-D.thomson-geopriv-confidence]
Thomson, M., "Expressing Confidence in a Location Object",
draft-thomson-geopriv-confidence-03 (work in progress),
October 2010.
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]
Fernandez, M., Berglund, A., Simeon, J., Chamberlin, D.,
Boag, S., Robie, J., and M. Kay, "XML Path Language
(XPath) 2.0", World Wide Web Consortium
Recommendation REC-xpath20-20070123, January 2007,
.
Authors' Addresses
Martin Thomson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Email: martin.thomson@andrew.com
Thomson & Winterbottom Expires December 30, 2011 [Page 15]
Internet-Draft Location Quality June 2011
James Winterbottom
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Email: james.winterbottom@andrew.com
Thomson & Winterbottom Expires December 30, 2011 [Page 16]