GEOPRIV M. Thomson Internet-Draft J. Winterbottom Intended status: Standards Track Andrew Expires: August 28, 2009 February 24, 2009 Specifying Location Quality Requirements in Location Protocols draft-thomson-geopriv-location-quality-03 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 August 28, 2009. Copyright Notice Copyright (c) 2009 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. Abstract Parameters that define the expected quality of location information are defined for use in location protocols. These parameter can be Thomson & Winterbottom Expires August 28, 2009 [Page 1] Internet-Draft Location Quality February 2009 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. 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 Thomson & Winterbottom Expires August 28, 2009 [Page 2] Internet-Draft Location Quality February 2009 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 [I-D.thomson-geopriv-uncertainty] and [GeoShape]. 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) [I-D.ietf-geopriv-l7-lcp-ps] or as a location dereference protocol [I-D.ietf-geopriv-lbyr-requirements]. Application of the parameters described in this document to other protocols is out of scope. 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 able to provide that response before the time indicated within the Thomson & Winterbottom Expires August 28, 2009 [Page 3] Internet-Draft Location Quality February 2009 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 [I-D.ietf-geopriv-l7-lcp-ps] and [RFC3693] 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. geodetic 150 1000 2008-05-27T05:47:55Z Figure 1: Example HELD Location Request Thomson & Winterbottom Expires August 28, 2009 [Page 4] Internet-Draft Location Quality February 2009 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 this message contains a quality indicator element that includes a list of the quality requirements that were understood and met. Figure 2 shows a location response that includes a quality indicator. maxUncertainty/vertical maxAge Figure 2: 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 location uncertainty, timestamp, or through the presence of absence of civic address fields. 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 MAY specify XML elements that are included as children of the "quality" element. Elements that are not understood SHOULD be ignored. 3.1.1. 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 August 28, 2009 [Page 5] Internet-Draft Location Quality February 2009 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 horizontal plane. Vertical uncertainty is the difference in altitude from the centroid to the point in the shape with the greatest 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 MUST be assumed to be infinite at 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. However, this is NOT RECOMMENDED since 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. Confidence has a default value of 95%. 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 radius of the resulting circle is compared to the maximum horizontal uncertainty. Thomson & Winterbottom Expires August 28, 2009 [Page 6] Internet-Draft Location Quality February 2009 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, it is RECOMMENDED that the LS provide a location estimate that includes altitude and altitude uncertainty if possible. It is RECOMMENDED that the LS provide location information at the confidence included in the request, if scaling to a particular confidence is possible. Scaling MAY be avoided if the location information is significantly degraded by the scaling process. 3.1.2. 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 3 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 Figure 3: Example Specifying Required Civic Address Fields Thomson & Winterbottom Expires August 28, 2009 [Page 7] Internet-Draft Location Quality February 2009 Note that this does not force the LS to restrict civic address information to the indicated fields. Additional fields can be provided. 3.1.3. 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 either be determined anew, or checked so that the timestamp can be updated. A value of "now" can be used to indicate that stored location information is not acceptable to the LR. 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.2. 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 equivalent indications are shown in Figure 4. maxUncertainty maxUncertainty/horizontal maxUncertainty/vertical Figure 4: Equivalent Quality Indications Thomson & Winterbottom Expires August 28, 2009 [Page 8] Internet-Draft Location Quality February 2009 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. Two special values are added to the quality indication element for convenience. The value "##all" indicates that all quality requirements were met. A value of "##all" MUST NOT 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 August 28, 2009 [Page 9] Internet-Draft Location Quality February 2009 Thomson & Winterbottom Expires August 28, 2009 [Page 10] Internet-Draft Location Quality February 2009 5. Security Considerations This document does not introduce any security considerations. [[Editor's Note: Please let us know if you find any.]] 6. IANA Considerations This section registers a namespace and schema for the location quality objects. 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: Thomson & Winterbottom Expires August 28, 2009 [Page 11] Internet-Draft Location Quality February 2009 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). Schema: The XML for this schema can be found in Section 4 of this document. 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. [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Thomson & Winterbottom Expires August 28, 2009 [Page 12] Internet-Draft Location Quality February 2009 Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [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-12 (work in progress), January 2009. [I-D.thomson-geopriv-uncertainty] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", draft- thomson-geopriv- uncertainty-02 (work in progress), November 2008. 7.2. Informative References [W3C.REC-xpath20-20070123] Fernandez, M., Chamberlin, D., Robie, J., Berglund, A., Boag, S., Kay, M., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC- xpath20-20070123, January 2007, . [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf- geopriv-l7-lcp-ps-09 (work in progress), February 2009. [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., Thomson & Winterbottom Expires August 28, 2009 [Page 13] Internet-Draft Location Quality February 2009 "Requirements for a Location-by-Reference Mechanism", draft-ietf- geopriv-lbyr-requirements- 05 (work in progress), November 2008. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification 06-142r1, Version: 1.0, April 2007. Authors' Addresses Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 EMail: martin.thomson@andrew.com URI: http://www.andrew.com/ James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2938 EMail: james.winterbottom@andrew.com URI: http://www.andrew.com/ Thomson & Winterbottom Expires August 28, 2009 [Page 14]