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]