[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05

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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             entity="pres:anonymous@location-server.example.com">
     <!-- contents of PIDF-LO goes in here -->
   </presence>


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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:cp="urn:ietf:params:xml:ns:common-policy"
             entity="pres:anonymous@location-server.example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info/>
           <gp:usage-rules>
             <cp:ruleset>
               <cp:rule id="rul123">
                 <cp:conditions>
                   <cp:identity>
                     <cp:id>helpme@roadside.assistance.com</cp:id>
                   </cp:identity>
                 </cp:conditions>
                 <cp:actions/>
                 <cp:transformations/>
               </cp:rule>
             </cp:ruleset>
           </gp:usage-rules>
         </gp:geopriv>
       </status>
       <timestamp>2005-02-08T15:38:43+10:00</timestamp>
     </tuple>
   </presence>

   ---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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             entity="pres:anonymous@location-server.example.com">
     <!-- contents of PIDF-LO goes in here -->
   </presence>


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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             entity="pres:anonymous@location-server.example.com">
     <!-- contents of PIDF-LO goes in here -->
   </presence>

   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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:cp="urn:ietf:params:xml:ns:common-policy"
             xmlns:gml="http://opengis.net/gml"
             entity="pres:anonymous@location-server.example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:position>
               <gml:Point srsName="urn:ogc:def:crs:EPSG:4326:6.6">
                 <gml:pos>-34.407 150.88001</gml:pos>
               </gml:Point>
             </gml:position>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2005-02-08T15:38:43+10:00</timestamp>
     </tuple>
   </presence>



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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             entity="pres:anonymous@location-server.example.com">
     <!-- contents of PIDF-LO goes in here -->
   </presence>


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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:cp="urn:ietf:params:xml:ns:common-policy"
             entity="pres:anonymous@location-server.example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info/>
           <gp:usage-rules>
             <cp:ruleset>
               <cp:rule id="rul123">
                 <cp:conditions>
                   <cp:identity>
                     <cp:id>helpme@roadside.assistance.com</cp:id>
                   </cp:identity>
                 </cp:conditions>
                 <cp:actions/>
                 <cp:transformations/>
               </cp:rule>
             </cp:ruleset>
           </gp:usage-rules>
         </gp:geopriv>
       </status>
       <timestamp>2005-02-08T15:38:43+10:00</timestamp>
     </tuple>
   </presence>

   ---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

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"



Winterbottom, et al.    Expires August 11, 2005                [Page 21]


Internet-Draft                    HELD                     February 2005


             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:cp="urn:ietf:params:xml:ns:common-policy"
             entity="pres:anonymous@location-server.example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info/>
           <gp:usage-rules>
             <cp:ruleset>
               <cp:rule id="rul123">
                 <cp:conditions>
                   <cp:identity>
                     <cp:id>helpme@roadside.assistance.com</cp:id>
                     <cp:id>delivery@pizza.example.com</cp:id>
                   </cp:identity>
                 </cp:conditions>
                 <cp:actions/>
                 <cp:transformations/>
               </cp:rule>
             </cp:ruleset>
           </gp:usage-rules>
         </gp:geopriv>
       </status>
       <timestamp>2005-02-08T16:06:43+10:00</timestamp>
     </tuple>
   </presence>

   ---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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/