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.

     <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>2008-05-27T05:47:55Z</maxAge>
       </quality>
     </locationRequest>

                  Figure 1: Example HELD Location Request



Thomson & Winterbottom   Expires January 9, 2011                [Page 4]

Internet-Draft              Location Quality                   July 2010


   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.

     <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: 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.


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 by the LS.

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 January 9, 2011                [Page 5]

Internet-Draft              Location Quality                   July 2010


   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 is assumed to be arbitrarily large 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.  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
   radius of the resulting circle is compared to the maximum horizontal



Thomson & Winterbottom   Expires January 9, 2011                [Page 6]

Internet-Draft              Location Quality                   July 2010


   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, 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.

     <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>




Thomson & Winterbottom   Expires January 9, 2011                [Page 7]

Internet-Draft              Location Quality                   July 2010


        Figure 3: Example Specifying Required Civic Address Fields

   This does not force the LS to limit the civic address fields provided
   to just those requested.  Additional address fields MAY 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 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.

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.

       <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: Equivalent Quality Indications




Thomson & Winterbottom   Expires January 9, 2011                [Page 8]

Internet-Draft              Location Quality                   July 2010


   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" 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.

   <?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">
         Location Quality Parameters
       </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"/>



Thomson & Winterbottom   Expires January 9, 2011                [Page 9]

Internet-Draft              Location Quality                   July 2010


               <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:union memberTypes="xs:dateTime">
         <xs:simpleType>
           <xs:restriction base="xs:token">
             <xs:enumeration value="now"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
     </xs:simpleType>

     <xs:element name="requiredCivic" type="lq:childOnlyXPathList"/>

     <xs:element name="qualityInd" type="lq:qualityIndType"/>
     <xs:simpleType name="qualityIndType">
       <xs:union memberTypes="lq:childOnlyXPathList">
         <xs:simpleType>



Thomson & Winterbottom   Expires January 9, 2011               [Page 10]

Internet-Draft              Location Quality                   July 2010


           <xs:restriction base="xs:token">
             <xs:enumeration value="##all"/>
             <xs:enumeration value="##none"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
     </xs:simpleType>

     <xs:simpleType name="childOnlyXPathList">
       <xs:list itemType="lq:childOnlyXPath"/>
     </xs:simpleType>
     <xs:simpleType name="childOnlyXPath">
       <xs:union memberTypes="xs:QName lq:childOnlyXPath2"/>
     </xs:simpleType>
     <xs:simpleType name="childOnlyXPath2">
       <xs:restriction base="xs:token">
         <xs:pattern value="(([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*/)+
                            ([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*"/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>


5.  Security Considerations

   This extension does not add significantly to the security and privacy
   concerns of the protocol that the location quality requirements are
   attached to.

   An entity that is concerned about the privacy implications of making
   its preferences known can choose not to specify location quality
   requirements.


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].





Thomson & Winterbottom   Expires January 9, 2011               [Page 11]

Internet-Draft              Location Quality                   July 2010


      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>Location Quality</title>
             </head>
             <body>
               <h1>Namespace for 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

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,
              <http://www.w3.org/TR/2007/REC-xpath20-20070123>.




Thomson & Winterbottom   Expires January 9, 2011               [Page 13]

Internet-Draft              Location Quality                   July 2010


Authors' Addresses

   Martin Thomson
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   Email: martin.thomson@andrew.com


   James Winterbottom
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522
   AU

   Email: james.winterbottom@andrew.com





























Thomson & Winterbottom   Expires January 9, 2011               [Page 14]