One document matched: draft-thomson-geopriv-held-capabilities-04.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2141 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.ietf-geopriv-lis-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lis-discovery.xml">
<!ENTITY I-D.winterbottom-geopriv-held-context PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-held-context.xml">
<!ENTITY I-D.thomson-geopriv-held-measurements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-held-measurements.xml">
<!ENTITY I-D.winterbottom-geopriv-deref-protocol PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-deref-protocol.xml">
<!ENTITY I-D.thomson-geopriv-uncertainty PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml">
]>
<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="full3978">
<front>
<title abbrev="HELD Capabilities">
Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD
</title>
<author initials="M." surname="Thomson"
fullname="Martin Thomson">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<author initials="J." surname="Winterbottom"
fullname="James Winterbottom">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2938</phone>
<email>james.winterbottom@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<date month="July" year="2008"/>
<area>Application</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>HELD</keyword>
<keyword>Capabilities</keyword>
<keyword>Location</keyword>
<keyword>Measurements</keyword>
<keyword>Device-based</keyword>
<abstract>
<t>A framework for the exchange of capabilities in HELD is described. Capabilities for enabling device-based measurements and device-based location generation are described.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>A device is a good source of information about its location. Even where a device is unable to independently determine its location, it can often make observations about its environment and network attachment that are of use in determining its position. Making this information available to the Location Information Server (LIS) in the access network can improve the quality of location estimates for the device.
</t>
<t>Requests that retrieve location information by value are largely covered by the measurement information and data formats described in <xref target="I-D.thomson-geopriv-held-measurements"/>. However, location information provided through location URIs cannot utilise this information.
</t>
<t>This document outlines a method whereby a device indicates capabilities to a LIS during the creation of a HELD context (see <xref target="I-D.winterbottom-geopriv-held-context"/>). The LIS is able to then exercise those capabilities to assist it in the generation of location information, or to acquire location information from the device.
</t>
</section>
<section anchor="conventions" title="Conventions used in this document">
<t>This document relies on definitions from a range of specification. Use of the terms LIS and Device is consistent with <xref target="I-D.ietf-geopriv-http-location-delivery"/>. Location measurement is defined in <xref target="I-D.thomson-geopriv-held-measurements"/> and location estimate is defined in <xref target="I-D.thomson-geopriv-uncertainty"/>. The term context is used as defined in <xref target="I-D.winterbottom-geopriv-held-context"/>.
</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 anchor="overview" title="Capabilities Exchange Overview">
<t>Acquiring location measurements or information from a device is made difficult by the nature of the relationship between the LIS, or access network, and the device. The relationship between a LIS and the devices that it serves is often transient. A device is not necessarily a permanent part of an access network.
</t>
<t><xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> provides a basis for the relationship between device and LIS. LIS Discovery <xref target="I-D.ietf-geopriv-lis-discovery"/> provides a means for the device to initiate the relationship. The relationship is extended to include stateful information at the LIS in the form of a <xref target="I-D.winterbottom-geopriv-held-context">context</xref>. This document relies on the concept of a HELD context and provides a means for the LIS to acquire information from the device.
</t>
<t>This document describes how the context can be used as the basis for cooperative location determination. A device provides the LIS with a capabilities indication when it creates or updates its context data. The LIS responds with a reciprocal indication, that includes which of these capabilities it might use.
</t>
<t>Depending on the specific capabilities that were shared and thereby agreed upon, the LIS is able to retrieve location information or location measurements from the device. Device capabilities include the ability to generate or acquire location information, or the ability to make observations about the mode of network attachment or environment. For instance, a device with GNSS-capable hardware can determine its own position by taking a set of measurements and performing a calculation, or it can provide the raw measurement data.
</t>
<t>This document defines a set of capabilities that a device can use to indicate that it is able to provide location measurements. The form of location measurements is described in <xref target="I-D.thomson-geopriv-held-measurements"/>. A device is able to use these capabilities to indicate to the LIS the types of measurements that it can observe and the means by which the LIS can acquire these measurements when needed. <xref target="ex"/> shows a simple scenario where the LIS uses a device-provided measurement to service a request to a location URI.
</t>
<figure anchor="ex" title="Basic Operation">
<artwork><![CDATA[
+--------+ +-------+ +-----------+
| | | | | Location |
| Device | | LIS | | Recipient |
+--------+ +-------+ +-----------+
| | |
+-----createContext---->| |
| (capabilities) | |
| | |
|<----contextResponse---+ |
| (capabilities) | |
| | |
| ~ ~ ~ ~ ~ ~ (convey location URI) ~ ~ ~ ~ >|
| | |
| |<--locationRequest--+
| | |
|<--measurementRequest--+ |
| | |
+--measurementResponse->| |
| | |
| +--locationResponse->|
| | |
]]></artwork>
</figure>
<t>This document also defines a location capability, which indicates that the device is able to determine its own location. Guidelines for the definition of other capabilities are also included.
</t>
<section title="Capabilities Exchange">
<t>At its core, the capabilities exchange is simple. The device sends a set of capabilities, each identified by a URN, to the LIS inside a HELD <spanx style="verb">createContext</spanx> request. The LIS selects those capabilities that it is able to make use of and includes those in the <spanx style="verb">contextResponse</spanx> message.
</t>
<figure anchor="capex" title="Capabilities Exchange">
<artwork><![CDATA[
+--------+ +-------+
| Device | | LIS |
+--------+ +-------+
| |
+------createContext----->|
| (capability A, B, C) |
| |
|<-----contextResponse----+
| (capability A, C) |
| |
]]></artwork>
</figure>
<t>The set of capabilities that the LIS includes in the response are a subset of the capabilities advertised by the Device.
</t>
<t>Capabilities are related to a single context. The LIS MUST restrict its use of capabilities to requests relating to the context where the capabilities are provided by the Device. The LIS MUST remove and pre-existing capabilities from a context when it receives a capabilities indication. Therefore, a Device is able to remove capabilities from a context by providing an empty capabilities set.
</t>
<t>Once a common set of capabilities are agreed upon, the LIS is able to make use of these capabilities to generate location information. This might be an ability to generate geodetic location information at the device, or the device might be able provide the LIS with location measurements. The LIS invokes capabilities in response to a request for location information, which can be initiated by either the device, or a Location Recipient (LR).
</t>
<figure anchor="excap" title="Exercising Capabilities">
<artwork><![CDATA[
+--------+ +-------+ +-----------+
| | | | | Location |
| Device | | LIS | | Recipient |
+--------+ +-------+ +-----------+
| | |
| |<--locationRequest--+
| | |
|<--measurementRequest--+ |
| | |
+--measurementResponse->| |
| | |
| +--locationResponse->|
| | |
]]></artwork>
</figure>
<t>A capabilities exchange may contain additional information that is specific to the associated measurement acquisition method. This additional information allows the Device and LIS to provide more information about capabilities. Agreed capabilities and associated parameters can be stored in the context created for the device at the LIS for later use.
</t>
</section>
</section>
<section title="The Capability Indication">
<t>A <spanx style="verb">capabilities</spanx> element is added to the create context or update context HELD requests. The device initiates the exchange, including the <spanx style="verb">capabilities</spanx> element in the request message. The response from the LIS includes a similar element that indicates which of these capabilities might be used.
</t>
<t>A <spanx style="verb">capabilities</spanx> element contains a set of capability indications. A single capability is represented by a <spanx style="verb">capind</spanx> element. Each <spanx style="verb">capind</spanx> element has a mandatory <spanx style="verb">uri</spanx> attribute that contains a URI that identifies the capability.
</t>
<t>The <spanx style="verb">capind</spanx> element may also contain arbitrary content, which means that the element is able to carry supplementary information that is specific to the capability. This supplementary information could include addressing information, protocol selection, authentication details, or any data necessary for the successful retrieval of information. Different supplementary information is provided by the Device and LIS.
</t>
<t>The <spanx style="verb">capind</spanx> element has an additional optional parameter that indicates the expected time that exercising that particular capability takes. This information assists the LIS in a decision on whether or not to use this particular capability to serve a request for location information. Note that the Device is only able to quantify the time for its own involvement in the process; additional delays from network transmission and LIS processing need to be included in any decision to exercise a device capability. The <spanx style="verb">responseTime</spanx> attribute is specified as a time in milliseconds. The <spanx style="verb">responseTime</spanx> attribute SHOULD NOT be specified in a response from a LIS.
</t>
<figure>
<preamble>The following figure shows a capabilities indication that might be made by a device with GNSS capabilities. This uses the location capability defined in <xref target="location"/>, as well as a second capability that includes additional parameters.
</preamble>
<artwork><![CDATA[
<capabilities xmlns="urn:ietf:params:xml:ns:geopriv:held:cap">
<capind uri="urn:ietf:params:xml:ns:geopriv:held:cap:location"
responseTime="45000">
<url>held://192.0.2.55:46743/location/</url>
</capind>
<capind uri="urn:ietf:params:xml:ns:geopriv:held:cap:lm"
responseTime="30">
<url>held://192.0.2.55:46743/gnss/</url>
<lm xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss">
gnss:gnss
</lm>
</capind>
</capabilities>
]]></artwork>
</figure>
<section title="Retrieving Data from the Device">
<t>The capabilities described in this document both rely on the Device providing a URL. The LIS is able to dereference this URL in order to retrieve information from the device. The <spanx style="verb">url</spanx> element is included by the Device to indicate where (and how) the information is retrieved.
</t>
<t>Although HELD can theoretically be bound to session protocols other than HTTP, in effect, HELD capabilities use the questionable practice of HTTP callbacks. For this particular application the drawbacks (primarily the fact that it doesn't work very reliably, aside from the general disdain it attracts) are considered acceptable for the following reasons:
<list style="symbols">
<t>The LIS is expected to exist in close proximity to the device in the network, thereby reducing the probability that an intermediate node exists that could block the callback.
</t>
<t>The LIS is expected to hold a privileged position in the access network and may be able to resolve some of the shortcomings of this method.
</t>
<t>The benefit gained by acquiring measurements might be considered worthwhile despite a low probability of success.
</t>
</list>
</t>
</section>
<section anchor="defn" title="Capability Definitions">
<t>Capabilities can be defined for access network or location measurement technologies as required. No special registration is required to define a capability; each capability is identified by a namespace URI. A capability definition includes the following information:
<list style="hanging">
<t hangText="URI:">A capability is identified by a URI, which need only be unique and persistent. Common practice is to use an <spanx style="verb">http:</spanx> URI for a domain that is under the author's control. An IETF document MUST use a <xref target="RFC2141">URN</xref> that is registered with the IANA.
</t>
<t hangText="Capability Parameters:">Each capability may require additional information to be passed between LIS and device in order for it to be exercised. This information must be described and defined as XML elements for inclusion in the <spanx style="verb">capind</spanx> element. Separate descriptions and definitions SHOULD be provided for the Device to LIS indications and LIS to Device responses.
</t>
<t hangText="Procedures for Exercising Capabilities:">Each capability MUST also include a description of how it can be exercised. This includes the protocol that is used for any network exchanges, the impact of each parameter.
</t>
<t hangText="Security and Privacy Implications:">A discussion of the security and the privacy implications associated with using the capability MUST be included with each definition.
</t>
<t hangText="Author Contact:">Details on how to contact the individual or organization responsible for the capability definition.
</t>
</list>
</t>
</section>
</section>
<section anchor="location" title="The Location Capability">
<t>The ability to locate itself is a trait that is applicable to devices in a range of networks. This includes automated location determination, like Global Navigation Satellite Systems (GNSS), user input, an alternative location service, or a range of location techniques. Because the device produces complete location information, there is no need for technology- or network-specific features in messages. Therefore, this section describes how a device may advertise its capability to source its own location.
</t>
<t>This section defines a location capability, identified by the URN <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:cap:location</spanx>. This capability indicates that the device is able to provide location information to the LIS.
</t>
<t>The location capability includes a URI parameter that is passed in the request from Device to LIS. This URI indicates where the LIS can retrieve location information. Any URI scheme that can be trivially resolved may be used when expressing this capability. When using the HTTP binding of HELD, it is recommended that this be an <spanx style="verb">https:</spanx> or <spanx style="verb">held:</spanx> URI. The URI should use the same HELD binding as is being used for the initial HELD exchange.
</t>
<t>The URI provided by the Device should resolve to a <xref target="RFC4119">PIDF-LO document</xref> containing the location of the Device. The PIDF-LO MUST be current at the time that is requested. Only the <spanx style="verb">location-info</spanx> element of the PIDF-LO SHALL be used by the LIS; therefore, other fields of the PIDF-LO MAY be minimally populated.
</t>
<t>If the provided URI is an <spanx style="verb">http:</spanx> URL, a GET request MUST yield a PIDF-LO in the response. If the URI is a <spanx style="verb">held:</spanx> URI, the LIS MUST follow the rules in <xref target="I-D.winterbottom-geopriv-deref-protocol"/> when requesting information. The Device includes the PIDF-LO in a location response message. In the HELD request, the LIS SHOULD NOT request a specific location type; in particular, the LIS MUST NOT request a location URI from the Device.
</t>
<t>In providing location information in this manner, the Device implicitly grants the LIS the ability to redistribute location information under the same conditions that apply to the HELD context.
</t>
<section title="Location Capability Summary">
<t>The following summarizes the location capability following the outline from <xref target="defn"/>:
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:geopriv:held:cap:location
</t>
<t hangText="Capability Parameters:">This capability has a single parameter, a URL that is included in a <spanx style="verb">url</spanx> element. The <spanx style="verb">url</spanx> element is only used in the Device to LIS capabilities indication.
</t>
<t hangText="Procedures for Exercising Capabilities:">This capability is exercised by resolving and dereferencing a URL.
</t>
<t hangText="Security and Privacy Implications:">See <xref target="security"/> of this document.
</t>
<t hangText="Author Contact:">The authors of this document.
</t>
</list>
</t>
</section>
</section>
<section anchor="measurements" title="Location Measurement Capability">
<t>Like the ability to generate location information, acquiring measurement data from the Device can be invaluable to the LIS. Measurement information from a device can improve the accuracy of location estimates or enable positioning methods that would not otherwise be available. See <xref target="I-D.thomson-geopriv-held-measurements"/> for more information on location measurements.
</t>
<t>The measurement capability is identified by the URN <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:cap:lm</spanx>. In addition to this URN, the Device also needs to indicate which measurements it can provide in the capability indication. This is done by identifying the location measurement element.
</t>
<t>The <spanx style="verb">lm</spanx> element includes a qualified element name (using the namespace context of the enclosing document). This name identifies a measurement element, as defined by the guidelines in <xref target="I-D.thomson-geopriv-held-measurements"/>.
</t>
<t>When the LIS dereferences the provided URL, the Device acquires location measurements and provides these in response. If an HTTP URI is provided, the response is an <spanx style="verb">appplication/xml</spanx> document containing a <spanx style="verb">measurements</spanx> element. If a HELD URI is used, the HELD measurement request and measurement response are used, as defined in <xref target="heldmr"/>.
</t>
<section anchor="heldmr" title="HELD Measurement Request">
<t>A HELD measurement request is defined by a <spanx style="verb">measurementRequest</spanx> element. A HELD measurement request has a single parameter, <spanx style="verb">responseTime</spanx>, which has the same semantics as the response time parameter on a location request (see <xref target="I-D.ietf-geopriv-http-location-delivery"/>). <xref target="ex-mreq"/> contains an example measurement request message.
</t>
<figure anchor="ex-mreq" title="Example Measurement Request">
<artwork><![CDATA[
<measurementRequest xmlns="urn:ietf:params:xml:ns:geopriv:held:mr"
responseTime="3000"/>
]]></artwork>
</figure>
<t>The measurement response contains measurements, in the form of a <spanx style="verb">measurements</spanx> element (see <xref target="I-D.thomson-geopriv-held-measurements"/>). <xref target="ex-mresp"/> contains an example measurement response message.
</t>
<figure anchor="ex-mresp" title="Example Measurement Response">
<artwork><![CDATA[
<measurementResponse
xmlns="urn:ietf:params:xml:ns:geopriv:held:mr">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<servingWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-EF</bssid>
</servingWap>
</wifi>
</measurements>
</measurementResponse>
]]></artwork>
</figure>
<t>The HELD measurement request and response are defined in the <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:mr</spanx> namespace and use the <spanx style="verb">application/held+xml</spanx> MIME type.
</t>
<t>For privacy purposes, the Device implicitly grants the LIS the ability to redistribute location information derived from the location measurements it provides under the same conditions that apply to the HELD context.
</t>
</section>
<section title="Location Measurement Capability Summary">
<t>The following summarizes the location measurement capability following the outline from <xref target="defn"/>:
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:geopriv:held:cap:lm
</t>
<t hangText="Capability Parameters:">This capability has two parameters: a URL that is included in a <spanx style="verb">url</spanx> element; and a qualified element name that is included in the <spanx style="verb">lm</spanx> element. These parameters are only used in the Device to LIS capabilities indication.
</t>
<t hangText="Procedures for Exercising Capabilities:">This capability is exercised by resolving and dereferencing a URL. If the URL is a <spanx style="verb">held:</spanx> URL, a HELD measurement request (see <xref target="heldmr"/>) is used.
</t>
<t hangText="Security and Privacy Implications:">See <xref target="security"/> of this document.
</t>
<t hangText="Author Contact:">The authors of this document.
</t>
</list>
</t>
</section>
</section>
<section anchor="schema" title="XML Schema">
<t>This section includes a definition for the capabilities exchange element (<xref target="capschema"/>) and a definition of HELD measurement request and response messages (<xref target="mrschema"/>).
</t>
<section anchor="capschema" title="Capabilities Schema">
<figure>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
xmlns:cap="urn:ietf:params:xml:ns:geopriv:held:cap"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:cap"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:cap">
HELD Capabilities
</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 capabilities negotiation
in HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="capabilities">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="cap:capind"
minOccurs="0" maxOccurs="unbounded"/>
<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="capind">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="responseTime" type="cap:durationType"
use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="durationType">
<xs:restriction base="xs:decimal">
<xs:minInclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<!-- Location measurement element -->
<xs:element name="lm" type="cap:lmType"/>
<xs:complexType name="lmType">
<xs:simpleContent>
<xs:extension base="xs:Name">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Callback URI element -->
<xs:element name="url" type="xs:anyURI"/>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="mrschema" title="HELD Measurement Request Schema">
<figure>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
xmlns:mr="urn:ietf:params:xml:ns:geopriv:held:mr"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:mr"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:mr">
HELD Capabilities
</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 the HELD measurement request and response.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:held"/>
<xs:element name="measurementRequest" type="held:baseRequestType"/>
<xs:element name="measurementResponse" type="xs:anyType"/>
</xs:schema>
]]></artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Giving the LIS additional information about the location of a Device might consititute a compromise of privacy. The LIS is able to resolve the location of the Device with greater accuracy than would be otherwise possible without this assistance. Information about the capabilities of a Device could also be considered sensitive. A Device SHOULD offer a user the option to suppress the capability exchange and all associated functions.
</t>
<t>Capabilities MUST only be exchanged with the LIS in the scope of a context. This precaution provides the Device with a means to void access to these capabilities at any time. This can be done by deleting the context, or by indicating an empty set of capabilities to the LIS.
</t>
<t>Any information that is provided to the LIS by the Device increases the impact of LIS impersonation. Measures that mitigate the possibility of impersonation, as outlined in <xref target="I-D.ietf-geopriv-lis-discovery"/>, are more important for a Device that provides capability information to a LIS. Protocols used for the exchange of location information or location measurements should also provide protection from eavesdropping.
</t>
<t>When the LIS contacts the Device, the Device SHOULD authenticate the LIS using the same credentials provided by the LIS after discovery (see <xref target="I-D.ietf-geopriv-lis-discovery"/>). This ensures that other entities are not able to retrieve location information or measurements from the Device. Requiring client authentication on a TLS connection and then matching this authentication to the server authentication provided by the LIS can achieve this.
</t>
<t>The LIS is responsible for the veracity of location information it provides, even when it relies on information that comes from the Device. However, the LIS is not necessarily able to establish grounds for trust in this information. A Device could provide erroneous measurements in an attempt to make the LIS provide incorrect or fraudulent location information. The LIS should take measures to verify the information that is provided to it before acting on those data. The LIS can use information from the network, or other trusted sources, to check that information provided by the Device is valid.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This section registers URNs for XML namespaces of capabilities (<xref target="iana-nscap"/>) and the HELD measurement request and response (<xref target="iana-nsmr"/>). Corresponding schemas are also registered (<xref target="iana-schemacap"/>, <xref target="iana-schemamr"/>). URNs are registered for the location (<xref target="iana-nsloc"/>) and location measurement (<xref target="iana-nslm"/>) capability URIs.
</t>
<section anchor="iana-nscap" title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:held:cap</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:held:cap</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>HELD Capabilities Indication</title>
</head>
<body>
<h1>Namespace for HELD Capabilities Indication</h1>
<h2>urn:ietf:params:xml:ns:held:cap</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 anchor="iana-nsloc" title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap:location">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:held:cap:location</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:held:cap:location</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>HELD Capabilities - Location Capability</title>
</head>
<body>
<h1>Namespace for HELD Capabilities
- Location Capability</h1>
<h2>urn:ietf:params:xml:ns:held:cap:location</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 anchor="iana-nslm" title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap:lm">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:held:cap:lm</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:held:cap:lm</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>HELD Capabilities
- Location Measurement Capability</title>
</head>
<body>
<h1>Namespace for HELD Capabilities
- Location Measurement Capability</h1>
<h2>urn:ietf:params:xml:ns:held:cap:lm</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 anchor="iana-schemacap" title="XML Schema Registration for HELD Capabilities">
<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:held:cap</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 as the entirety of <xref target="capschema"/> of this document.
</t>
</list>
</t>
</section>
<section anchor="iana-nsmr" title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:mr">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:held:mr</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:held:mr</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>HELD Measurement Request/Response</title>
</head>
<body>
<h1>Namespace for HELD Request/Response</h1>
<h2>urn:ietf:params:xml:ns:held:mr</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 anchor="iana-schemamr" title="XML Schema Registration for HELD Measurement Request and Response">
<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:held:mr</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 as the entirety of <xref target="mrschema"/> of this document.
</t>
</list>
</t>
</section>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&I-D.ietf-geopriv-http-location-delivery;
&I-D.ietf-geopriv-lis-discovery;
&I-D.winterbottom-geopriv-held-context;
&I-D.thomson-geopriv-held-measurements;
&I-D.winterbottom-geopriv-deref-protocol;
</references>
<references title="Informative References">
&RFC2141;
&RFC3688;
&RFC4119;
&I-D.thomson-geopriv-uncertainty;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:25:10 |