| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 June 23, 2008.
1.
Introduction
1.1.
Conventions used in this document
2.
Location Quality Operation
3.
Location Quality Parameters
3.1.
Location Quality Request
3.1.1.
Maximum Uncertainty
3.1.2.
Required Civic Elements
3.1.3.
Maximum Age
3.2.
Location Quality Indication
4.
Location Quality Schema
5.
Security Considerations
6.
IANA Considerations
6.1.
URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lq
6.2.
XML Schema Registration for Measurement Schema
7.
References
7.1.
Normative References
7.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Location determination methods produce results of varying quality. In general, the quality of location information increases as the effort expended in generating the information increases. This document provides XML extension objects that can be added to any protocol that provides location information. These elements provide the ability to communicate location quality constraints to the location server.
This document provides semantics, examples and security considerations for the HELD protocol (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) [I‑D.ietf‑geopriv‑http‑location‑delivery]. Application of the parameters described in this document are out of scope.
Means for expressing the quality of location information is outlined in [I‑D.thomson‑geopriv‑uncertainty] (Thomson, M. and J. Winterbottom, “Representation of Uncertainty and Confidence in PIDF-LO,” November 2009.) and [GeoShape] (Thomson, M. and C. Reed, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” April 2007.). An entity requesting location information of an 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 describes an optional HELD parameter that communicates location quality constraints to an LS. These constraints 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.
[I‑D.busin‑geopriv‑location‑qos‑req] (Busin, A., Jin, Y., Mosmondor, M., and S. Loreto, “Requirements for a Location Quality of Service (QoS) Information Object,” November 2007.) describes some of the benefits of providing an LS with location quality constraints. Location quality constraints provide information that an LS can use in deciding how to generate location information. For example, an LS that is able to provide a location estimate with a sufficiently small uncertainty might be able to provide a response before the time indicated in the responseTime.
This document also provides a means by which the LS is able to indicate if the location quality meets the constraints. These parameters can be used by a Location Recipient to ensure that the location is of adequate quality without requiring specific checking (although the PIDF-LO should include sufficient information to perform this check). Response parameters are optional, and are also used to indicate that the LS has understood the location quality constraints.
This document provides solutions that address a subset of the requirements in [I‑D.busin‑geopriv‑location‑qos‑req] (Busin, A., Jin, Y., Mosmondor, M., and S. Loreto, “Requirements for a Location Quality of Service (QoS) Information Object,” November 2007.).
| TOC |
Terms and procedures relating to uncertainty and confidence are taken from [I‑D.thomson‑geopriv‑uncertainty] (Thomson, M. and J. Winterbottom, “Representation of Uncertainty and Confidence in PIDF-LO,” November 2009.). Familiarity with terminology outlined in [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.) and [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.) is also assumed.
The term Location Server (LS) is used as a generic label. 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
Location quality parameters are provided by a Device or any other client of an LS in a location request message. Figure 1 shows an example message.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">geodetic</locationType>
<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
<maxUncertainty confidence="95">
<horizontal>150</horizontal>
<vertical>1000</vertical>
</maxUncertainty>
<maxAge>PT30S</maxAge>
</quality>
</locationRequest>
| Figure 1 |
A LS that supports the location quality element uses the information contained in the request to choose how it serves the query. The response to this message contains a quality indicator element that includes a list of the quality constraints that were met. Figure 2 shows a location response that includes a quality indicator.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:user@example.com">
<!-- Actual location information omitted -->
</presence>
<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
maxUncertainty/vertical maxAge
</qualityInd>
</locationResponse>
| Figure 2 |
A LS doesn't indicate the quality of the location estimate in the quality indicator; quality information is included in the PIDF-LO. The quality indicator provides notice to its recipient that the requested quality was provided.
| TOC |
This section defines the format and semantics of the location quality parameters for requests and the indication that is included with responses.
| TOC |
The quality element is included in a HELD request to indicate the constraints set by the Location Recipient (LR) on the quality of returned location information. This document defines three elements that are included.
| TOC |
The maxUncertainty element describes an upper limit on uncertainty at a given confidence. Uncertainty is divided in to horizontal and 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.
Note: A LS MAY provide location information using the Point shape and indicate that the requested uncertainty is met providing that the LS has access to uncertainty information. However, this is NOT RECOMMENDED since the recipient has no way of verifying the uncertainty.
The horizontal and vertical elements are numerical values that contain a decimal value in meters. 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 constraints. 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 constraints.
The confidence attribute of this element includes the confidence level (expressed as a percentage) that the uncertainty is evaluated at. Confidence is set to a default 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 MAY 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] (Thomson, M. and J. Winterbottom, “Representation of Uncertainty and Confidence in PIDF-LO,” November 2009.), it is RECOMMENDED that a normal PDF be used for all except where confidence is reduced for a rectangular PDF.
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.
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.
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, is is RECOMMENDED that the LS provide a location estimate that includes altitude and altitude uncertainty. It is RECOMMENDED that the LS provide location information at the requested confidence, if possible.
| TOC |
The requiredCivic element represents the requirements of an LR for uncertainty in 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 (DeRose, S. and J. Clark, “XML Path Language (XPath) Version 1.0,” November 1999.) [W3C.REC‑xpath‑19991116] expressions that are evaluated in the context of the "civicAddress" element (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” December 2007.) [I‑D.ietf‑geopriv‑revised‑civic‑lo]. These XPath statements are restricted to use of qualified names only (using the response document namespace context) and the / separator. 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.
<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
<requiredCivic
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
ca:country ca:A1 ca:PC
</requiredCivic>
</quality>
| Figure 3 |
| TOC |
Where location information is stored or cached, an LR can specify how long since the information. This is particularly important if location information is generated in advance. The "age" of location information is the taken as the time interval between the location information timestamp (the timestamp element in the PIDF tuple) and the time that the request is received by the LS.
Location information that has greater age than requested SHOULD either be determined anew, or checked so that the timestamp can be updated. If this value is set to zero (i.e. PT0S), stored location information cannot be used.
| TOC |
The qualityInd element contains a list of the quality constraints that the resulting location information meets.
The list of constraints is represented as a whitespace-separated list of element names. These can be interpreted as XPath (DeRose, S. and J. Clark, “XML Path Language (XPath) Version 1.0,” November 1999.) [W3C.REC‑xpath‑19991116] 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 (Required Civic Elements).
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.
<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
maxUncertainty
</qualityInd>
<qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
maxUncertainty/horizontal maxUncertainty/vertical
</qualityInd>
| Figure 4 |
A LS that is unable to determine if a constraint MUST either omit the quality indication, or indicate that the constraint was not met.
Two special values are added to the quality indication element for convenience. The value ##all indicates that all quality constraints were met (including any extensions). The value ##none indicates that none of the constraints were met.
| TOC |
Note that the pattern rules in the following schema wrap due to length constraints in RFC documents. None of the patterns contain whitespace.
<?xml version="1.0"?>
<xs:schema
xmlns:lq="urn:ietf:params:xml:ns:geopriv:lq"
xmlns:conf="urn:ietf:params:xml:ns:geopriv:conf"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lq"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lq">
HELD Location Quality
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a framework for location quality requests
and indications of whether they are met.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:conf"/>
<xs:element name="quality">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="lq:maxUncertainty" minOccurs="0"/>
<xs:element ref="lq:requiredCivic" minOccurs="0"/>
<xs:element ref="lq:maxAge" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="maxUncertainty" type="lq:maxUncertaintyType"/>
<xs:complexType name="maxUncertaintyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="horizontal" type="lq:limitType"/>
<xs:element name="vertical" type="lq:limitType"/>
</xs:sequence>
<xs:attribute name="confidence" type="conf:confidenceBase"
default="95"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="limitType">
<xs:restriction base="xs:decimal">
<xs:minExclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="maxAge" type="lq:maxAgeType"/>
<xs:simpleType name="maxAgeType">
<xs:restriction base="xs:duration">
<xs:minInclusive value="PT0S"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="requiredCivic" type="lq:elementListType"/>
<xs:element name="qualityInd" type="lq:qualityIndType"/>
<xs:simpleType name="qualityIndType">
<xs:union memberTypes="lq:elementListType">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##all"/>
<xs:enumeration value="##none"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="elementListType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern
value="(([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*/)*
([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:schema>
| TOC |
This document does not introduce any security considerations. [[Editor's Note: Please let us know if you can think of some.]]
| TOC |
| TOC |
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lq, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).
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 <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>HELD Location Quality</title> </head> <body> <h1>Namespace for HELD Location Quality</h1> <h2>urn:ietf:params:xml:ns:geopriv:lq</h2> [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]] <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> </body> </html> END
| TOC |
This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).
- 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 (Location Quality Schema) of this document.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3688] | Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT). |
| [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 (TXT). |
| [I-D.thomson-geopriv-uncertainty] | Thomson, M. and J. Winterbottom, “Representation of Uncertainty and Confidence in PIDF-LO,” draft-thomson-geopriv-uncertainty-04 (work in progress), November 2009 (TXT). |
| TOC |
| [W3C.REC-xpath-19991116] | DeRose, S. and J. Clark, “XML Path Language (XPath) Version 1.0,” World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999 (HTML). |
| [I-D.ietf-geopriv-revised-civic-lo] | Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” draft-ietf-geopriv-revised-civic-lo-07 (work in progress), December 2007 (TXT). |
| [I-D.busin-geopriv-location-qos-req] | Busin, A., Jin, Y., Mosmondor, M., and S. Loreto, “Requirements for a Location Quality of Service (QoS) Information Object,” draft-busin-geopriv-location-qos-req-01 (work in progress), November 2007 (TXT). |
| [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-10 (work in progress), July 2009 (TXT). |
| [RFC3693] | Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” RFC 3693, February 2004 (TXT). |
| [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. |
| TOC |
| 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/ |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.