One document matched: draft-thomson-geopriv-held-capabilities-04.txt
Differences from draft-thomson-geopriv-held-capabilities-03.txt
GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: January 4, 2009 July 3, 2008
Device Capability Negotiation for Device-Based Location Determination
and Location Measurements in HELD
draft-thomson-geopriv-held-capabilities-04
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 4, 2009.
Abstract
A framework for the exchange of capabilities in HELD is described.
Capabilities for enabling device-based measurements and device-based
location generation are described.
Thomson & Winterbottom Expires January 4, 2009 [Page 1]
Internet-Draft HELD Capabilities July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Capabilities Exchange Overview . . . . . . . . . . . . . . . . 3
3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 5
4. The Capability Indication . . . . . . . . . . . . . . . . . . 6
4.1. Retrieving Data from the Device . . . . . . . . . . . . . 8
4.2. Capability Definitions . . . . . . . . . . . . . . . . . . 8
5. The Location Capability . . . . . . . . . . . . . . . . . . . 9
5.1. Location Capability Summary . . . . . . . . . . . . . . . 10
6. Location Measurement Capability . . . . . . . . . . . . . . . 10
6.1. HELD Measurement Request . . . . . . . . . . . . . . . . . 11
6.2. Location Measurement Capability Summary . . . . . . . . . 11
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Capabilities Schema . . . . . . . . . . . . . . . . . . . 12
7.2. HELD Measurement Request Schema . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap . . . . . . . . . . . . . 15
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:location . . . . . . . . . 16
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:lm . . . . . . . . . . . . 17
9.4. XML Schema Registration for HELD Capabilities . . . . . . 18
9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:mr . . . . . . . . . . . . . . 18
9.6. XML Schema Registration for HELD Measurement Request
and Response . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Thomson & Winterbottom Expires January 4, 2009 [Page 2]
Internet-Draft HELD Capabilities July 2008
1. Introduction
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.
Requests that retrieve location information by value are largely
covered by the measurement information and data formats described in
[I-D.thomson-geopriv-held-measurements]. However, location
information provided through location URIs cannot utilise this
information.
This document outlines a method whereby a device indicates
capabilities to a LIS during the creation of a HELD context (see
[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.
2. Conventions used in this document
This document relies on definitions from a range of specification.
Use of the terms LIS and Device is consistent with
[I-D.ietf-geopriv-http-location-delivery]. Location measurement is
defined in [I-D.thomson-geopriv-held-measurements] and location
estimate is defined in [I-D.thomson-geopriv-uncertainty]. The term
context is used as defined in
[I-D.winterbottom-geopriv-held-context].
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].
3. Capabilities Exchange Overview
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.
HELD [I-D.ietf-geopriv-http-location-delivery] provides a basis for
the relationship between device and LIS. LIS Discovery
[I-D.ietf-geopriv-lis-discovery] provides a means for the device to
Thomson & Winterbottom Expires January 4, 2009 [Page 3]
Internet-Draft HELD Capabilities July 2008
initiate the relationship. The relationship is extended to include
stateful information at the LIS in the form of a context
[I-D.winterbottom-geopriv-held-context]. This document relies on the
concept of a HELD context and provides a means for the LIS to acquire
information from the device.
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.
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.
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
[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. Figure 1 shows a simple scenario where the
LIS uses a device-provided measurement to service a request to a
location URI.
Thomson & Winterbottom Expires January 4, 2009 [Page 4]
Internet-Draft HELD Capabilities July 2008
+--------+ +-------+ +-----------+
| | | | | Location |
| Device | | LIS | | Recipient |
+--------+ +-------+ +-----------+
| | |
+-----createContext---->| |
| (capabilities) | |
| | |
|<----contextResponse---+ |
| (capabilities) | |
| | |
| ~ ~ ~ ~ ~ ~ (convey location URI) ~ ~ ~ ~ >|
| | |
| |<--locationRequest--+
| | |
|<--measurementRequest--+ |
| | |
+--measurementResponse->| |
| | |
| +--locationResponse->|
| | |
Figure 1: Basic Operation
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.
3.1. Capabilities Exchange
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 "createContext" request. The LIS selects those capabilities
that it is able to make use of and includes those in the
"contextResponse" message.
+--------+ +-------+
| Device | | LIS |
+--------+ +-------+
| |
+------createContext----->|
| (capability A, B, C) |
| |
|<-----contextResponse----+
| (capability A, C) |
| |
Figure 2: Capabilities Exchange
Thomson & Winterbottom Expires January 4, 2009 [Page 5]
Internet-Draft HELD Capabilities July 2008
The set of capabilities that the LIS includes in the response are a
subset of the capabilities advertised by the Device.
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.
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).
+--------+ +-------+ +-----------+
| | | | | Location |
| Device | | LIS | | Recipient |
+--------+ +-------+ +-----------+
| | |
| |<--locationRequest--+
| | |
|<--measurementRequest--+ |
| | |
+--measurementResponse->| |
| | |
| +--locationResponse->|
| | |
Figure 3: Exercising Capabilities
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.
4. The Capability Indication
A "capabilities" element is added to the create context or update
context HELD requests. The device initiates the exchange, including
the "capabilities" element in the request message. The response from
the LIS includes a similar element that indicates which of these
Thomson & Winterbottom Expires January 4, 2009 [Page 6]
Internet-Draft HELD Capabilities July 2008
capabilities might be used.
A "capabilities" element contains a set of capability indications. A
single capability is represented by a "capind" element. Each
"capind" element has a mandatory "uri" attribute that contains a URI
that identifies the capability.
The "capind" 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.
The "capind" 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
"responseTime" attribute is specified as a time in milliseconds. The
"responseTime" attribute SHOULD NOT be specified in a response from a
LIS.
The following figure shows a capabilities indication that might be
made by a device with GNSS capabilities. This uses the location
capability defined in Section 5, as well as a second capability that
includes additional parameters.
<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>
Thomson & Winterbottom Expires January 4, 2009 [Page 7]
Internet-Draft HELD Capabilities July 2008
4.1. Retrieving Data from the Device
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 "url" element is included
by the Device to indicate where (and how) the information is
retrieved.
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:
o 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.
o 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.
o The benefit gained by acquiring measurements might be considered
worthwhile despite a low probability of success.
4.2. Capability Definitions
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:
URI: A capability is identified by a URI, which need only be unique
and persistent. Common practice is to use an "http:" URI for a
domain that is under the author's control. An IETF document MUST
use a URN [RFC2141] that is registered with the IANA.
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 "capind" element. Separate
descriptions and definitions SHOULD be provided for the Device to
LIS indications and LIS to Device responses.
Thomson & Winterbottom Expires January 4, 2009 [Page 8]
Internet-Draft HELD Capabilities July 2008
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.
Security and Privacy Implications: A discussion of the security and
the privacy implications associated with using the capability MUST
be included with each definition.
Author Contact: Details on how to contact the individual or
organization responsible for the capability definition.
5. The Location Capability
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.
This section defines a location capability, identified by the URN
"urn:ietf:params:xml:ns:geopriv:held:cap:location". This capability
indicates that the device is able to provide location information to
the LIS.
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 "https:" or
"held:" URI. The URI should use the same HELD binding as is being
used for the initial HELD exchange.
The URI provided by the Device should resolve to a PIDF-LO document
[RFC4119] containing the location of the Device. The PIDF-LO MUST be
current at the time that is requested. Only the "location-info"
element of the PIDF-LO SHALL be used by the LIS; therefore, other
fields of the PIDF-LO MAY be minimally populated.
If the provided URI is an "http:" URL, a GET request MUST yield a
PIDF-LO in the response. If the URI is a "held:" URI, the LIS MUST
follow the rules in [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
Thomson & Winterbottom Expires January 4, 2009 [Page 9]
Internet-Draft HELD Capabilities July 2008
request a location URI from the Device.
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.
5.1. Location Capability Summary
The following summarizes the location capability following the
outline from Section 4.2:
URI: urn:ietf:params:xml:ns:geopriv:held:cap:location
Capability Parameters: This capability has a single parameter, a URL
that is included in a "url" element. The "url" element is only
used in the Device to LIS capabilities indication.
Procedures for Exercising Capabilities: This capability is exercised
by resolving and dereferencing a URL.
Security and Privacy Implications: See Section 8 of this document.
Author Contact: The authors of this document.
6. Location Measurement Capability
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 [I-D.thomson-geopriv-held-measurements]
for more information on location measurements.
The measurement capability is identified by the URN
"urn:ietf:params:xml:ns:geopriv:held:cap:lm". 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.
The "lm" 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
[I-D.thomson-geopriv-held-measurements].
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 "appplication/xml" document
containing a "measurements" element. If a HELD URI is used, the HELD
Thomson & Winterbottom Expires January 4, 2009 [Page 10]
Internet-Draft HELD Capabilities July 2008
measurement request and measurement response are used, as defined in
Section 6.1.
6.1. HELD Measurement Request
A HELD measurement request is defined by a "measurementRequest"
element. A HELD measurement request has a single parameter,
"responseTime", which has the same semantics as the response time
parameter on a location request (see
[I-D.ietf-geopriv-http-location-delivery]). Figure 4 contains an
example measurement request message.
<measurementRequest xmlns="urn:ietf:params:xml:ns:geopriv:held:mr"
responseTime="3000"/>
Figure 4: Example Measurement Request
The measurement response contains measurements, in the form of a
"measurements" element (see [I-D.thomson-geopriv-held-measurements]).
Figure 5 contains an example measurement response message.
<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>
Figure 5: Example Measurement Response
The HELD measurement request and response are defined in the
"urn:ietf:params:xml:ns:geopriv:held:mr" namespace and use the
"application/held+xml" MIME type.
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.
6.2. Location Measurement Capability Summary
The following summarizes the location measurement capability
following the outline from Section 4.2:
Thomson & Winterbottom Expires January 4, 2009 [Page 11]
Internet-Draft HELD Capabilities July 2008
URI: urn:ietf:params:xml:ns:geopriv:held:cap:lm
Capability Parameters: This capability has two parameters: a URL
that is included in a "url" element; and a qualified element name
that is included in the "lm" element. These parameters are only
used in the Device to LIS capabilities indication.
Procedures for Exercising Capabilities: This capability is exercised
by resolving and dereferencing a URL. If the URL is a "held:"
URL, a HELD measurement request (see Section 6.1) is used.
Security and Privacy Implications: See Section 8 of this document.
Author Contact: The authors of this document.
7. XML Schema
This section includes a definition for the capabilities exchange
element (Section 7.1) and a definition of HELD measurement request
and response messages (Section 7.2).
7.1. Capabilities Schema
<?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">
Thomson & Winterbottom Expires January 4, 2009 [Page 12]
Internet-Draft HELD Capabilities July 2008
<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"/>
Thomson & Winterbottom Expires January 4, 2009 [Page 13]
Internet-Draft HELD Capabilities July 2008
</xs:schema>
7.2. HELD Measurement Request Schema
<?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>
8. Security Considerations
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.
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.
Thomson & Winterbottom Expires January 4, 2009 [Page 14]
Internet-Draft HELD Capabilities July 2008
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
[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.
When the LIS contacts the Device, the Device SHOULD authenticate the
LIS using the same credentials provided by the LIS after discovery
(see [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.
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.
9. IANA Considerations
This section registers URNs for XML namespaces of capabilities
(Section 9.1) and the HELD measurement request and response
(Section 9.5). Corresponding schemas are also registered
(Section 9.4, Section 9.6). URNs are registered for the location
(Section 9.2) and location measurement (Section 9.3) capability URIs.
9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:held:cap", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:held:cap
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 4, 2009 [Page 15]
Internet-Draft HELD Capabilities July 2008
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
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:location
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:held:cap:location", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:held:cap:location
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 4, 2009 [Page 16]
Internet-Draft HELD Capabilities July 2008
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
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:lm
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:held:cap:lm", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:held:cap:lm
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 4, 2009 [Page 17]
Internet-Draft HELD Capabilities July 2008
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
9.4. XML Schema Registration for HELD Capabilities
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:held:cap
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found as the entirety of
Section 7.1 of this document.
9.5. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:mr
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:held:mr", as per the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:held:mr
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
XML:
Thomson & Winterbottom Expires January 4, 2009 [Page 18]
Internet-Draft HELD Capabilities July 2008
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
9.6. XML Schema Registration for HELD Measurement Request and Response
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:held:mr
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found as the entirety of
Section 7.2 of this document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words
for use in RFCs to
Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[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-07 (work
in progress), April 2008.
Thomson & Winterbottom Expires January 4, 2009 [Page 19]
Internet-Draft HELD Capabilities July 2008
[I-D.ietf-geopriv-lis-discovery] Thomson, M. and J.
Winterbottom, "Discovering
the Local Location
Information Server (LIS)",
draft-ietf-geopriv-lis-
discovery-01 (work in
progress), June 2008.
[I-D.winterbottom-geopriv-held-context] Winterbottom, J.,
Tschofenig, H., and M.
Thomson, "HELD Protocol
Context Management
Extensions", draft-
winterbottom-geopriv-held-
context-02 (work in
progress), February 2008.
[I-D.thomson-geopriv-held-measurements] Thomson, M. and J.
Winterbottom, "Using
Device-provided Location-
Related Measurements in
HELD", draft-thomson-
geopriv-held-measurements-
02 (work in progress),
May 2008.
[I-D.winterbottom-geopriv-deref-protocol] Winterbottom, J.,
Tschofenig, H.,
Schulzrinne, H., Thomson,
M., and M. Dawson, "An
HTTPS Location
Dereferencing Protocol
Using HELD", draft-
winterbottom-geopriv-
deref-protocol-00 (work in
progress), November 2007.
10.2. Informative References
[RFC2141] Moats, R., "URN Syntax",
RFC 2141, May 1997.
[RFC3688] Mealling, M., "The IETF
XML Registry", BCP 81,
RFC 3688, January 2004.
[RFC4119] Peterson, J., "A Presence-
based GEOPRIV Location
Thomson & Winterbottom Expires January 4, 2009 [Page 20]
Internet-Draft HELD Capabilities July 2008
Object Format", RFC 4119,
December 2005.
[I-D.thomson-geopriv-uncertainty] Thomson, M. and J.
Winterbottom,
"Representation of
Uncertainty and Confidence
in PIDF-LO", draft-
thomson-geopriv-
uncertainty-01 (work in
progress), June 2008.
Authors' Addresses
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Thomson & Winterbottom Expires January 4, 2009 [Page 21]
Internet-Draft HELD Capabilities July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Thomson & Winterbottom Expires January 4, 2009 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 16:53:47 |