GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Corporation
Expires: July 18, 2010 January 14, 2010
Device Capability Negotiation for Device-Based Location Determination
and Location Measurements in HELD
draft-thomson-geopriv-held-capabilities-07
Abstract
A framework for the exchange of capabilities in HELD is described.
Capabilities for enabling Device-based measurements and Device-based
location generation are defined based on this framework.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 July 18, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Thomson & Winterbottom Expires July 18, 2010 [Page 1]
Internet-Draft HELD Capabilities January 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
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 . . . . . . . . . . . . . . . . . . 7
4.1. Capability Definitions . . . . . . . . . . . . . . . . . . 8
5. Capability Invocation . . . . . . . . . . . . . . . . . . . . 9
5.1. HTTP Polling . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Invocation Resource . . . . . . . . . . . . . . . . . . . 10
5.3. Invocation Time . . . . . . . . . . . . . . . . . . . . . 11
5.4. Responding to a Capability Invocation . . . . . . . . . . 12
5.5. Multiple Invocations . . . . . . . . . . . . . . . . . . . 12
6. The Location Capability . . . . . . . . . . . . . . . . . . . 12
6.1. Location Capability Summary . . . . . . . . . . . . . . . 13
7. Location Measurement Capability . . . . . . . . . . . . . . . 13
7.1. Location Measurement Capability Summary . . . . . . . . . 14
8. XML Schema for Capabilities . . . . . . . . . . . . . . . . . 15
9. Example Capabilities Exchange and Invocation . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10.1. URI Secrecy . . . . . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap . . . . . . . . . . . . . 23
11.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:location . . . . . . . . . 24
11.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:cap:lm . . . . . . . . . . . . 25
11.4. XML Schema Registration for HELD Capabilities . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Thomson & Winterbottom Expires July 18, 2010 [Page 2]
Internet-Draft HELD Capabilities January 2010
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
HELD context (or just 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 July 18, 2010 [Page 3]
Internet-Draft HELD Capabilities January 2010
initiate the relationship. The relationship is extended to include
stateful information at the LIS in the form of a HELD context
[I-D.winterbottom-geopriv-held-context]. This document builds HELD
contexts by providing a means for the LIS to request information from
the Device.
This document describes how a HELD 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 capabilities agreement, that includes
which of these capabilities it might use.
In the process of serving requests to a location URI, a LIS might
determine that certain Device capabilities could be useful or
necessary in completing the request. The LIS is able to invoke
specific capabilities to request location information, location
measurements, or any other information 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 Global Navigation Satellite System (GNSS) hardware can determine
its own position by taking a set of measurements and performing a
calculation, or it can provide the GNSS 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 logical overview of a
simple scenario where the LIS uses a Device-provided measurement to
service a request to a location URI.
Thomson & Winterbottom Expires July 18, 2010 [Page 4]
Internet-Draft HELD Capabilities January 2010
+--------+ +-------+ +-----------+
| | | | | Location |
| Device | | LIS | | Recipient |
+--------+ +-------+ +-----------+
| | |
+-------createContext----->| |
| (capability indication) | |
| | |
|<------contextResponse----+ |
| (capability agreement) | |
| | |
|~ ~ ~ ~ ~ ~ ~ ~(convey location URI)~ ~ ~ ~ ~ >|
| | |
| |<--locationRequest--+
| capability | |
|<-------invocation--------+ |
| | |
|<- - - - exchange - - - ->| |
| (measurements/location) | |
| +--locationResponse->|
| | |
Figure 1: Logical Overview of Operation
In practice, this scheme relies on HTTP polling to provide a channel
for LIS communication. This mechanism is described in more detail in
Section 5.
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
To indicate capabilities to a LIS, a Device sends a capability
indication to the LIS in a HELD "createContext" request. The
capability indication includes a set of capabilities, each identified
by a URI. The LIS selects those capabilities that it might make use
of and provides a capabilities agreement that includes the selected
capabilities in a "contextResponse" message.
Thomson & Winterbottom Expires July 18, 2010 [Page 5]
Internet-Draft HELD Capabilities January 2010
+--------+ +-------+
| Device | | LIS |
+--------+ +-------+
| |
+-----------createContext----------->|
| (capability indication: A, B, C) |
| |
|<----------contextResponse----------+
| (capability agreement: A, C) |
| |
Figure 2: Capabilities Exchange
Once a common set of capabilities are agreed upon, the LIS is able
invoke 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. Agreed capabilities and associated parameters can be
stored in the HELD context for later use in serving requests.
The LIS invokes capabilities as it is necessary to service requests
to the HELD context. For instance, capabilities might be used to
respond to a location request made by a location recipient (LR) to
one of the location URIs provided by the context.
+--------+ +-------+ +-----------+
| | | | | Location |
| Device | | LIS | | Recipient |
+--------+ +-------+ +-----------+
| | |
| |<--locationRequest--+
| capability | |
|<-------invocation--------+ |
| | |
|<- - - - exchange - - - ->| |
| (measurements/location) | |
| +--locationResponse->|
| | |
Figure 3: Invoking Capabilities (Logical Process)
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 any
pre-existing capabilities from a context when it receives a
capabilities indication. Therefore, a Device is able to remove
specific capabilities from a context by providing a capabilities
indication that omits that capability. An empty capabilities
Thomson & Winterbottom Expires July 18, 2010 [Page 6]
Internet-Draft HELD Capabilities January 2010
indication removes all 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 individual capabilities. This information is
stored along with the agreed capabilities in the HELD context.
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 "capind" element in the request message. The "capagree" element
contain in the response from the LIS includes the set of capabilities
that might be used.
Both "capind" and "capagree" elements contain a set of capability
indications. A single capability is represented by a "cap" element.
Each "cap" element has a mandatory "uri" attribute that contains a
URI unique to the type of capability. An "id" attribute identifies
the individual capability within the context of an exchange; the
value used by the LIS matches the corresponding indication by the
Device.
The "cap" 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 can be provided by
the Device and LIS.
The optional "responseTime" attribute of the "cap" element indicates
the expected time that invoking that particular capability takes.
This parameter assists the LIS in deciding whether or not to invoke a
capability when serving a request for location information. The
"responseTime" attribute is an integer value in milliseconds. The
"responseTime" attribute only appears in a capabilities indication.
The Device is only able to quantify the time for its own
involvement in the process; additional delays from polling,
network transit and LIS processing need to be included in any
decision to invoke a Device capability.
Multiple capability indications are not necessary, since a set of
capabilities can be specified in the same element. A LIS MAY either
select an arbitrary capability indication, or combine capabilities
from multiple indications.
Thomson & Winterbottom Expires July 18, 2010 [Page 7]
Internet-Draft HELD Capabilities January 2010
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 6, as well as a second capability that
includes additional parameters.
See RFCXXXX.
END 11.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 July 18, 2010 [Page 24] Internet-Draft HELD Capabilities January 2010 BEGINSee RFCXXXX.
END 11.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 July 18, 2010 [Page 25] Internet-Draft HELD Capabilities January 2010 BEGINSee RFCXXXX.
END 11.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 8 of this document. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Thomson & Winterbottom Expires July 18, 2010 [Page 26] Internet-Draft HELD Capabilities January 2010 Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http- location-delivery-16 (work in progress), August 2009. [I-D.ietf-geopriv-lis-discovery] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", draft-ietf-geopriv-lis- discovery-13 (work in progress), December 2009. [I-D.winterbottom-geopriv-held-context] Winterbottom, J., Tschofenig, H., and M. Thomson, "Location URI Contexts in HTTP-Enabled Location Delivery (HELD)", draft-winterbottom- geopriv-held-context-05 (work in progress), October 2009. [I-D.thomson-geopriv-held-measurements] Thomson, M. and J. Winterbottom, "Using Device-provided Location- Related Measurements in Location Configuration Protocols", draft-thomson- geopriv-held-measurements- 05 (work in progress), October 2009. [I-D.winterbottom-geopriv-deref-protocol] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD", draf t-winterbottom-geopriv- deref-protocol-04 (work in progress), July 2009. 12.2. Informative References [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. Thomson & Winterbottom Expires July 18, 2010 [Page 27] Internet-Draft HELD Capabilities January 2010 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4119] Peterson, J., "A Presence- based GEOPRIV Location Object Format", RFC 4119, December 2005. [I-D.loreto-http-bidirectional] Loreto, S., Saint-Andre, P., Wilkins, G., and S. Salsano, "Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", draft -loreto-http- bidirectional-01 (work in progress), October 2009. [I-D.thomson-geopriv-uncertainty] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", draft- thomson-geopriv- uncertainty-04 (work in progress), November 2009. Authors' Addresses Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU EMail: martin.thomson@andrew.com Thomson & Winterbottom Expires July 18, 2010 [Page 28] Internet-Draft HELD Capabilities January 2010 James Winterbottom Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU EMail: james.winterbottom@andrew.com Thomson & Winterbottom Expires July 18, 2010 [Page 29]