One document matched: draft-thomson-geopriv-location-quality-08.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902">
<front>
<title abbrev="Location Quality">
Specifying Location Quality Requirements in Location Protocols
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<date month="June" year="2011"/>
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>HELD</keyword>
<keyword>Location</keyword>
<keyword>Quality</keyword>
<keyword>Uncertainty</keyword>
<keyword>Accuracy</keyword>
<keyword>QOP</keyword>
<keyword>QOS</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
</t>
<t>Means for expressing the quality of location information is outlined in <xref target="RFC5491"/> and <xref target="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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>This document provides semantics, examples and security considerations for the <xref target="RFC5985">HELD protocol</xref> and the <xref target="RFC3856">SIP presence event package</xref>. The parameters and procedures described in this document are applicable to HELD when used either as a <xref target="RFC5687">location configuration protocol (LCP)</xref> or as a <xref target="RFC5808">location dereference protocol</xref>. 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.
</t>
<t>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 <spanx style="verb">responseTime</spanx> parameter).
</t>
<t>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.
</t>
<section anchor="conventions" title="Conventions used in this document">
<t>Terms and procedures relating to uncertainty and confidence are taken from <xref target="I-D.thomson-geopriv-uncertainty"/>. Familiarity with terminology outlined in <xref target="RFC5687"/> and <xref target="I-D.ietf-geopriv-arch"/> is also assumed.
</t>
<t>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.
</t>
<t>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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="Location Quality Operation">
<t>Location quality parameters are provided by a location recipient when it requests location information. These parameters identify a minimum quality for parameters.
</t>
<t><xref target="ex-locreq"/> shows an example HELD message where a Device requests location information of a specified quality.
</t>
<figure anchor="ex-locreq" title="Example HELD Location Request">
<artwork><![CDATA[
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">geodetic</locationType>
<quality xmlns="urn:ietf:params:xml:ns:geopriv:lq"
strict="false">
<maxUncertainty confidence="95">
<horizontal>150</horizontal>
<vertical>1000</vertical>
</maxUncertainty>
<maxAge>2008-05-27T05:47:55Z</maxAge>
</quality>
</locationRequest>
]]></artwork>
</figure>
<t>A presence application that uses <xref target="RFC4660">event notification filtering</xref> and the <xref target="RFC4661">XML format for expressing event notification filters</xref> can include this element in the <spanx style="verb">what</spanx> element of the filter document. A SIP presence application might include this in a filter document as shown in <xref target="ex-filter"/>.
</t>
<figure anchor="ex-filter" title="Example Filter Document">
<artwork><![CDATA[
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:lq="urn:ietf:params:xml:ns:geopriv:lq">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lq:quality strict="false">
<lq:requiredCivic>ca:RD ca:HNO</lq:requiredCivic>
</lq:quality>
</what>
</filter>
</filter-set>
]]></artwork>
</figure>
<t>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.
</t>
<t>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. <xref target="ex-locresp"/> shows a HELD location response that includes a quality indicator.
</t>
<figure anchor="ex-locresp" title="Example HELD Location Response">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section title="Location Quality Objects">
<t>This section defines the format and semantics of the location quality parameters for requests and the indication that is included with responses.
</t>
<section title="Location Quality Request">
<t>The <spanx style="verb">quality</spanx> 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.
</t>
<t>Extensions to this specification can specify XML elements that are included as children of the <spanx style="verb">quality</spanx> element. Elements that are not understood MUST be ignored.
</t>
<section title="Strict Quality Constraints">
<t>The <spanx style="verb">strict</spanx> attribute of the <spanx style="verb">quality</spanx> element contains a Boolean value that indicates if the constraints are to be followed strictly. If the <spanx style="verb">strict</spanx> attribute is present and set to <spanx style="verb">true</spanx>, the LS is requested to respond with an error code when it is unable to provide location information of the requested quality.
</t>
<t>A HELD error code, <spanx style="verb">lowQuality</spanx>, is registered in <xref target="lowQuality"/>. A code of <spanx style="verb">lowQuality</spanx> indicates that the requested quality couldn't be provided. The example in <xref target="ex-err"/> shows how the <spanx style="verb">lowQuality</spanx> error code might be used.
</t>
<figure anchor="ex-err" title="HELD Error"><artwork><![CDATA[
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
xmlns:lq="urn:ietf:params:xml:ns:geopriv:lq"
code="lowQuality">
<message xml:lang="en">
Could not provide location of requested quality.</message>
<lq:qualityInd>##none</lq:qualityInd>
</error>
]]></artwork></figure>
<t>The <spanx style="verb">strict</spanx> attribute defaults to <spanx style="verb">false</spanx>. This indicates that the LS provides location information even when the quality constraints aren't met.
</t>
</section>
<section title="Maximum Uncertainty">
<t>The <spanx style="verb">maxUncertainty</spanx> 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 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.
</t>
<t>The <spanx style="verb">horizontal</spanx> and <spanx style="verb">vertical</spanx> elements are numerical values that contain a decimal value in metres. Maximum uncertainty values MUST be greater than zero.
</t>
<t>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.
<list style="hanging">
<t hangText="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.
</t>
</list>
</t>
<t>The <spanx style="verb">confidence</spanx> 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 <xref target="I-D.thomson-geopriv-confidence"/>.
</t>
<t>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 <xref target="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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="req-civic" title="Required Civic Elements">
<t>The <spanx style="verb">requiredCivic</spanx> 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.
</t>
<t>The <spanx style="verb">requiredCivic</spanx> element contains a whitespace-separated list of element names. These can be interpreted as <xref target="W3C.REC-xpath20-20070123">XPath</xref> expressions that are evaluated in the context of the <xref target="RFC5139">"civicAddress" element</xref>. These XPath statements are restricted to use of qualified names only (using the response document namespace context) and the <spanx style="verb">/</spanx> separator; that is, the only permitted axis is the <spanx style="verb">child::</spanx> axis. All child nodes of elements (including attributes and textual content) are treated as belonging to an element.
</t>
<t><xref target="ex-reqcivic"/> 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.
</t>
<figure anchor="ex-reqcivic" title="Example Specifying Required Civic Address Fields">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section title="Maximum Age">
<t>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 <spanx style="verb">timestamp</spanx> element in the PIDF tuple. The age parameter specifies the minimum value for this field; that is, the oldest location information that is acceptable.
</t>
<t>Location information that has greater age than requested SHOULD be determined anew. A value of <spanx style="verb">now</spanx> can be used to indicate that stored location information of any age is not acceptable to the LR.
</t>
<t>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.
</t>
</section>
</section>
<section title="Location Quality Indication">
<t>The <spanx style="verb">qualityInd</spanx> 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.
</t>
<t>The list of requirements is represented as a whitespace-separated list of element names. These can be interpreted as <xref target="W3C.REC-xpath20-20070123">XPath</xref> 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 <xref target="req-civic"/>.
</t>
<t>Where elements are nested, such as the <spanx style="verb">maxUncertainty</spanx> 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 <xref target="ex-uncind"/>.
</t>
<figure anchor="ex-uncind" title="Similar Quality Indications">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>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.
</t>
<t>The special value <spanx style="verb">##all</spanx> indicates that all quality requirements were met. A value of <spanx style="verb">##all</spanx> cannot be used if there are unknown or unsupported elements in the quality request.
</t>
</section>
</section>
<section anchor="schema" title="Location Quality Schema">
<t>Note that the pattern rules in the following schema wrap due to length constraints in RFC documents. None of the patterns contain whitespace.
</t>
<figure>
<artwork><![CDATA[
<?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" type="lq:qualityType"/>
<xs:complexType name="qualityType">
<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:attribute name="strict" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<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>
<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>
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>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 <spanx style="verb">maxAge</spanx> quality constraint. Where caching is used to reduce location generation load, a location server needs mechanisms to control how caching is bypassed.
</t>
<t>An entity that is concerned about the privacy implications of making its preferences known can choose not to specify location quality requirements.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This section registers a schema for the location quality objects and a HELD error code.
</t>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lq">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lq</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lq</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t>XML:
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for Location Quality Schema">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:geopriv:lq</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found in <xref target="schema"/> of this document.
</t>
</list>
</t>
</section>
<section anchor="lowQuality" title="Registration of HELD 'lowQuality' Error Code">
<t>This section registers the <spanx style="verb">lowQuality</spanx> error code in the "Geopriv HELD Registries, Error codes for HELD" IANA registry.
<list style="hanging">
<t hangText="lowQuality:">This error code indicates that the location information that was available did not meet the strict quality constraints specified in the request.
</t>
</list></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4661.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5985.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-confidence.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4660.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5687.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5808.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-arch.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xpath20-20070123.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:03:13 |