Geopriv J. Winterbottom
Internet-Draft M. Dawson
Expires: August 11, 2005 M. Thomson
Nortel
February 10, 2005
HTTP Enabled Location Delivery (HELD)
draft-winterbottom-http-location-delivery-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a means by which a client-device may request
location from a Location Server using HTTP as a GeoPriv 'using
protocol'.
Winterbottom, et al. Expires August 11, 2005 [Page 1]
Internet-Draft HELD February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Specifics . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Location Server Discovery . . . . . . . . . . . . . . . . 7
4.2 Location-Key Generation . . . . . . . . . . . . . . . . . 7
4.3 Location Request . . . . . . . . . . . . . . . . . . . . . 7
4.3.1 Form Fields . . . . . . . . . . . . . . . . . . . . . 8
4.3.2 PIDF-LO Document . . . . . . . . . . . . . . . . . . . 9
4.4 Third Party Location Request Message . . . . . . . . . . . 11
4.5 Location Response Message . . . . . . . . . . . . . . . . 11
4.6 Authentication . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Session Management . . . . . . . . . . . . . . . . . . . . 13
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Simple Location Request . . . . . . . . . . . . . . . . . 14
5.2 Location Key with Rules Request . . . . . . . . . . . . . 14
5.3 Civic Location Request . . . . . . . . . . . . . . . . . . 16
5.4 Exact and Signed Location Request . . . . . . . . . . . . 16
5.5 Location Assertion . . . . . . . . . . . . . . . . . . . . 17
5.6 Third Party Location Request . . . . . . . . . . . . . . . 19
5.7 Session Management . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1 Normative references . . . . . . . . . . . . . . . . . . . . 26
9.2 Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28
Winterbottom, et al. Expires August 11, 2005 [Page 2]
Internet-Draft HELD February 2005
1. Introduction
This document describes a mechanism that employs HTTP as a GeoPriv
'using protocol' to deliver location information relating to a
client-device from a Location Server. The client-device discovers or
is informed of the Location Server and establishes a session with the
server. The Location Server constructs a PIDF-LO document and
returns this to the client-device. In addition to requesting a
location, the mechanism described allows the client-device to request
specific forms of location, geodetic, civic-postal,
civic-jurisdictional etc, including requesting that the Location
Server sign the location as specified in [I-D.ietf-geopriv-domauth].
Currently proposed location delivery mechanism, such as those defined
in [RFC3825] and [I-D.ietf-geopriv-dhcp-civil], tightly couple
location determination (generation) and location delivery. While
this coupling offers some benefits it also has drawbacks,
particularly if the form of location or its container evolve to
encompass additional information, for example signatures as proposed
in [I-D.ietf-geopriv-domauth] or the existing provided-by field,
where support for these will necessitate changes to the base
protocol. In contrast to these mechanisms the proposal made in this
paper aligns itself more closely with the GEOPRIV framework [RFC3693]
by separating the Location Server and Location Generator functions
and concentrating on Location-Recipient and Location Server
interactions. Location determination itself within a network is left
for further discussion and is outside the scope of this paper.
1.1 Paradigm
The philosophical approach for requesting a location on which this
paper is based, is that the network does not know the identity of a
user requesting a location, but it can have some assurances as to
which access point the location request is coming from. That is,
location is a resource or an attribute being used in a network and
the network can identify the resource being used. This is somewhat
analogous to an IP address being allocated via DHCP, that is to say
that the DHCP server does not know the identity of the user
requesting the address, but it can be sure that it has allocated an
address in response to a request to an entity physically present in
the access network it serves.
The Location Server is assumed to have the facilities of a Location
Generator as part of its own implementation or available in the
access networks serviced by the Location Server. The form and nature
of the Location Generator are not discussed in this document.
Winterbottom, et al. Expires August 11, 2005 [Page 3]
Internet-Draft HELD February 2005
2. Terminology
The key conventions and terminology used in this paper are defined as
follows:
This document reuses the terms Location Server, Location Generator
and Using-Protocol as defined in [RFC3693].
Target: The device that the location is attributed to.
Client-Device: Used interchangeably with Target
Domain: An area or group of services falling with in a specific
category or jurisdictional boundary.
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].
Winterbottom, et al. Expires August 11, 2005 [Page 4]
Internet-Draft HELD February 2005
3. Overview
The protocol described in this paper is made up of 3 main parts:
Location Server Discovery, Location Request, and Location Response.
Location Server discovery is achieved through the use of a DNS SRV
record, the client-device having discovered the Location Server will
make an HTTP connection to the Location Server. The requesting
client-device will forward its IP address and MAC address to the
Location Server, optionally including requests for specific types of
location information using an HTTP POST method.
The Location Server checks the source IP address of the arriving
packet to ensure that it matches that included in the location
request message. In the normative case these two addresses are
expected to match, specific exceptions as to where this may not be
the case and subsequent behaviours are explored in more detail later
in the document. The Location Server will use the IP address of the
source to determine the correct Location Generator to generate the
location for the device. The Location Server will take the generated
location and produce a PIDF-LO that is subsequently returned to the
requesting client-device.
In addition to simply returning a location to a device requesting its
own location, the protocol provides a "location-key" which is a
temporary presentity identifier that is assigned to a client-device.
The location-key may be distributed by the client-device to
third-parties, who can use the location-key to directly request the
location of the client-device from the Location Server. This is
useful in the case where the third-party is not SIP or
IETF-presence-enabled and the client-device does not wish to maintain
a session with the third-party, but does wish the third-party to be
able to locate the client-device. For example, in emergency
services, the caller wants the emergency network to be able to locate
them even if the call is unexpectedly dropped; using a location-key
allows this while the client-device still has a presence on the
original access network.
Winterbottom, et al. Expires August 11, 2005 [Page 5]
Internet-Draft HELD February 2005
+-----------------+
| | Third Party-Location-Request
| Location Server |<----------------------------+
| | |
+-----------------+ |
^ | |
| | +--------------+
Location | | Location | |
Request | | | Third Party |
| | | |
| V +--------------+
+-------------------+ ^
| | Location-key |
| HTTP Location |--------------------------+
| Client | Location
+-------------------+
Winterbottom, et al. Expires August 11, 2005 [Page 6]
Internet-Draft HELD February 2005
4. Protocol Specifics
4.1 Location Server Discovery
Location Server discovery SHOULD occur through a DNS SVC record. A
new service is to be created "locserv+http" such that the querying
entity can recover the FQDN for the local Location Server. This
service MUST be configured such that an HTTP POST to this address
will result in the Location Server application being invoked. The
DNS server entry will therefore look similar to:
_locserv+http_.tcp SRV 1 0 0 location-server.example.com.
The new service record needs to be registered with IANA, see IANA
section for more details.
4.2 Location-Key Generation
The location-key is a pseudonym generated by the Location Server to
represent a client-device inside the access network. The
location-key takes the form of a 'pres' uri. A 'pres' uri, as
defined in [RFC3863] is a uri representing a user within a domain in
the form "pres:pseudonym@domain.example.com". To ensure anonymity
for the client-device the Location Server MUST ensure that there is
no way for a third-party to determine the MAC and IP addresses of a
client-device from a location-key. Furthermore the pseudonym
generated by the Location Server MUST be unique.
The Location Server generates a location-key in response to either an
explicit location-key request, or as the presentity attribute used in
a signed PIDF-LO [I-D.ietf-geopriv-domauth].
4.3 Location Request
A location request is an HTTP POST over TLS (port 443) [RFC2818]
using the path "/location-server".
The request may be made by one of two types of entities, a
client-device wishing to determine its own location, or a
proxy-device making a location request on behalf of a client-device
that may not be location aware. Where a proxy-device is requesting
location on behalf of a client-device, the "ip" value and the IP
address of the requesting node may not match. This is acceptable
providing the Location Server and proxy-device have a suitable trust
relationship in place, for example if the proxy and Location Server
are colocated in the same network. If the requesting entity is not
explicitly trusted by the Location Server, the Location Server MUST
reject the request if the "ip" value and the source IP address of the
Winterbottom, et al. Expires August 11, 2005 [Page 7]
Internet-Draft HELD February 2005
request do not match.
Location requests are made through an HTTP POST or GET request, as
defined in [RFC2616]. Rules and location information may be included
in the request by using the file upload methods described in
[RFC1867]. The request consists of three types of information.
The first type of information is the source information containing
the IP address ("ip") and, optionally, the hardware address
("hwaddr") of the client-device. The second set of information is
the type of location that is needed by the requesting entity. These
fields are included in the request as form entries.
An optional third type of information describes a set of rules and
possibly a client-asserted location. These are uploaded as a PIDF-LO
document.
4.3.1 Form Fields
When location is being requested by the client-device itself, then
both "ip" and "hwaddr" MUST be provided. When the location is being
requested by a proxy-device on behalf of a client-device then only
"ip" MUST be provided, however both SHOULD be provided if available.
4.3.1.1 ip
The "ip" represents the source IP address of the client-device to
which the location is attributed.
4.3.1.2 hwaddr
The "hwaddr" is the source MAC address of the client-device to which
the location is attributed.
4.3.1.3 locationtype
The locationtype element is an optional element that can be used by
the requestor to specify the type of location information to be
returned. This is a complex type and consequently may contain
multiple values. The valid values are:
locationkey provides a requesting target a means to obtain a domain
specific identifier that it can subsequently distribute to third
parties. This allows suitably authorized third parties to obtain
location information on-behalf of the client-device without the
client-device needing to maintain a session with the third party.
The requesting client-device can provide a rule-set (described
later) enabling the Location Server to suitably identify
Winterbottom, et al. Expires August 11, 2005 [Page 8]
Internet-Draft HELD February 2005
authorized third parties. In addition to this, the client-device
may alter the ruleset at any time by providing a new ruleset to
the Location Server
geodetic instructs the Location Server to return a geodetic location
for the client-device if possible.
jurisdictionalCivic instructs the Location Server to return a civic
location, as defined in [I-D.ietf-geopriv-pidf-lo], where the
civic address corresponds to the jurisdicational address in which
the client-device resides. In many cases this is the same as the
postal address.
postalCivic instructs the Location Server to return the civic
location, as defined in [I-D.ietf-geopriv-pidf-lo], where the
civic address corresponds to the postal address in which the
client-device resides. In many cases this is the same as the
jurisdictional address.
4.3.1.4 exact
The "exact" element is a flag that relates to the "locationtype"
values. If exact is set to "true", then the Location Server MUST
return an error if the Location Server is unable to provide all of
the location types requested. If "exact" is set to "false" then the
Location Server will provide location on a best effort basis. If the
"exact" flag is not explicitly included in the request then it MUST
be assumed to have a value of "false".
4.3.1.5 signed
The "signed" flag allows the device to request a signed location
object as defined in [I-D.ietf-geopriv-domauth]. A value of "true"
indicates a request for a signed location. If not present a value of
"false" MUST be assumed.
4.3.1.6 pidflo
This is a file upload field and is described in detail in Section
4.3.2.
4.3.2 PIDF-LO Document
PIDF-LO is the IETF mechanism for expressing Location Information and
is defined in [I-D.ietf-geopriv-pidf-lo]. The PIDF-LO encapsulates a
set of information relating to the location of some entity. This
information may include who the enitity is, where the entity
physically is (location), who may know where the entity is (rules),
and when this location was determined (timestamp). The Location
Request message uses the PIDF-LO to convey two things. Firstly it
allows the client-device to specify location rules to the Location
Winterbottom, et al. Expires August 11, 2005 [Page 9]
Internet-Draft HELD February 2005
Server on how and to whom the Location Server may distribute the
client-device's location. Secondly, it allows the client-device to
assert a possibly more precise location for consideration by the
Location Server.
4.3.2.1 Usage Rules
The GeoPriv working group has defined rules and policies governing
the usage of location information, these are addressed in references
[I-D.ietf-geopriv-common-policy] and [I-D.ietf-geopriv-policy].
Since rules are applicable when third parties wish to access location
information, they are most applicable here when a location-key has
been requested by the target. At a minimum the Location Server MUST
implement identity conditions as defined in
[I-D.ietf-geopriv-common-policy], and MUST not provide location
information to any third-party for which it does not have an explicit
rule indicating that it may do so.
The rules are transferred from the target to the Location Server
inside a PIDF-LO "usage-rule" element. Since the PIDF-LO and the
rules are an optional component, the Location Server must have a
default ruleset that it MUST apply in the event that the
client-device has not supplied one. The default ruleset SHALL
prohibit the Location Server from providing location information to
any unauthorized third-party. The default ruleset MAY include
specific third-parties as mandated by local regulations, for example
emergency services.
4.3.2.2 Location Assertion
Location assertion is most applicable when a client-device requests a
signed PIDF-LO for a self-determined location. In this situation the
device may be able to provide additional or more precise information
than the Location Generator available to the Location Server. The
location assertion mechanism allows the device to tell the Location
Server where it thinks it is and by comparing this location against
that provided by a Location Generator, the Location Server may assert
that indeed the location provided by the device is correct.
Conversely if the location provided by the client-device is
significantly different to that provided by the Location Generator
then the Location Server MAY fail the assertion.
If the Location Server is unable to assert the location provided by
the client-device as being correct then the Location Server MUST do
one of two things depending on the value of the "exact" flag. If
"exact" is set to "true" then the Location Server MUST return an
error to the client-device. If the "exact" flag is set to "false",
then the Location Server MUST return the location provided by the
Winterbottom, et al. Expires August 11, 2005 [Page 10]
Internet-Draft HELD February 2005
Location Generator.
4.4 Third Party Location Request Message
This enables third-parties that have a location-key to request the
location of a client-device from the Location Server. The
third-party must be authorized to use the location-key and this
authorization is determined by the usage rules presented to the
Location Server by the client-device.
A third-party location request is an HTTP request using the
location-key, however processing takes place in three parts;
Authentication, client-identification, location authorization.
Authentication techniques are described in Section 4.6.
4.5 Location Response Message
Location response messages contain the same format regardless of
whether they are requested by the client-device, a proxy-device or an
authorized third-party. Some status codes may be specific to the
type of request that is taking place as will be discussed in this
section of the paper.
The general form a of response will be a status code, and where
possible a PIDF-LO that will subscribe to the rules and forms
outlined in [I-D.ietf-geopriv-pidf-lo-profile]. The status codes
that must be supported are listed below:
100 Continue is expected to be used where the Location Server needs
to use a slower mechanism to determine the location of a
client-device, for example needing to walk through bridge MIBs or
such like. In such a case it may take some time to determine the
client-device's location so the "100 Continue" status is returned
to inform that the client-device that the operation is proceeding.
This status code may also be used in response to a third-party or
proxy-device making a location request.
200 OK is returned whenever a valid location meeting the requested
criteria has been determined. This may be returned to a
client-device, proxy-device or to a third-party.
206 Partial Content MUST only ever be returned to a client-device.
The Location Server will use this return code if the client-device
has requested several types of location information and the
Location Server is only able to satisfy some of them in the
response. The Location Server MUST only use this return code if
the exact flag has been set to false in the location request.
Winterbottom, et al. Expires August 11, 2005 [Page 11]
Internet-Draft HELD February 2005
400 Bad request is returned by the Location Server to the requesting
party if required data is incorrect, missing or badly formatted.
401 Unauthorized is returned by the Location Server if a third-party
requests the location of a client-device and fails authentication
checks.
403 Forbidden is returned by the Location Server if the third-party
does not satisfy the usage rules provided by the client-device. A
server MAY return a "404 Not Found" to prevent the requesting
party from knowing that the location-key is in use.
404 Not Found is returned by the Location Server in response to a
location request message when the client-device's location cannot
be determined. This response code may also be used in response to
the third-party location request message when the location-key
does not validate a client-device at the Location Server, or if
the location of the client-device cannot be determined.
406 Not Acceptable is returned by the Location Server to a
client-device if and only if the client-device has attempted to
assert a location to the Location Server with the exact and signed
flags set to true, and the Location Server is unable to assert
that the provided location is correct. This error code is
specific to the Location Server not being able to assert the
location provided and must not be returned unless this is the only
source of error when the exact flag is set to true.
408 Request Timeout is used by the Location Server in response to any
location request message when the Location Server has not been
able to determine the location of the client-device within a
prescribed period of time. Note that this response is different
from a "404 Not Found" in that the 404 message must only be sent
if there is a response from the Location Generator indicating that
the client location cannot be determined.
416 Request Range not satisfiable is returned by the Location Server
when a particular type of location information has been requested
by the client-device with the exact flag set to true and the
Location Server is unable to satisfy the request.
501 Not Implemented is returned by the Location Server if requested
functionality is not implemented by the server.
4.6 Authentication
Authentication may be achieved either through the use of client-side
certificates attached to the TLS session, or through the use of
Security Assertion Markup Language (SAML). When client-side
certificates are used the corresponding common name SHOULD be lifted
from the certificate and used to match against the identity
components in the usage ruleset provided by the client-device.
Once the third-party has been authenticated, authorization of the
third-party is checked against the cached rules. If the third-party
Winterbottom, et al. Expires August 11, 2005 [Page 12]
Internet-Draft HELD February 2005
request fails authentication then a "401 Unauthorized" status is
returned. If the third-party fails to meet the criteria specified in
the usage rules then either a "403 Forbidden" or a "404 Not Found"
status code is returned. On success a status code of "200 OK" is
returned along with a PIDF-LO representing the location of the
client-device.
4.7 Session Management
The protocol described thus far implies in some instances that a
session or state is maintained between the client-device and the
Location Server. State information is required by the Location
Server in two instances; firstly when the client-device has requested
a location-key, and secondly when the client-device has requested a
signed location. Sessions are established and maintained through the
use HTTP cookies, and the client-device is expected to re-request
location information from the Location Server prior to the expiry
time indicated in the session cookie. In addition the Location
Server SHOULD include an explicit "Expires" header in the response to
any request, and this value SHOULD match the expiry time of the
cookie. The Location Server SHOULD maintain client-device session
data until a cookie expires, at which time session data MUST be
deleted.
As part of an active session the Location Server will maintain the
network identity of the client-device (IP and MAC address), it will
maintain any ruleset that was passed to it from the client-device,
and the location-key if one has been requested. In addition, the
Location Server SHOULD NOT change the location-key value through the
course of the session. In cases where neither a location-key or a
signed location is requested there is no requirement for the Location
Server to maintain client-device sessions and a cookie SHOULD NOT be
exchanged.
A client-device may change its published usage rules at any time by
including the new usage rules (in their entirety) to the Location
Server in an explicit location request. The client-device MUST
include the cookie in this request or a new session is created.
Winterbottom, et al. Expires August 11, 2005 [Page 13]
Internet-Draft HELD February 2005
5. Examples
The following subsections represent a few examples of location
requests. Returned presence documents have been abbreviated.
5.1 Simple Location Request
In this example a client is simply making a request for a location.
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Content-Type: application/x-www-form-urlencoded
Content-Length: 43
ip=192.168.1.254&hwaddr=a0b1c2d3e4f5
A positive response header from the Location Server to the
client-device would look similar to:
HTTP/1.x 200 OK
Server: My Location-Server
Connection: close
Content-Length: 1787
Content-Type: application/pidf+xml
5.2 Location Key with Rules Request
In this example the client-device requests a location-key from the
Location Server and includes a minimal set of rules allowing only the
road-side assistance third-party to access its location. The example
includes both the client-device request and the subsequent server
response.
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Content-Type: multipart/form-data; boundary=-29733
Content-Length: 1787
Winterbottom, et al. Expires August 11, 2005 [Page 14]
Internet-Draft HELD February 2005
---29733
Content-Disposition: form-data; name="ip"
192.168.1.254
---29733
Content-Disposition: form-data; name="hwaddr"
a0b1c2d3e4f5
---29733
Content-Disposition: form-data; name="locationtype"
Locationkey
---29733
Content-Disposition: form-data;
name="pidflo";
filename="location_rules_only.xml"
Content-Type: application/pidf+xml
helpme@roadside.assistance.com
2005-02-08T15:38:43+10:00
---29733--
Winterbottom, et al. Expires August 11, 2005 [Page 15]
Internet-Draft HELD February 2005
The server responds with a location-key as requested, after storing
the usage rules.
HTTP/1.x 200 OK
Server: My Location-Server
Connection: close
Content-Length: 43
Content-Type: text/plain
pres:F72hkp23sa@location-server.example.com
5.3 Civic Location Request
The following example shows the client-device requesting a
jursidictional civic location, and the corresponding header that
would be returned by the server.
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Content-Type: application/x-www-form-urlencoded
Content-Length: 69
ip=192.168.1.254&hwaddr=a0b1c2d3e4f5&
locationtype=jurisdictionalCivic
The server provides a jurisdictional civic address in response:
HTTP/1.x 200 OK
Server: My Location-Server
Connection: close
Content-Length: 1787
Content-Type: application/pidf+xml
5.4 Exact and Signed Location Request
In the example below the client-device requests an exact signed civic
postal location.
Winterbottom, et al. Expires August 11, 2005 [Page 16]
Internet-Draft HELD February 2005
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Content-Type: application/x-www-form-urlencoded
Content-Length: 84
ip=192.168.1.254&hwaddr=a0b1c2d3e4f5&locationtype=postalCivic&
signed=true&exact=true
The Location Server may have a civic postal address and may be able
accommodate the client-device's request. Assuming this is the case
then the response would like similar to:
HTTP/1.x 200 OK
Server: My Location-Server
Connection: close
Content-Length: 1787
Content-Type: application/pidf+xml
If however the Location Server determined that it was only able to
provide, for arguments sake, a geodetic location rather than the
requested postal civic address then the Location Server MUST respond
with a "416 Request Range not satisfiable" with a suitable message
indicating exactly what could not be provided.
HTTP/1.x 416 Request Range not satisfiable
Server: My Location-Server
Connection: close
Content-Type: text/plain
Content-Length: 79
Server unable to provide postal civic address
Only Geodetic location available.
5.5 Location Assertion
In the example that follows the client-device contains an on-board
GPS so that the device can accurately determine where it is. The
client-device request a signed geodetic location against which it
will assert its GPS measured location
Winterbottom, et al. Expires August 11, 2005 [Page 17]
Internet-Draft HELD February 2005
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Content-Type: multipart/form-data; boundary=-640223
Content-Length: 2197
---640223
Content-Disposition: form-data; name="ip"
192.168.1.254
---640223
Content-Disposition: form-data; name="hwaddr"
a0b1c2d3e4f5
---640223
Content-Disposition: form-data; name="locationtype"
geodetic
---640223
Content-Disposition: form-data; name="signed"
true
---640223
Content-Disposition: form-data; name="pidflo"; filename="loca.xml"
Content-Type: text/xml
-34.407 150.88001
2005-02-08T15:38:43+10:00
Winterbottom, et al. Expires August 11, 2005 [Page 18]
Internet-Draft HELD February 2005
---640223--
If the Location Server is able to satisfy the request for a geodetic
location and the assertion was successful then a "200 OK" status is
returned to the client-device along with the PIDF-LO providing the
location. If however the Location Server was unable to assert the
location then a "206 Partial Content" status message, and the
location that could be provided are returned to the client-device.
5.6 Third Party Location Request
The third-party location request is shown below:
GET /location-server
?locationkey=pres%3Ax45tgq78%40location-server.example.com HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml, text/xml,application/xml
A positive response to this message will be a status of "200 OK" and
a PIDF-LO document describing the location of the client-device.
HTTP/1.x 200 OK
Server: My Location-Server
Connection: close
Content-Length: 1787
Content-Type: application/pidf+xml
5.7 Session Management
In the following example the client-device is requesting a
location-key, the server responds with a location-key and an http
session cookie.
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Content-Type: multipart/form-data; boundary=-29733
Content-Length: 1854
---29733
Winterbottom, et al. Expires August 11, 2005 [Page 19]
Internet-Draft HELD February 2005
Content-Disposition: form-data; name="ip"
192.168.1.254
---29733
Content-Disposition: form-data; name="hwaddr"
a0b1c2d3e4f5
---29733
Content-Disposition: form-data; name="locationtype"
locationkey
---29733
Content-Disposition: form-data;
name="pidflo";
filename="location_rules_only.xml"
Content-Type: application/pidf+xml
helpme@roadside.assistance.com
2005-02-08T15:38:43+10:00
---29733--
Winterbottom, et al. Expires August 11, 2005 [Page 20]
Internet-Draft HELD February 2005
The server creates a session for the client-device, associating the
newly created location-key and the provided usage rules. The server
then adds a "Set-Cookie" header in the response to ensure that the
client-device can identify this session.
HTTP/1.x 200 OK
Server: My Location-Server
Connection: close
Set-Cookie: httplocationID=F168jiwdjw92jds09;
expires: Tue, 08 Feb 2005 16:08:43 GMT;secure
Content-Length: 43
Content-Type: text/plain
Expires: Tue, 08 Feb 2005 16:08:43 GMT
pres:F72hkp23sa@location-server.example.com
The client-device may then at some time prior to the expiry of the
cookie make a request to keep the session open.
POST /location-server HTTP/1.1
Host: location-server.example.com
Accept: application/pidf+xml,text/xml,application/xml,text/plain
Cookie: httplocationID=F168jiwdjw92jds09
Connection: close
Content-Type: multipart/form-data; boundary=-29733
Content-Length: 1854
---29733
Content-Disposition: form-data; name="ip"
192.168.1.254
---29733
Content-Disposition: form-data; name="hwaddr"
a0b1c2d3e4f5
---29733
Content-Disposition: form-data; name="locationtype"
locationkey
---29733
Content-Disposition: form-data;
name="pidflo";
filename="location_rules_only.xml"
Content-Type: application/pidf+xml
helpme@roadside.assistance.com
delivery@pizza.example.com
2005-02-08T16:06:43+10:00
---29733--
The Location Server should respond with an updated expiry time but
the same location-key value as it provided in response to the first
request. If the client-device makes a request to the Location Server
without including the cookie in the header then the Location Server
MUST provide the client-device with a new location-key and
immediately expire the old location-key. Note that the usage rules
specified in the more recent request replace the original usage
rules.
Winterbottom, et al. Expires August 11, 2005 [Page 22]
Internet-Draft HELD February 2005
6. Security Considerations
All requests for location and subsequent location conveyance MUST be
done using secure HTTP (https).
Exactly how validation and authentication of third-parties using
client-side certificates and SAML identity session is implemented is
beyond the scope of this paper but consideration should be given to
employing best current practices.
State information associated with a session at the Location Server
MUST be purged when a session expires. Lengthy expiry times SHOULD
be avoided.
The location-key MUST NOT reveal any information about the
client-device with the possible exception of the network in which it
resides. It is recommended that a cryptographically random sequence
of characters be used as the pseudonym in the location-key.
Winterbottom, et al. Expires August 11, 2005 [Page 23]
Internet-Draft HELD February 2005
7. IANA Considerations
A new DNS services (SVR) field type of LOCSERV+HTTP with a protocol
type of TCP is required in order for a client-device to discover the
Location Server in the access network.
Winterbottom, et al. Expires August 11, 2005 [Page 24]
Internet-Draft HELD February 2005
8. Acknowledgements
The authors wish to thank Rohan Mahy and Hannes Tschofenig for their
useful comments and guidance.
Winterbottom, et al. Expires August 11, 2005 [Page 25]
Internet-Draft HELD February 2005
9. References
9.1 Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[I-D.ietf-geopriv-pidf-lo]
Peterson, J., "A Presence-based GEOPRIV Location Object
Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W.
and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in
HTML", RFC 1867, November 1995.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[I-D.ietf-geopriv-common-policy]
Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-03 (work in
progress), October 2004.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information",
draft-ietf-geopriv-policy-05 (work in progress), November
2004.
[I-D.ietf-geopriv-dhcp-civil]
Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information",
draft-ietf-geopriv-dhcp-civil-04 (work in progress),
Winterbottom, et al. Expires August 11, 2005 [Page 26]
Internet-Draft HELD February 2005
October 2004.
[I-D.ietf-geopriv-domauth]
Thomson, M. and J. Winterbottom, "Domain Authorization for
PIDF-LO, draft-thomson-domain-auth-00", February 2005.
[I-D.ietf-geopriv-pidf-lo-profile]
Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations,
draft-winterbottom-geopriv-pdif-lo-profile-00", February
2005.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
9.2 Informative References
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002.
Authors' Addresses
James Winterbottom
Nortel
Wollongong
NSW Australia
EMail: winterb@nortel.com
Martin Dawson
Nortel
Wollongong
NSW Australia
EMail: mdawson@nortel.com
Martin Thomson
Nortel
Wollongong
NSW Australia
EMail: martin.thomson@nortel.com
Winterbottom, et al. Expires August 11, 2005 [Page 27]
Internet-Draft HELD February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Winterbottom, et al. Expires August 11, 2005 [Page 28]