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

Versions: 00 01 02 03 04 05

GEOPRIV                                                  J. Winterbottom
Internet-Draft                                                 M. Dawson
Expires: April 24, 2006                                       M. Thomson
                                                                  Andrew
                                                                B. Stark
                                                               BellSouth
                                                        October 21, 2005


                 HTTP Enabled Location Delivery (HELD)
            draft-winterbottom-http-location-delivery-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a means by which a Target may request
   location from a Location Server using HTTP as a GEOPRIV 'using
   protocol'.  The protocol uses standard HTTP request methods with
   parameters encoded as form data.  Methods for discovering accessible
   servers are also described.



Winterbottom, et al.     Expires April 24, 2006                 [Page 1]


Internet-Draft                    HELD                      October 2005


Table of Contents

   1.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Changes from -01 to -02  . . . . . . . . . . . . . . . . .  4
     1.2.  Changes from -00 to -01  . . . . . . . . . . . . . . . . .  5
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Access Network . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Device or User . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Location Server Discovery  . . . . . . . . . . . . . . . . . . 11
     5.1.  SLP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  DNS Service Record . . . . . . . . . . . . . . . . . . . . 12
   6.  Protocol Specifics . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  HELD Protocol Stack  . . . . . . . . . . . . . . . . . . . 13
     6.2.  HELD Tasks . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Location Information Request Parameters  . . . . . . . . . 14
       6.3.1.  locationURI  . . . . . . . . . . . . . . . . . . . . . 15
       6.3.2.  locationType . . . . . . . . . . . . . . . . . . . . . 15
       6.3.3.  pidf-lo  . . . . . . . . . . . . . . . . . . . . . . . 16
       6.3.4.  exact  . . . . . . . . . . . . . . . . . . . . . . . . 17
       6.3.5.  updateURI  . . . . . . . . . . . . . . . . . . . . . . 17
       6.3.6.  updateResponseTime . . . . . . . . . . . . . . . . . . 18
       6.3.7.  rulesetURI . . . . . . . . . . . . . . . . . . . . . . 18
       6.3.8.  ruleset  . . . . . . . . . . . . . . . . . . . . . . . 19
       6.3.9.  retentionInterval  . . . . . . . . . . . . . . . . . . 19
       6.3.10. responseTime . . . . . . . . . . . . . . . . . . . . . 20
       6.3.11. lero . . . . . . . . . . . . . . . . . . . . . . . . . 20
       6.3.12. signed . . . . . . . . . . . . . . . . . . . . . . . . 21
       6.3.13. Identity Parameters  . . . . . . . . . . . . . . . . . 21
       6.3.14. Extension parameters . . . . . . . . . . . . . . . . . 22
   7.  Location Information Response  . . . . . . . . . . . . . . . . 23
     7.1.  Location Assertion . . . . . . . . . . . . . . . . . . . . 24
     7.2.  URI Generation and Identity Protection . . . . . . . . . . 24
       7.2.1.  Location URI . . . . . . . . . . . . . . . . . . . . . 24
       7.2.2.  Presentity URI . . . . . . . . . . . . . . . . . . . . 24
   8.  Authentication . . . . . . . . . . . . . . . . . . . . . . . . 26
     8.1.  Location Server and Location Generator Authentication  . . 26
     8.2.  Target Authentication  . . . . . . . . . . . . . . . . . . 26
     8.3.  Location Recipient Authentication  . . . . . . . . . . . . 27
     8.4.  Authentication for Location Update . . . . . . . . . . . . 27
   9.  Persistent State at the Location Server  . . . . . . . . . . . 28
     9.1.  Initiating Contexts  . . . . . . . . . . . . . . . . . . . 29
     9.2.  Terminating Contexts . . . . . . . . . . . . . . . . . . . 29
   10. Location Server Interactions . . . . . . . . . . . . . . . . . 31
     10.1. Delegating Location URI Allocation . . . . . . . . . . . . 31



Winterbottom, et al.     Expires April 24, 2006                 [Page 2]


Internet-Draft                    HELD                      October 2005


     10.2. Delegating Location Determination  . . . . . . . . . . . . 32
     10.3. Network Address Translation  . . . . . . . . . . . . . . . 32
   11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     11.1. Simple Location Request  . . . . . . . . . . . . . . . . . 33
       11.1.1. Request for Any Location . . . . . . . . . . . . . . . 33
       11.1.2. Request for Civic Location . . . . . . . . . . . . . . 34
     11.2. Location URI Request . . . . . . . . . . . . . . . . . . . 35
       11.2.1. Request Location URI Specifying rulesetURI . . . . . . 36
       11.2.2. Requesting locationURI Specifying ruleset  . . . . . . 39
       11.2.3. Location Recipient Using locationURI . . . . . . . . . 40
     11.3. Location Assertion . . . . . . . . . . . . . . . . . . . . 41
     11.4. Requests Using Update and Location URIs  . . . . . . . . . 45
     11.5. Location Server to Location Generator  . . . . . . . . . . 46
     11.6. Location Server to Location Server . . . . . . . . . . . . 47
   12. Addresssing Using-Protocol Requirements  . . . . . . . . . . . 51
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 53
     13.1. Identity Assurance and Location Fraud  . . . . . . . . . . 53
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 55
     14.1. DHCP Option Code Registration  . . . . . . . . . . . . . . 55
     14.2. SLP Service Template Registration  . . . . . . . . . . . . 55
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
     16.1. Normative references . . . . . . . . . . . . . . . . . . . 58
     16.2. Informative references . . . . . . . . . . . . . . . . . . 59
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
   Intellectual Property and Copyright Statements . . . . . . . . . . 62

























Winterbottom, et al.     Expires April 24, 2006                 [Page 3]


Internet-Draft                    HELD                      October 2005


1.  Change Log

   This section is intended for removal before publication.

1.1.  Changes from -01 to -02

   Changes based on feedback and further work (in no particular order):

   o  Used GEOPRIV terminology, as in [RFC3693].

   o  Added SLP as a discovery option.

   o  Added concept of using HELD to communicate with a Location
      Generator.

   o  Added short section on LS-LS communication using HELD, which also
      covers LS-LG and the NAT problem.

   o  Added common tasks and the associated parameters that are used to
      complete those tasks.

   o  Added LERO.

   o  Changed location URI request to use the Content-Location header.
      Location information is now always provided (except when a LERO is
      requested).

   o  Moved examples section.

   o  Corrected examples based on text and added more examples.

   o  Updated reference to RFC2388.

   o  Made identity parameters (ip address, hardware address) more
      explicit and identifiable, added extension parameters.

   o  Expanded security considerations.

   o  Added notes about IP spoofing in target authentication section.

   o  Removed "on behalf of".

   o  Expanded sessions section, used less overloaded word "context"
      instead of "session", included better guidance on when contexts
      should be established and when they should be purged.

   o  Miscellaneous clarifications, rewordings and reformatting.




Winterbottom, et al.     Expires April 24, 2006                 [Page 4]


Internet-Draft                    HELD                      October 2005


1.2.  Changes from -00 to -01

   This was a major revision - very little content was retained.
















































Winterbottom, et al.     Expires April 24, 2006                 [Page 5]


Internet-Draft                    HELD                      October 2005


2.  Introduction

   This document describes a protocol that employs secure HTTP as a
   GEOPRIV 'using protocol' to deliver location information relating to
   a Target from a Location Server.  The Target discovers or is informed
   of the Location Server and establishes a context with the server.
   The Location Server constructs a PIDF-LO document and returns this to
   the Target.  This protocol facilitates requesting specific forms of
   location including geodetic, postal civic, jurisdictional civic and
   that the Location Server sign the location as specified in
   [I-D.thomson-domain-auth].

   This document concentrates solely on the provision of location
   information, it does not describe how location may be generated.  The
   advantage of this is that this enables the use of this protocol in
   many different network environments due to its independence from the
   link layer.  This aligns this document with the model described in
   [RFC3693] by separating the Location Server and Location Generator
   functions and focussing on only the Location Server.

   Currently proposed location delivery mechanisms, such as those
   defined in [RFC3825] and [I-D.ietf-geopriv-dhcp-civil], tightly
   couple location determination (generation) and location acquisition.
   While this coupling offers some benefits, it also has drawbacks.
   Many residential broadband services, for example, do not use DHCP to
   deliver host configuration data.  Even where DHCP is employed the
   access is made up of a number of segments maintained and controlled
   by different organizations and business entities.  The operator of
   the DHCP server might have no direct knowledge of where physical
   access points terminate, as the equipment is outside their control.
   This makes it difficult for the provider of the IP address to provide
   a logical address to physical location mapping.  HELD overcomes this
   problem by allowing Location Server to Location Server and Location
   Server to Location Generator communications to occur in a common way
   so that the node most able to provide location is ultimately the
   source of the location information.  A second drawback is that binary
   protocols are less able to accommodate new features and data that are
   introduced as the XML representation evolves.

2.1.  Access Network

   Providing a location service is the responsibility of an access
   network.  This is primarily because the access network must be
   physically located in some fashion near an endpoint, either though
   hardware, such as cabling, or through electromagnetic transmission.
   In addition, in able for location to be made available for all
   endpoints, the endpoint cannot be relied upon for location
   information, due to lack of appropriate methods for sourcing this



Winterbottom, et al.     Expires April 24, 2006                 [Page 6]


Internet-Draft                    HELD                      October 2005


   information.  Therefore, the access network must provide a means for
   determining the location of endpoints within the access network.

   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.

2.2.  Device or User

   Location information provided for a device is often represented as
   the location of a user.  However, in this document location
   information is attributed to a device and not a person.  Primarily,
   this is because location determination technologies are generally
   designed to locate a device and not a person.  In addition to this,
   unless the device requires user authentication, there can be no level
   of assurance that any particular individual is using the device at
   that instance.  Thus, if any claim is to be made with regards to the
   veracity of location information, the distinction between user and
   device must be made explicit.

   This distinction should not lead to the impression that the location
   of a device does not impact the privacy constraints required by this
   protocol.  Revealing the location of a device almost invariably
   reveals some information about the location of the user of that
   device, therefore the same level of privacy protection demanded by a
   user is required for their device.

   It is expected that, for most applications, the location of a device
   will be used interchangably for the location of the user of that
   device.  This requires either some additional assurances about the
   link between device and user, or an acceptance of the aforementioned
   limitations.


















Winterbottom, et al.     Expires April 24, 2006                 [Page 7]


Internet-Draft                    HELD                      October 2005


3.  Terminology

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

   This document reuses the terms Target, Location Server, Location
   Generator, Location Recipient and Using-Protocol as defined in
   [RFC3693].  In some specifications the Location Server is referred to
   as a Location Information Server or LIS.  Note that in this context,
   the Location Server is distinct from what is alternatively referred
   to as a Registrar in other contexts.

   This document also introduces a new acronym, the Local Emergency
   Routing Option (LERO), which is a locality-specific option that may
   be provided by a Location Server to a Target to assist with emergency
   services contact.


































Winterbottom, et al.     Expires April 24, 2006                 [Page 8]


Internet-Draft                    HELD                      October 2005


4.  Overview

   This document describes how a Target requests location information
   from a Location Server, including how a Location Server is
   discovered.

   Location Server discovery is achieved through the use of a new DHCP
   option, a new DNS SRV record [RFC2782], Service Location Protocol
   (SLP) [RFC2608] or static configuration.  A Location Server is
   identified by a URI that identifies the Location Server as an HTTP
   service using the "https" scheme.

   The Target initiates an HTTP connection with the Location Server.  If
   the Target only requires location information with no particular
   constraints it uses the HTTP GET method, otherwise it includes
   request parameters using the HTTP POST method.

   The Location Server identifies the Target based on its IP address.
   The Location Server then identifies a Location Generator for the
   Target, which determines the location of the Target.  The Location
   Server will take the generated location and produce a PIDF-LO
   document that is subsequently returned to the requesting Target.  The
   PIDF-LO document can contain geodetic information [GML3] and/or civic
   address information [I-D.thomson-revised-civic-lo], [I-D.ietf-
   geopriv-pidf-lo].

   In addition to returning a location to a Target requesting its own
   location, the protocol provides support for a location URI, which
   enables by-reference distribution of location information by the
   Target.  This has a number of benefits which are described in more
   detail by [I-D.winterbottom-location-uri].

   The following figure shows the relationship between the Location
   Server and the Target, Location Generator and Location Recipient:

                Location                       Location
   +--------+    Request     +------------+    Request   +-----------+
   | Target |--------------->|  Location  |<-------------| Location  |
   |        |<---------------|   Server   |------------->| Recipient |
   +--------+  Location/URI  +------------+    Location  +-----------+
                                    ^
                                    |
                                Location
                                    |
                              +-----------+
                              | Location  |
                              | Generator |
                              +-----------+



Winterbottom, et al.     Expires April 24, 2006                 [Page 9]


Internet-Draft                    HELD                      October 2005


   HELD is not restricted to serving as a protocol for the acquisition
   of location information, it can be used by a Location Server to gain
   access to particular functions that it may not have locally.  A
   Location Server can use HELD to request location information from a
   Location Generator, or a Location Server can request certain
   information from another Location Server.  See Section 10 for
   details.












































Winterbottom, et al.     Expires April 24, 2006                [Page 10]


Internet-Draft                    HELD                      October 2005


5.  Location Server Discovery

   Location Server discovery MAY occur using SLP service discovery, a
   DHCP option, a DNS SRV record, or a preconfigured URL; these methods
   SHOULD be attempted in the given order where available.

5.1.  SLP

   This document registers a service type for SLP that describes a
   location service.  The abstract service prefix "service:locserv:" is
   defined as the base for discovering a location server.  A client that
   requires HELD SHOULD use the URL "service:locserv:https", but this
   registration also allows for schemes other than "https".

   The template in Section 14.2 includes a number of optional attributes
   that may indicate the capabilities of a Location Server.  These
   specifically apply to HELD, but they could apply to any Location
   Server with a similar feature set.  An SLP UA MAY use these
   attributes to assist in selecting a location service.  In the absence
   of desired characteristics a service SHOULD still be selected.

5.2.  DHCPv4

   The DHCPv4 option includes a list of URIs; the first URI must be
   attempted first and subsequent URIs contacted only in the event of a
   problem in retrieving location information.  Each URI must reference
   a service that is able to provide the Target with location
   information.  Where multiple URIs are provided with different
   schemes, a client SHOULD use the first scheme that it supports.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  LOCSERV_URI  |    Length     |    URI List ...               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code: LOCSERV_URI (TBD)

   Length: The length of the URI list in octets

   URI List: A list of one or more URIs separated by the space character

5.3.  DHCPv6

   The DHCPv6 option is similarly formatted to the DHCPv4 option.






Winterbottom, et al.     Expires April 24, 2006                [Page 11]


Internet-Draft                    HELD                      October 2005


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OPTION_LOCSERV_URI       |         option-len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           URI List ...                        .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code: OPTION_LOCSERV_URI (TBD)

   option-len: The length of the URI list in octets

   URI List: A list of one or more URIs separated by the space character

5.4.  DNS Service 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 could therefore look similar to:

     _locserv+http._tcp    SRV 1 0 10001 location-server.example.com.

   A host determines the search suffix based on local configuration,
   which MAY be static, or determined from an automatic configuration
   source.  For example, DHCP options 15 and 119 can indicate possible
   domain suffixes.

   The DNS response indicates a fully qualified domain name for the
   Location Server, as well as a TCP port.  In order to derive a URI
   from this FQDN, the "https" scheme MUST be used with the root path
   ("/").  For the above example, the client constructs a URL as
   follows:

     https://location-server.example.com:10001/














Winterbottom, et al.     Expires April 24, 2006                [Page 12]


Internet-Draft                    HELD                      October 2005


6.  Protocol Specifics

6.1.  HELD Protocol Stack

   HELD is a web services application that uses the POST and GET methods
   of HTTP.  TLS is used a secure transport layer to ensure that HELD
   meets the requirements of a GEOPRIV 'using protocol'.  TLS for
   transporting HTTP is defined [RFC2818].


         +------------+
         |    HELD    |
         +------------+
         |    HTTP    |
         +------------+
         |    TLS     |
         +------------+
         |    TCP     |
         +------------+
         |    IP      |
         +------------+

   HELD relies on the security features of TLS to ensure that location
   information is properly protected against interception and
   modification.  A detailed treatment of requirements, including how
   TLS addresses these is included in Section 12.

6.2.  HELD Tasks

   This section describes common tasks and how HELD may be used to
   accomplish these tasks.  Specifically, which parameters are required
   in request messages to complete those tasks.

   +---------------------------+-----------------+---------------------+
   | Task                      | Applicable      | Applicable          |
   |                           | Parameters      | References          |
   +---------------------------+-----------------+---------------------+
   | Request own location      | locationType    | Section 6.3,        |
   |                           |                 | Section 6.3.2       |
   |                           |                 |                     |
   | Request Target's location | locationType    | Section 6.3,        |
   | from location URI         |                 | Section 6.3.2       |
   |                           |                 |                     |
   | Request location URI      | locationURI and | Section 6.3.1,      |
   |                           | ruleset or      | Section 6.3.7,      |
   |                           | rulsetURI       | Section 6.3.8       |
   |                           |                 |                     |




Winterbottom, et al.     Expires April 24, 2006                [Page 13]


Internet-Draft                    HELD                      October 2005


   | Provide own location to   | locationURI and | Section 6.3.3       |
   | be retrieved by Location  | pidf-lo         |                     |
   | Recipients                |                 |                     |
   |                           |                 |                     |
   | Update authorization      | locationURI and | Section 6.3.1,      |
   | policy                    | ruleset or      | Section 9           |
   |                           | rulesetURI      |                     |
   |                           |                 |                     |
   | Cancel a location URI     | locationURI     | Section 6.3.1,      |
   |                           | (0d)            | Section 9           |
   +---------------------------+-----------------+---------------------+

6.3.  Location Information Request Parameters

   A HELD location information request is either an HTTP GET or POST
   [RFC2616] to the discovered Location Server URI.  Where the
   requesting entity needs to request specific information from, or
   provide specific information to the Location Server the POST method
   MUST be used.

   A request may be made by one of three types of entity: a Target
   requesting its own location of a Location Server, a Location
   Recipient requesting the location of a Target from a Location server,
   or a Location Server querying a Location Generator.  Request
   parameters are included in the body of a POST request using either
   URL-encoding or the "multipart/form-data" encoding defined in
   [RFC2388].  The same type of request is made from the Target, a
   Location Recipient, or a Location Server, the only difference being
   the URI to which the requests are posted.

   It is RECOMMENDED that URL-encoded parameters be indicated by the
   "application/x-www-form-urlencoded" MIME type, however the following
   MIME types MUST also be recognized as including URL-encoded data:
   "application/x-url-urlencoded", "application/x-www-form-urlencoded".

   The Location Server identifies the Target by a different means for
   each request source.  For requests from the Target, the source IP
   address of the connection is used.  Requests from the Location
   Recipient SHOULD be to a globally unique URI that includes
   information that the Location Server can use to identify a particular
   Target.  Where an Location Server requests the location of a Target
   from a Location Generator, the IP address of the Target is included
   as a parameter and additional identity information MAY be included as
   necessary.

   The protocol structure of HELD suitably lends itself to support the
   cascading of location information requests between Location Servers.
   This accommodates complex network structures by enabling distribution



Winterbottom, et al.     Expires April 24, 2006                [Page 14]


Internet-Draft                    HELD                      October 2005


   of location functions across servers.

   The following sub-sections describe each of the parameters in detail.

6.3.1.  locationURI

   The "locationURI" parameter indicates if a location URI is required
   by the Target.

   The value space of this parameter is the superset of the "duration"
   type specified in [W3C.REC-xmlschema-2-20041028], plus the boolean
   type.  A value of "true" implies that a location URI is requested
   with no set time limit; a value of "false" indicates that no location
   URI is requested.  The default value for this parameter is "false".

   The value of this parameter indicates the maximum amount of time that
   the requester wishes the location URI to be valid for; a Location
   Server MAY specify a shorter duration, but MUST NOT provide a longer
   duration than that requested.

   A location URI is provided in the "Content-Location:" header of the
   response message.

   A Location Server MUST create a context in response to a location URI
   request.  The creation of a context is indicated to the Target by the
   presence of a "Set-Cookie2" header [RFC2965]; the value of the
   "Max-Age" parameter of this header indicates when the context
   expires.  See Section 9 for more details on contexts.

   If a cookie is provided in the request, a value of "false", or a zero
   or negative duration for this parameter indicates that the Target
   wishes to cancel a location URI that was already issued.  See
   Section 9.2 for details on terminating contexts.

6.3.2.  locationType

   A form parameter that may have multiple values.  The valid values
   are:

   any: The Location Server SHOULD attempt to provide location
      information in all available forms, however it MAY return any
      location information it has available.  This value SHOULD be
      assumed as the default if no "locationType" is specified.

   geodetic: The Location Server SHOULD return a geodetic location for
      the Target.





Winterbottom, et al.     Expires April 24, 2006                [Page 15]


Internet-Draft                    HELD                      October 2005


   jurisdictionalCivic: The Location Server SHOULD return a
      jurisdictional civic address for the Target.

   postalCivic: The Location Server SHOULD return a postal civic address
      for the Target.

   civic: The Location Server SHOULD return a civic address for the
      Target.  Any type of civic address may be returned.  The location
      server SHOULD ignore this value if a request for
      "jurisdictionalCivic" or "postalCivic" has been made and can be
      satisfied.

   The Location Server SHOULD attempt to provide the location in the
   requested form unless the request cannot be properly satisfied.  If
   the "exact" parameter is set to "true" then the Location Server MUST
   provide the location in the requested form or fail.

   The Location Server SHOULD provide location-information types in the
   same order in which they are requested.

6.3.3.  pidf-lo

   A file describing a location provided by a Target, and the general
   format of PIDF-LO documents that the Target wishes the Location
   Server use when providing location information.

   The "pidf-lo" parameter is transferred to the location server using
   the multipart file transfer, with the MIME type of
   "application/pidf+xml".

   The Location Server SHOULD validate all locations provided in the
   PIDF-LO document.  The Location Server MUST only include location
   information that has been successfully asserted.  If the "exact"
   parameter is set to "true" then any location failing an assertion
   test results in the entire request failing.

   The Location Server fills in the values of the following elements in
   any provided PIDF-LO document with values that it derives or
   determines:

   o  "presentity"

   o  "timestamp"

   o  "retention-expiry"

   o  "method"




Winterbottom, et al.     Expires April 24, 2006                [Page 16]


Internet-Draft                    HELD                      October 2005


   o  "provided-by"

   A Location Server MAY retain published location information when it
   is providing a location URI for a Target.  A Location Server SHOULD
   place time limits on published location information to prevent stale
   information from being provided.  The amount of time that location
   information can be retained depends on a number of factors such as
   the type of network access and the degree of mobility afforded the
   device, therefore local policy should limit how long location
   information is retained.

   If the "exact" parameter is set to "true", then these values MAY be
   changed, but the Location Server MUST NOT insert new elements if they
   are not already present.

   PIDF-LO documents SHOULD contain a "method" element if location
   information is included.

   If the Target wishes authorization policy rules to be included in any
   PIDF-LO documents containing its location, then it MUST include them
   in the "pidf-lo" parameter sent to the Location Server.  The Location
   Server will preserve, but not adhere to, any of these rules.  The
   Location Server will adhere to rules provided in either the
   "rulesetURI" or "ruleset" parameters discussed in subsequent
   sections.

6.3.4.  exact

   The "exact" parameter may have a value of "true" or "false".  If not
   included the default value is "false".

   When set to "true" the "exact" parameter affects the way that the
   "locationType" and "pidf-lo" parameters are interpreted.  See
   Section 6.3.2 and Section 6.3.3 for details.

6.3.5.  updateURI

   The "updateURI" parameter MAY be provided by a Target that is capable
   of determining its own location.  This provides the Location Server
   with a means of interrogating a Target to determine the Target's
   current location.

   A location update URI SHOULD use the "https" scheme so that HELD may
   be employed to request information.

   When requesting location information from a location update URI, the
   following constraints apply:




Winterbottom, et al.     Expires April 24, 2006                [Page 17]


Internet-Draft                    HELD                      October 2005


   o  The Location Server MUST NOT request a location URI, or signed
      location information.

   o  The Location Server MUST NOT include a location update URI, a
      ruleset or ruleset URI.

   o  The Target (or other serving entity) MAY disregard any PIDF-LO
      document provided.

6.3.6.  updateResponseTime

   A form parameter provided to the Location Server in conjunction with
   an "updateURI" as an indication of how long a Target could take to
   respond to a request for location information.

   The "updateResponseTime" is indicative only and is a positive decimal
   value, which may include a decimal point, representing the
   approximate number of seconds that it could take to obtain a
   response.  The Location Server MUST ignore this value if no
   corresponding "updateURI" is provided.  It is RECOMMENDED that
   systems support millisecond precision for this parameter, that is, up
   to three decimal places.

6.3.7.  rulesetURI

   A form parameter that defines a URI to a set of policies and rules
   describing how and to whom a Target's location may be provided.

   The "rulesetURI" is the preferred means by which a Target informs the
   Location Server to whom the Target's location may be divulged.  If a
   "rulesetURI" is provided to the Location Server then the Location
   Server MUST adhere to the rules referenced.  If a "rulesetURI" and a
   "ruleset" are both provided then ONLY the "rulesetURI" MUST be used.

   Rules documents MUST comply with [I-D.ietf-geopriv-common-policy] and
   [I-D.ietf-geopriv-policy].  It is RECOMMENDED that a ruleset URI use
   an "https" scheme.

   If the Target does not provide an authorization policy, using the
   "rulesetURI" or "ruleset" parameters, then the Location Server MUST
   NOT provide location information to any requester.  Note that in
   certain jurisdictions a Location Server MAY include specific third-
   parties as mandated by local regulations, for example emergency
   services.

   If the Target provides a "rulesetURI" that is not accessible,
   contains invalid rules, or cannot be parsed by the Location Server
   then the Location Server SHOULD reject the request and return an



Winterbottom, et al.     Expires April 24, 2006                [Page 18]


Internet-Draft                    HELD                      October 2005


   error.  Note that this implies that a Location Server SHOULD attempt
   to retrieve the ruleset at the time of a request, however a Location
   Server MAY choose not to do this where the requested response time
   might be exceeded.

   It is anticipated that, to improve responsiveness and reduce network
   usage, a Location Server may cache an authorization policy,
   consistent with the rules specified by the Rule Holder.  For
   instance, the Rule Holder may specify retention times using the
   "Expires" header in HTTP [RFC2616].  The impact of changes to
   authorization policies are addressed in Section 9.1.

   Section 11.2.1 demonstrates how a ruleset is associated with a
   location URI.  The ruleset indicated in a request (either by value or
   reference) is bound to the location URI provided in the response.

6.3.8.  ruleset

   A file containing policies and rules describing how and to whom a
   Target's location may be provided.  It is transferred to the Location
   Server using multipart file transfer, with a MIME type of
   "application/auth-policy+xml".

   If a "ruleset" is provided to the Location Server then the Location
   Server MUST adhere to the rules, unless it is also provided with a
   "rulesetURI", in which case the rules referenced by the "rulesetURI"
   take precedence.  Rules documents MUST comply with [I-D.ietf-geopriv-
   common-policy] and [I-D.ietf-geopriv-policy].

   If the Target does not provide an authorization policy, using the
   "ruleset" or "rulesetURI" parameters, then the Location Server MUST
   NOT provide location information to any requester.  Note that in
   certain jurisdictions a Location Server MAY include specific third-
   parties as mandated by local regulations, for example, emergency
   services.

   If the Target provides a "ruleset" that is invalid, or cannot be
   parsed by the Location Server then the request MUST be rejected and
   an error returned.

6.3.9.  retentionInterval

   A form parameter provided to the Location Server to specify the
   length of time that should be allowed for the "retention-expiry"
   element in the PIDF-LO document that SHOULD be applied to all
   locations provided for this Target.

   The "retentionInterval" is an positive decimal value, which may



Winterbottom, et al.     Expires April 24, 2006                [Page 19]


Internet-Draft                    HELD                      October 2005


   include a decimal point, specifying a duration in seconds.  When a
   Location Server serves a request for location, the resulting PIDF-LO
   document will have a "retention-expiry" element set to the specified
   number of seconds after the issue of the location information.

   If no "retentionInterval" is specified the Location Server SHOULD
   provide a default value for the "retention-expiry" element in all
   PIDF-LO documents.  Nominally this default SHOULD be 24 hours from
   the receipt of the location request as specified in [I-D.ietf-
   geopriv-pidf-lo].  The Location Server MAY use a different value as
   circumstances dictate, but MUST NOT use a larger value than that
   requested; for example, where the access network supports mobility,
   this value can be reduced.

6.3.10.  responseTime

   A form parameter that is sent to the Location Server indicating how
   long a requester is prepared to wait for location information.

   The "responseTime" is a positive decimal value, which may include a
   decimal point, representing the time in seconds that a client is
   prepared to wait for a location response from the Location Server.
   It is RECOMMENDED that systems support millisecond precision for this
   parameter, that is, up to three decimal places.

   The Location Server should provide the most accurate location that it
   can within the response time requested.  The Location Server may use
   this parameter to aid it in making decisions about which location
   determination method it will invoke if more than one is supported.
   If this parameter is not provided then the Location Server may
   provide any default value, which may be arbitrarily large.  The value
   used in this parameter is indicative to the Location Server only, and
   the Location Server is under no obligation to strictly adhere to it,
   any strict enforcement of behaviour around this time is left to the
   requester.

6.3.11.  lero

   The Local Emergency Routing Option, or "lero", parameter requests
   that the Location Server provide the requester with routing
   information specific to their locality.  The LERO is represented as a
   set of URNs, that either contain routing information, or can be
   dereferenced to acquire this information.

   "lero" is a form parameter that MAY have a value of "true" or
   "false".  The default value of this parameter is "false".

   When present and set to "true", the Location Server MUST NOT provide



Winterbottom, et al.     Expires April 24, 2006                [Page 20]


Internet-Draft                    HELD                      October 2005


   a PIDF-LO document in the response.  Instead, the LERO is provided as
   a text document with a MIME type of "text/plain".

   A LERO document includes one or more URNs, each on a different line,
   that is, separated by CRLF.  For example, a LERO could include URNs
   such as: a contact URI for the local Public Safety Answering Point
   (PSAP), an Emergency Location Identification Number (ELIN), or any
   other local information applicable to the routing of an emergency
   call.

6.3.12.  signed

   A form parameter that may have a value of "true" or "false".  If not
   included the default value is "false".

   When the "signed" parameter is set to "true", the Location Server
   MUST provide a signed location object as defined in [I-D.thomson-
   domain-auth], or return an error.  If not present a value of "false"
   MUST be assumed.  Location information MUST NOT be signed unless
   explicitly requested.

6.3.13.  Identity Parameters

   When a Location Server requests location information from a Location
   Generator, it might need to provide some information that identifies
   the Target to the Location Generator.  Identity parameters SHOULD
   begin with the string "id-" to indicate the nature of the parameter
   and enable appropriate treatment.

   A Location Generator MUST NOT use identity parameters unless it has
   successfully authenticated the identity of an authorized Location
   Server.  Identity parameters are inputs that could affect the output
   of the location determination process performed by a Location
   Generator; if incorrect values are used, fraudulent location
   information could be acquired.

   Two identity parameters are described in this document, others MAY be
   defined by extension:

   id-ip: The IP address of the Target.  Either a dotted decimal IPv4
      address, or a valid IPv6 address [RFC2373].

   id-hwaddr: The hardware address of the Target as a sequence of
      hexadecimal digits.







Winterbottom, et al.     Expires April 24, 2006                [Page 21]


Internet-Draft                    HELD                      October 2005


6.3.14.  Extension parameters

   Parameter names that contain the period character (".") are defined
   as extension parameters.  Extensions SHOULD be given names of the
   form "parameter.company.com".  Using a domain name registered to the
   person or organization creating the extension parameter limits the
   opportunity for collisions in parameter definitions.

   Extension parameters that are not recognized SHOULD be ignored.  If a
   Location Server forwards a request to another Location Server, it
   SHOULD include all received extension parameters.








































Winterbottom, et al.     Expires April 24, 2006                [Page 22]


Internet-Draft                    HELD                      October 2005


7.  Location Information Response

   The location information response message contains either a
   "application/pidf+xml" body containing a valid PIDF-LO document or a
   "text/plain" body containing the LERO.  HTTP features SHOULD be used
   to provide additional information, including the "Content-Type",
   "Expires" and "Date" headers.

   The following HTTP status codes MAY be used to convey additional
   information about the request:

   200 OK: The Location Server MAY return this code if the request was
      processed successfully; the body of the response contains the
      requested data.

   400 Bad request: The Location Server MAY return this code if the
      request was badly formatted, or required parameters were
      incorrect, out of range or missing.  This code MAY be returned if
      any data type does not correctly parse, including any XML content.

   403 Forbidden: The Location Server MAY return this code if a Location
      Recipient does not meet the criteria specified in the
      authorization policy.  A Location Server SHOULD use the 404 code
      instead of 403 to prevent a Location Recipient from discovering
      that a location URI is in use.

   404 Not Found: The Location Server MAY return this code when the
      Location Server URI or location URI is not correct.  A Location
      Server MAY also use this return code when location information
      cannot be determined, or a session has expired.

   406 Not Acceptable: The Location Server MAY return this code where
      the client uses "Accept" header that does not allow for the
      content characteristics that the Location Server is capable of
      providing.  A request for location information MUST include an
      "Accept" header that includes "text/xml",
      "application/xml""application/pidf+xml", or "*".

   410 Gone: The Location Server MAY return this code if a request
      arrives to an expired location URI.

   501 Not Implemented: The Location Server MAY return this code if it
      does not support a requested function.  The body of the response
      should include some indication about the feature that is not
      implemented.






Winterbottom, et al.     Expires April 24, 2006                [Page 23]


Internet-Draft                    HELD                      October 2005


7.1.  Location Assertion

   Location assertion is most applicable where a Target can determine
   its own 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 Target to tell the Location Server where it
   thinks it is.

   If the Location Server decides not to use the location information
   provided by the Target then the Location Server MUST do one of two
   things depending on the value of the "exact" parameter:

   o  If "exact" parameter is set to "true" then the Location Server
      MUST return an error to the Target.

   o  If the "exact" parameter is set to "false", then the Location
      Server MUST return the location provided by the Location
      Generator.

7.2.  URI Generation and Identity Protection

7.2.1.  Location URI

   The location URI is an identifier generated by the Location Server so
   that the Target's location may be retrieved by-reference.  Location
   URIs are discussed in more detail in Section 11.2.2.

   The Location Server MUST be able to correlate a location URI with a
   Target context in order to provide location information, therefore a
   location URI MUST be globally unique.  The Location Server MUST also
   ensure that no private information is leaked in the location URI;
   that is, the location URI MUST NOT indicate either identity or
   location information in any way.  This implies that internal
   correlation is the only means available to match a location URI to a
   particular Target.

   To this end, it is RECOMMENDED that a location URI be, at a minimum,
   composed of a public address for the Location Server and a random
   sequence of characters that uniquely identifies a context within the
   Location Server.

7.2.2.  Presentity URI

   There is no requirement for the Location Server to know the identity
   of the user of a Target.  The unlinked pseudonym that is used for a
   presentity URI ensures that this identity can be protected.




Winterbottom, et al.     Expires April 24, 2006                [Page 24]


Internet-Draft                    HELD                      October 2005


   It is RECOMMENDED that Location Server be able to identify a Target
   context based on the presentity URI.  Therefore presentity URIs
   SHOULD be globally unique.  Where requests include a PIDF-LO
   document, the Location Server SHOULD use that presentity URI to limit
   the effectiveness of the attack described in Section 13.1.  A
   Location Server MAY append URI parameters to ensure that the URI is
   globally unique.

   A Location Server MUST generate a presentity URI when one is not
   provided.  A Location Server MAY also generate a presentity URI, even
   where one is provided.  Generating a presentity URI ensures that it
   is globally unique, however this might provide a Location Recipient
   no means of attributing location information to a particular Target,
   as described in Section 13.1.





































Winterbottom, et al.     Expires April 24, 2006                [Page 25]


Internet-Draft                    HELD                      October 2005


8.  Authentication

   Identification of clients to a Location Server may be achieved
   through any of the means available to HTTP/TLS implementations.
   Selection of authentication method is left to specific administrative
   domains.  The HTTP authentication methods described in [RFC2616] MAY
   be used, or any of the authentication methods available for TLS
   [RFC2246].  Authentication using X.509v3 certificates is RECOMMENDED.

   Regardless of the following recommendations, a Location Server MAY
   require any form of authentication from Targets as dictated by local
   policy.

8.1.  Location Server and Location Generator Authentication

   This document RECOMMENDS that Location Servers and Location
   Generators support X.509v3 certificate-based authentication for
   server authentication.  If a Location Server uses either another
   Location Server or a Location Generator, an X.509v3 certificate to
   provide client authentication.

8.2.  Target Authentication

   The Location Server identifies that a request comes from a Target by
   the incoming URI and the accompanying HELD parameters.  For these
   requests, the source IP address of the request message is used to
   determine the location of the device.  The response to this request
   is returned to the IP address where the request came from.

   A Location Server MAY require any reasonable form of authentication
   for Targets.  However, using return routability might prove
   sufficient protection against providing location information to the
   wrong entity.  Note that a Location Server provides location
   information to the device that currently uses the IP address.

   Using return routability can reduce the administrative effort
   required to manage device authentication, however care should be
   taken to reduce the impact of location theft.  Network administrators
   that rely on return routability should ensure that IP spoofing cannot
   be used to obtain a location URI for some other device.  Measures to
   mitigate this problem include:

   o  Limit the interval over which a location URI is valid, as
      suggested in Section 6.3.1.

   o  Ensure that requests to a Location Server can only originate from
      the served access network.




Winterbottom, et al.     Expires April 24, 2006                [Page 26]


Internet-Draft                    HELD                      October 2005


   o  Provide a means for the Location Server (perhaps through a
      Location Generator) to be notified of changes in network
      connectivity and address allocation.  This ensures that location
      information can be cancelled.

   o  Associate location information with other identifiers that can be
      independently verified, such as device hardware addresses.

   These measures are dependent on network deployments and should each
   be considered as appropriate, keeping in mind existing constraints on
   a network.  For instance, fixed access providers may be able to
   restrict the allocation of IP addresses to a single physical line,
   negating the need for any of these measures.

8.3.  Location Recipient Authentication

   Authentication of Location Recipients requesting the location of a
   Target through a location URI 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 X.509 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 Target.  If the
   Location Recipient request fails authentication then a "404 Not
   Found" status code SHOULD be returned.

8.4.  Authentication for Location Update

   A Location Server SHOULD should have one X.509v3 certificate that is
   used for all HELD-based communication.  That is, it SHOULD provide
   the same certificates to Targets regardless of if the request is from
   the Target, or to the location update URI provided by the Target.  If
   a Target provides a location update URI, it is RECOMMENDED that the
   Target retain the certificate provided by the Location Server to
   later authenticate the Location Server.
















Winterbottom, et al.     Expires April 24, 2006                [Page 27]


Internet-Draft                    HELD                      October 2005


9.  Persistent State at the Location Server

   When a client requests a location URI from a Location Server, the
   Location Server MUST maintain sufficient state information to be able
   to serve requests to the provided URI.  The term _context_ avoids
   confusion with the term _session_, which is often used in the HTTP
   concept with regards to a persistent relationship between a
   particular client and a server.

   When a location URI is requested, the Location Server MUST create a
   context that stores the following state information, where it is
   provided by the Target:

   o  Any PIDF-LO document format provided as a "pidf-lo" parameter.

   o  The authorization policy (the "rulesetURI" or "ruleset"
      parameters).

   o  The location update URI and associated response time.

   o  Any Target identification information necessary to be able to
      determine location information, or sufficient to provide to a
      Location Generator.

   The following diagram shows how a context is referenced by Targets
   and Location Recipients.

                +--------+
                | Target |
                +--------+
                    |
               (HTTP Cookie)
                    |
                    v
      .-----------------------------.
     |    Location Server Context    |
     | (PIDF-LO, Auth. Policy, ...)  |
     |                               |
     |  +-------------------------+  |
     |  |      Location URI       |  |
      `-+-------------------------+-'
            ^                 ^
            |                 |
      +-----------+     +-----------+
      | Location  | ... | Location  |
      | Recipient |     | Recipient |
      +-----------+     +-----------+




Winterbottom, et al.     Expires April 24, 2006                [Page 28]


Internet-Draft                    HELD                      October 2005


   Although they reference the same context through the location URI,
   Location Recipients MUST NOT be able to update the information stored
   in the context.  Note also that a location URI ensures that the
   location retrieved from the Location Server always contains the
   location of the Target.

9.1.  Initiating Contexts

   A Location Server MUST issue an HTTP cookie to a Target that requests
   a location URI so that the Target can update the information stored
   in the context.  Cookies are set using the "Set-Cookie2" header, as
   defined in [RFC2965].

   The Target updates stored information by providing a request that
   includes the updated information and the cookie information (using
   the "Cookie" header).  The Location Server MAY retain only latest
   provided value for any of these data.  Changes to authorization
   policy MUST be immediate; in particular, if a rulesetURI is provided
   the Location Server MUST assume that any cached rules are no longer
   valid.

   A Location Server MAY issue HTTP cookies to a Target for other
   requests.  Such a cookie can be used for correlating requests.
   However, if a Target receives a cookie the Location Server MUST store
   the listed state information.  A Target that makes a request from a
   Location Server using a cookie MAY assume that the Location Server
   has created a context that includes any query information that was
   previously provided.  A Target MAY therefore omit parameters that
   haven't changed in subsequent requests.

   A Location Server MAY also issue HTTP cookies to Location Recipients.
   Since Location Recipients do not initiate a context, they do not need
   to make any assumptions about the nature of stored data.

   A Location Server MUST NOT use an existing context for a request from
   a Target that does not contain an issued cookie.  This ensures that
   hosts that appear to originate from the same network address cannot
   affect each other.  This particularly applies where Network Address
   Translation (NAT) is employed.  To protect against denial of service
   type attacks, a Location Server SHOULD limit the number of contexts
   that it maintains for any one logical location.

9.2.  Terminating Contexts

   The Location Server SHOULD expire contexts based on the value of the
   "locationURI" parameter, see Section 6.3.1.  The expiration time of a
   context SHOULD be indicated through the "Max-Age" parameter of the
   "Set-Cookie" header.



Winterbottom, et al.     Expires April 24, 2006                [Page 29]


Internet-Draft                    HELD                      October 2005


   The Location Server MAY terminate a context at any time to react to
   changes in the access network.  For example, the Location Server
   could detect when the IP address allocated to the Target is
   reassigned to another device, or when the device is no longer
   attached to the network.  If a Target subsequently uses a cookie to
   attempt to refer to a context that has been removed in this fashion,
   the Location Server SHOULD treat the request as if the cookie were
   not present.

   Targets SHOULD be able to extend the expiry time of a context by
   requesting a location URI with a new duration, providing that the
   context has not already expired.

   When a request to terminate a context is received (see
   Section 6.3.1), the Location Server MUST remove any stored state
   information relating to identified context.  The Location Server MUST
   indicate this expiry by providing a response message that indicates
   that the context identifying cookie has expired.  A response message
   can indicate that cookie has expired by including a "Set-Cookie"
   header with the "Max-Age" parameter set to "0".































Winterbottom, et al.     Expires April 24, 2006                [Page 30]


Internet-Draft                    HELD                      October 2005


10.  Location Server Interactions

   Differences in network configurations can mean that location
   information cannot be provided by a single service that houses a
   Location Server and Location Generator function.  Typical scenarios
   include segmented networks operated by different organizations; a
   network "core" that is hidden from its users; and, networks employing
   network address translation (NAT).  To address these scenarios, it is
   often desirable to segment the Location Server and Location Generator
   functions in a fashion that suits the specific network.

   HELD supports this division of functions by providing a means for a
   Location Server to delegate specific responsibilities to another
   entity, using HELD.  Typical functions that may be delegated are:
   location determination (Location Generator), allocation of location
   URIs, and signing of location information.  If the Location Server is
   unable to serve a request it MAY forward a HELD request to an entity
   that is able to service that request.

10.1.  Delegating Location URI Allocation

   A Location Server MAY delegate the allocation of location URIs to
   another Location Server using the HELD protocol.  For instance, a
   Location Server that is behind a firewall may delegate the allocation
   of location URIs to another Location Server that is more accessible
   from the wider network.

   Location Servers that delegate the allocation of a location URIs MAY
   not need to maintain a context.  When location URIs are provided by
   another Location Server, the Location Server does not have to
   understand or enforce authorization policy rules.  A Location Server
   that provides a location URI MUST enforce the authorization policy
   rules specified by the Target.  Therefore, a Location Server that
   delegates the allocation of location URIs MUST forward any request
   that contains either the "rulesetURI" or "ruleset" parameters
   immediately.

   To delegate the allocation of location URIs a Location Server either
   publishes a PIDF-LO document, or provides a location update URI.  A
   location update URI SHOULD be used to enable the retrieval of current
   location information when requests are made to the location URI.  A
   location update URI MAY be omitted only when a location update URI
   cannot be provided.  If a location update URI is not provided the
   Location Server MUST provide location information in the request.
   For instance, the Location Server might be unreachable externally due
   to firewalls or Network Address Translation (NAT).





Winterbottom, et al.     Expires April 24, 2006                [Page 31]


Internet-Draft                    HELD                      October 2005


10.2.  Delegating Location Determination

   If the Location Generator function is not a part of the Location
   Server, the Location Server may forward a HELD request to an
   appropriate Location Generator to retrieve location information.

   For these instances, the Location Server includes the IP address of
   the Target, and any additional identification information it has
   available in a request message.  In this case, the Location Generator
   uses this IP address as an input to its location determination
   function, rather than the source IP address of the request message.

10.3.  Network Address Translation

   When session border controllers, for instance, NAT devices, are
   employed, a Location Server is unable to distinguish between
   individual hosts behind the NAT; all hosts appear as a single host -
   the NAT device.  This limits the ability of a Location Generator that
   is external to the translated network to determine locations for each
   individual host behind the NAT device.

   In some cases, particularly where only a small number of hosts exist
   in a small area, this limitation is not of great concern.  For
   example, many households employ a modem/router with NAT for internet
   access; the location of the residence is considered ample for a large
   range of applications.

   However, this limitation is unacceptable where the network on the
   other side of a NAT device covers a larger space or multiple sites.
   In the most extreme cases, intranets that span multiple continents
   employ a NAT, which means that an externally determined location
   could not possibly be accurate.

   It is RECOMMENDED that where sufficient area is covered, a Location
   Server be provided for the network behind the NAT device.  This
   Location Server MAY provide a limited service and use HELD to request
   other features from external Location Servers.














Winterbottom, et al.     Expires April 24, 2006                [Page 32]


Internet-Draft                    HELD                      October 2005


11.  Examples

   The following subsections represent a few examples of location
   requests and subsequent responses.

11.1.  Simple Location Request

   In this example a Target makes a request for any location from the
   Location Server.

   The Location Server determines the location and subsequently returns
   it to the Target, which may then communicate its location to other
   entities.


     +--------+         +-----------+        +-----------+
     | Target |         | Location  |        | Location  |
     |        |         |  Server   |        | Recipient |
     +----+---+         +-----+-----+        +-----+-----+
          |                   |                    |
          |   LocReq(ANY)     |                    |
          |------------------>|                    |
          |                   |                    |
          |               Determine                |
          |               Location                 |
          |                   |                    |
          |     Location      |                    |
          |<------------------|                    |
          |                   |                    |
          |                                        |
          |              Conveyance                |
          | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >|
          |                                        |



11.1.1.  Request for Any Location

   In this example the Target sends a GET to the Location Server URL.


   GET / HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*






Winterbottom, et al.     Expires April 24, 2006                [Page 33]


Internet-Draft                    HELD                      October 2005


   A positive response from the Location Server to the Target would look
   similar to:

   HTTP/1.x 200 OK
   Server: Example LIS
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 01:59:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Length: 648

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gml="http://www.opengis.net/gml"
     entity="pres:3650n87934c@lis.example.com">
     <tuple id="3b650sf789nd">
     <status>
      <gp:geopriv>
        <gp:location-info>
          <gml:position>
            <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
              <gml:pos>-34.407 150.88001</gml:pos>
            </gml:Point>
          </gml:position>
        </gp:location-info>
        <gp:usage-rules/>
      </gp:geopriv>
     </status>
     <timestamp>2005-07-13T01:59:45+00:00</timestamp>
     </tuple>
   </presence>

11.1.2.  Request for Civic Location

   In this example the Target specifically wants a civic location, so it
   posts a "locationType" of "civic" to the Location Server.


   POST / HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 18

   locationType=civic




Winterbottom, et al.     Expires April 24, 2006                [Page 34]


Internet-Draft                    HELD                      October 2005


   A civic location response from the Location Server follows:

   HTTP/1.x 200 OK
   Server: Example LIS
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 07:54:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Length: 1131

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
             entity="pres:Rvi46wB4fd345@lis.example.com">
     <tuple id="38mvwfq54">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <cl:civilAddress>
               <cl:country>AU</cl:country>
               <cl:A1>NSW</cl:A1>
               <cl:A3>Wollongong</cl:A3>
               <cl:A4>North Wollongong</cl:A4>
               <cl:A6>Northfields</cl:A6>
               <cl:STS>Avenue</cl:STS>
               <cl:LMK>University of Wollongong</cl:LMK>
               <cl:LOC>Building 3</cl:LOC>
             </cl:civilAddress>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
             <gp:retention-expiry>
               2005-07-13T07:54:47Z
             </gp:retention-expiry>
           </gp:usage-rules>
           <gp:method>DHCP</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-13T01:54:47Z</timestamp>
     </tuple>
   </presence>


11.2.  Location URI Request

   In these examples the Target requests a location URI from the
   Location Server.  Two examples show the way in which a Target may



Winterbottom, et al.     Expires April 24, 2006                [Page 35]


Internet-Draft                    HELD                      October 2005


   specify either a "rulesetURI" or a "ruleset" to control to whom the
   Location Server divulges their location information.  A third example
   shows how a Location Recipient can request the location of a Target
   using a location URI.


     +--------+         +-----------+        +-----------+
     | Target |         | Location  |        | Location  |
     |        |         |  Server   |        | Recipient |
     +----+---+         +-----+-----+        +-----+-----+
          |                   |                    |
          | LocReq(URI,rules) |                    |
          |------------------>|                    |
          |                   |                    |
          |               Generate                 |
          |              LocationURI               |
          |                   |                    |
          |     LocationURI   |                    |
          |<------------------|                    |
          |                   |                    |
          |                                        |
          |        Conveyance(locationURI)         |
          | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >|
          |                                        |
          |                   |    LocReq(ANY)     |
          |                   |<-------------------|
          |                   |                    |
          |              Authenticate              |
          |                   |                    |
          |               Determine                |
          |               Location                 |
          |                   |                    |
          |                   |     location       |
          |                   |------------------->|
          |                   |                    |


11.2.1.  Request Location URI Specifying rulesetURI

   In this example the Target specifies a "rulesetURI" when requesting a
   "locationURI".










Winterbottom, et al.     Expires April 24, 2006                [Page 36]


Internet-Draft                    HELD                      October 2005


   POST / HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 61

   locationURI=true&rulesetURI=https://10.2.3.4:9974/ruleset.xml











































Winterbottom, et al.     Expires April 24, 2006                [Page 37]


Internet-Draft                    HELD                      October 2005


   The Location Server responds with a PIDF-LO document, except that a
   location URI is included in the "Content-Location" header and a
   cookie is set to indicate that a session has been created.

   HTTP/1.x 200 OK
   Server: Example LIS
   Set-Cookie2: httplocationID="F168jiwdjw92jds09";
       Version="1"; Max-Age: 86400; Secure
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 07:54:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Location: https://lis.example.com/362b0e75du908n1
   Content-Length: 1131

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
             entity="pres:Rvi46wB4fd345@lis.example.com">
     <tuple id="38mvwfq54">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <cl:civilAddress>
               <cl:country>AU</cl:country>
               <cl:A1>NSW</cl:A1>
               <cl:A3>Wollongong</cl:A3>
               <cl:A4>North Wollongong</cl:A4>
               <cl:A6>Northfields</cl:A6>
               <cl:STS>Avenue</cl:STS>
               <cl:LMK>University of Wollongong</cl:LMK>
               <cl:LOC>Building 3</cl:LOC>
             </cl:civilAddress>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
             <gp:retention-expiry>
               2005-07-13T07:54:47Z
             </gp:retention-expiry>
           </gp:usage-rules>
           <gp:method>DHCP</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-13T01:54:47Z</timestamp>
     </tuple>
   </presence>




Winterbottom, et al.     Expires April 24, 2006                [Page 38]


Internet-Draft                    HELD                      October 2005


11.2.2.  Requesting locationURI Specifying ruleset

   In this example the Target provides an explicit "ruleset" in a
   request for a location URI.

   Note that the location request contains a cookie identifying the
   session created from a previous request.  [[NOTE: The authorization
   policy here is incorrect, however the common policy document is still
   undergoing changes.  This should be updated once that document
   becomes stable.]]

   POST / HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Cookie: $Version="1"; httplocationID="F168jiwdjw92jds09"
   Content-Type: multipart/form-data; boundary=-29733
   Content-Length: 472

   ---29733
   Content-Disposition: form-data; name="locationURI"

   true
   ---29733
   Content-Disposition: form-data; name="ruleset"
   Content-Type: application/auth-policy+xml

   <?xml version="1.0"?>
   <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
     <rule id="rul123">
       <conditions>
         <identity>
           <id>helpme@roadside.assistance.com</id>
         </identity>
       </conditions>
       <actions/>
       <transformations/>
     </rule>
   </ruleset>
   ---29733--


   The Location Server accepts the request and responds with a
   "locationURI".  Requests to this URI will result in the Location
   Server providing location information to the requester based on the
   rules in the provided ruleset.  Note that the PIDF-LO returned in
   this example is identical to the one shown in Section 11.2.1, so it
   is omitted.



Winterbottom, et al.     Expires April 24, 2006                [Page 39]


Internet-Draft                    HELD                      October 2005


   HTTP/1.x 200 OK
   Server: Example LIS
   Set-Cookie2: httplocationID="F168jiwdjw92jds09";
       Version="1"; Max-Age: 86400; Secure
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 07:54:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Location: https://lis.example.com/362b0e75du908n1
   Content-Length: 1131

   ... PIDF-LO contents omitted for brevity ...

11.2.3.  Location Recipient Using locationURI

   This example shows how a Location Recipient makes a request to a
   "locationURI", and the subsequent response.


   GET /362b0e75du908n1 HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*


   The example GET request shows how a Location Recipient can request
   arbitrary location information.  A POST to the "locationURI" with
   parameters is also allowed where specific location formats are
   required.






















Winterbottom, et al.     Expires April 24, 2006                [Page 40]


Internet-Draft                    HELD                      October 2005


   HTTP/1.x 200 OK
   Server: Example LIS
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 01:59:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Length: 692

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gml="http://www.opengis.net/gml"
             entity="pres:3650n87934c@lis.example.com">
     <tuple id="3b650sf789nd">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:position>
               <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
                 <gml:pos>-34.407 150.88001</gml:pos>
               </gml:Point>
             </gml:position>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-13T01:59:45+00:00</timestamp>
     </tuple>
   </presence>


11.3.  Location Assertion

   In the example the Target contains an on-board GPS so that the device
   can accurately determine where it is.  The Target asserts its
   location to the Location Server to obtain a valid PIDF-LO document.















Winterbottom, et al.     Expires April 24, 2006                [Page 41]


Internet-Draft                    HELD                      October 2005


     +--------+         +-----------+
     | Target |         | Location  |
     |        |         |  Server   |
     +----+---+         +-----+-----+
          |                   |
          | LocReq(Assert)    |
          |------------------>|
          |                   |
          |               Validate
          |               Location
          |                   |
          |      Location     |
          |<------------------|
          |                   |





































Winterbottom, et al.     Expires April 24, 2006                [Page 42]


Internet-Draft                    HELD                      October 2005


   POST / HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Content-Type: multipart/form-data; boundary=-29733
   Content-Length: 971

   ---29733
   Content-Disposition: form-data; name="locationType"

   geodetic
   ---29733
   Content-Disposition: form-data; name="pidf-lo"
   Content-Type: application/pidf+xml

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
       xmlns:gml="http://www.opengis.org/gml"
       entity="pres:user@example.com">
     <tuple id="38mvwfq54">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:position>
               <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
                 <gml:pos>-34.407 150.88001</gml:pos>
               </gml:Point>
             </gml:position>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
           </gp:usage-rules>
           <gp:method>GPS</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-13T01:54:32Z</timestamp>
     </tuple>
   </presence>

   ---29733--


   If the Location Server is able to validate the location information
   then a "200 OK" status is returned to the Target along with the
   PIDF-LO document providing the location.





Winterbottom, et al.     Expires April 24, 2006                [Page 43]


Internet-Draft                    HELD                      October 2005


   HTTP/1.x 200 OK
   Server: Example LIS
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 02:04:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Length: 1242

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gml="http://www.opengis.org/gml"
             entity="pres:vw46sny894G9@lis.example.com">
     <tuple id="38mvwfq54">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:position>
               <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
                 <gml:pos>-34.407 150.88001</gml:pos>
               </gml:Point>
             </gml:position>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
   <gp:retention-expiry>2005-07-13T02:04:32Z</gp:retention-expiry>
           </gp:usage-rules>
           <gp:method>GPS</gp:method>
   <gp:provided-by>
     <mydp:myProvidedBy
       xmlns:dp="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
       xmlns:mydp="http://www.example.org/schema/myDataProvider">
       <dp:DataProviderID>99999</dp:DataProviderID>
       <dp:TelURI>tel:555-99</dp:TelURI>
       <dp:URL>https://www.example.com/</dp:DataProviderID>
     </mydp:myProvidedBy>
   </gp:provided-by>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-13T01:54:32Z</timestamp>
     </tuple>
   </presence>


   Note that the "provided-by" element has also been populated.

   If the location assertion had failed in the above example then the
   Location Server would return the location that the Location Generator



Winterbottom, et al.     Expires April 24, 2006                [Page 44]


Internet-Draft                    HELD                      October 2005


   generated for the Target.  If the "exact" parameter was set to "true"
   then the request would fail.

11.4.  Requests Using Update and Location URIs

   In this example the Target requests a location URI from the Location
   Server that includes a "rulesetURI" and an "updateURI".  The Location
   Server assigns a location URI and returns it to the Target.


   +--------+               +-----------+     +-----------+
   | Target |               | Location  |     | Location  |
   |        |               |  Server   |     | Recipient |
   +----+---+               +-----+-----+     +-----+-----+
        |                         |                 |
        | LocReq(URI,upURI,rules) |                 |
        |------------------------>|                 |
        |                         |                 |
        |                     Generate              |
        |                    LocationURI            |
        |        LocationURI      |                 |
        |<------------------------|                 |
        |                         |                 |
        |           Conveyance(locationURI)         |
        | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~>|
        |                         |    LocReq(ANY)  |
        |                         |<----------------|
        |                         |                 |
        |                    Authenticate           |
        |          LocReq         |                 |
        |<------------------------|                 |
    Determine                     |                 |
    Location                      |                 |
        |        Location         |                 |
        |------------------------>|                 |
        |                     Validate              |
        |                     Location              |
        |                         |     Location    |
        |                         |---------------->|
        |                         |                 |

   The Target sends the location URI to the Location Recipient.  The
   Location Recipient uses the location URI to request a location from
   the Location Server.

   The Location Server uses the update URI to request location
   information from the Target.  The Target determines its own location
   and responds to the Location Server.



Winterbottom, et al.     Expires April 24, 2006                [Page 45]


Internet-Draft                    HELD                      October 2005


   The Location Server validates the provided location information and
   then returns a PIDF-LO document to the Location Recipient.


   POST / HTTP/1.1
   Host: lis.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 63

   locationURI=true&updateURI=https://10.2.3.4:9974/locationUpdate

   The Location-Server response and subsequent Location Recipient
   request are the same as shown in Section 11.2.2 and are not repeated
   here.  The Location Server request to the Target using the update URI
   is shown below.  The response from the Target is either a PIDF-LO
   document or an error.


   GET /locationUpdate HTTP/1.1
   Host: 10.2.3.4
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*


11.5.  Location Server to Location Generator

   This example demonstrates how a Location Server might delegate
   location determination to a Location Generator.

   +--------+            +------------+         +------------+
   | Target |            |  Location  |         |  Location  |
   |        |            |   Server   |         |  Generator |
   +----+---+            +-----+------+         +-----+------+
        |   Location Request   |                      |
        |--------------------->|                      |
        |                      |   Location Request   |
        |                      |--------------------->|
        |                      |                      |
        |                   Allocate              Determine
        |                 Location URI            Location
        |                      |                      |
        |                      | Location Information |
        |                      |<---------------------|
        | Location Information |                      |
        |<---------------------|                      |
        |                      |                      |



Winterbottom, et al.     Expires April 24, 2006                [Page 46]


Internet-Draft                    HELD                      October 2005


   From the perspective of the Target, the Location Server interaction
   is no different to that shown in previous examples.  That is, the
   fact that a Location Generator interaction is required is not visible
   to the Target.  Similarly the Location Recipient is also unaware of
   the existence of a separate Location Generator.

   For the purposes of this example, assume that the request and
   response messages are identical to those in Section 11.2.2.  However,
   the response is sourced from both the Location Server and Location
   Generator.

   The following request message is sent from the Location Server to the
   Location Generator.  The Location Server indicates the identity of
   the target using the "id-ip" parameter.  Note that the request does
   not need to include either of the "locationURI" or "ruleset"
   parameters.

   POST / HTTP/1.1
   Host: location-generator.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 14

   id-ip=10.2.3.4

   The response from the Location Generator includes a PIDF-LO document
   and the associated expiry information.

   HTTP/1.x 200 OK
   Server: Example Location Generator
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 07:54:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Length: 1131

   ... PIDF-LO contents omitted for brevity ...

11.6.  Location Server to Location Server

   This example demonstrates how a Location Server might delegate the
   allocation of location URIs to another Location Server.








Winterbottom, et al.     Expires April 24, 2006                [Page 47]


Internet-Draft                    HELD                      October 2005


   +--------+            +------------+         +------------+
   | Target |            |  Location  |         |  Location  |
   |        |            |  Server A  |         |  Server B  |
   +----+---+            +-----+------+         +-----+------+
        |                      |                      |
        |   Location Request   |                      |
        |--------------------->|                      |
        |                      |                      |
        |                  Determine                  |
        |                  Location                   |
        |                      |   Location Request   |
        |                      |--------------------->|
        |                      |                      |
        |                      |                   Allocate
        |                      |                 Location URI
        |                      |                      |
        |                      | Location Information |
        |                      |<---------------------|
        | Location Information |                      |
        |<---------------------|                      |
        |                      |                      |

   Similar to the example in Section 11.5, the interaction between the
   Target and the Location Server is identical to that in
   Section 11.2.2, except that the location URI indicates a different
   Location Server than the one that the Target directly interacts with.

























Winterbottom, et al.     Expires April 24, 2006                [Page 48]


Internet-Draft                    HELD                      October 2005


   The request message is identical to that in Section 11.2.2.  Upon
   receipt of this request, Location Server A determines the location of
   the Target and sends a request to Location Server B as follows:

   POST / HTTP/1.1
   Host: lis-b.example.com
   Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
   Accept-Charset: UTF-8,*
   Content-Type: multipart/form-data; boundary=-29733
   Content-Length: 1803

   ---29733
   Content-Disposition: form-data; name="locationURI"

   true
   ---29733
   Content-Disposition: form-data; name="updateURI"

   https://lis.example.com/F168jiwdjw92jds09
   ---29733
   Content-Disposition: form-data; name="ruleset"
   Content-Type: application/auth-policy+xml

   ... authorization policy document included here (omitted) ...
   ---29733
   Content-Disposition: form-data; name="pidf-lo"
   Content-Type: application/pidf+xml

   ... PIDF-LO document included here (omitted) ...
   ---29733--


   Note that this request message does not include identity parameters,
   instead it includes a location update URI.  Location Server B does
   not perform the role of Location Generator, therefore it does not
   need to receive any identity information.















Winterbottom, et al.     Expires April 24, 2006                [Page 49]


Internet-Draft                    HELD                      October 2005


   The response from Location Server B includes the same PIDF-LO body
   that was included in the request from Location Server A, but now
   includes a "Content-Location" header with a Location URI.

   HTTP/1.x 200 OK
   Server: Example LIS
   Set-Cookie2: locURInumber="vyIh39sS843sil3mr";
       Version="1"; Max-Age: 86400; Secure
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 07:54:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Location: https://lis-b.example.com/362b0e75du908n1
   Content-Length: 1131

   ... PIDF-LO document omitted for brevity ...

   Upon receipt of this response, Location Server A stores the cookie
   and issues another.  Location Server A now maintains state that
   correlates between cookie received from Location Server B and the one
   that it issues.  Location Server A also needs to maintain enough
   information to be able to service the location update URI that it
   issued.

   The response from Location Server A is shown below:

   HTTP/1.x 200 OK
   Server: Example LIS
   Set-Cookie2: httplocationID="F168jiwdjw92jds09";
       Version="1"; Max-Age: 86400; Secure
   Date: Wed, 13 Jul 2005 01:54:47 GMT
   Expires: Wed, 13 Jul 2005 07:54:47 GMT
   Cache-control: private
   Content-Type: application/pidf+xml
   Content-Location: https://lis-b.example.com/362b0e75du908n1
   Content-Length: 1131

   ... PIDF-LO document omitted for brevity ...













Winterbottom, et al.     Expires April 24, 2006                [Page 50]


Internet-Draft                    HELD                      October 2005


12.  Addresssing Using-Protocol Requirements

   The following list individually addresses the requirements from
   [RFC3693]:

   Req 1-3: These requirements are addressed by the formatting in
      [I-D.ietf-geopriv-pidf-lo], and subsequently [I-D.ietf-geopriv-
      pdif-lo-profile].

   Req 4: This protocol defines an out-of-band method for conveying
      rulesets to a Location Server, which controls privacy and security
      for the Location Object and associated rules.  A Location Server
      cannot distribute location information unless expressly given
      permission.  A Location Server cannot disseminate rulesets and may
      only provide rulesets that are explicitly provided for that
      purpose by a user.

   Req 5: Key establishment is acheived by using TLS [RFC2246].

   Req 6: This protocol does not add to the size of the Location Object,
      but is constrained by [I-D.ietf-geopriv-pidf-lo] in its encoding.
      HTTP [RFC2616] supports content compression, which may be employed
      to reduce the size of message contents.

   Req 7: This document makes it mandatory to follow provided rules and
      specifies that where rules are not provided the Location Server
      MUST prohibit access to data.

   Req 8: The interactions between a Location Generator and other
      entities are not defined by this document.

   Req 9: This document specifies that Rules, or authorization policy
      documents, are stored separately to the Location Object and that a
      Viewer does not receive these rules.  A Rule Maker may specify a
      set of rules that are visible to a Viewer by including this
      information in a template PIDF-LO document.

   Req 10: This requirement is addressed by [I-D.ietf-geopriv-common-
      policy] and [I-D.ietf-geopriv-policy].

   Req 11: This requirement is addressed by [I-D.ietf-geopriv-pidf-lo].

   Req 12: Section 7.2 includes rules that ensure that a location URI
      does not include information that reveals any information about
      the Target.  In addition to this, this section also specifies that
      the presentity URI provided in Location Objects be an Unlinked
      Pseodonym, which offers the protections described in [RFC3694].




Winterbottom, et al.     Expires April 24, 2006                [Page 51]


Internet-Draft                    HELD                      October 2005


   Req 13: This document recommends that the authentication schemes
      adopted in [I-D.ietf-geopriv-common-policy] are used.

   Req 14:

      Req 14.1: TLS provides a number of schemes that enable mutual end-
         point authentication.  Section 8.1 addresses this requirement
         in more detail.

      Req 14.2: TLS provides protection against in-transit modification
         of information.

      Req 14.3: TLS provides data confidentiality.

      Req 14.4: TLS provides protection against replay attacks.

   Req 15:

      Req 15.1: This document makes TLS a MUST implement component of
         the defined protocol stack.  Other aspects, including the
         provision of a digital signature on location information are
         outside the scope of this document; for instance, [I-D.thomson-
         domain-auth] defines a digital signature scheme.

      Req 15.2: No further security measures are identified as
         mandatory.

      Req 15.3: The Location Server does not have any means of ensuring
         that any request is as a result of an emergency call.  However,
         see Section 8.2 for details on how Target authentication MAY be
         avoided.

   Where HELD is used between a Location Server and Location Generator,
   TLS can provide identity assurance, data confidentiality, in-transit
   modification and replay protection.  This protection is sufficient to
   ensure that only the Location Server and Generator have access to the
   location information.














Winterbottom, et al.     Expires April 24, 2006                [Page 52]


Internet-Draft                    HELD                      October 2005


13.  Security Considerations

   All requests for location and subsequent location responses MUST be
   done using secure HTTP (https).  Target authentication MAY be avoided
   in preference for return routability, see Section 8.2.  The Location
   Server MUST be authenticated; using the method described in [RFC2818]
   is RECOMMENDED.

   Exactly how validation and authentication of Location Recipients
   using client-side certificates or SAML assertions is implemented is
   beyond the scope of this document but consideration should be given
   to employing best current practices.

   State information associated with a context at the Location Server
   MUST be purged when the context expires.

   Identity parameters, such as Target IP address, MUST NOT be accepted
   by a Location Server, see Section 6.3.13 for details.  A Location
   Generator MUST only accept identity parameters from an authenticated,
   authorized Location Server.

13.1.  Identity Assurance and Location Fraud

   Unlinked pseudonyms are favoured by the GEOPRIV architecture so that
   users can provide location information without necessarily revealing
   identity information at the same time.  However, this characteristic
   of unlinked pseudonyms can make it difficult to associate PIDF-LO
   documents with a particular Target.  This applies with all PIDF-LO
   documents.

   Even if a PIDF-LO document is provided directly from a Location
   Server that the Location Recipient can rely on to provide accurate
   information, there may be no way to associate the presentity URI with
   a particular Target.  This effect is somewhat less applicable when
   providing location information directly from Target to Location
   Recipient, since the link between Target and location information is
   made implicitly.  When receiving location information directly, the
   Location Recipient needs to only trust the Target's assurances, which
   may be backed by a digital signature.

   For a location URI, if an attacker were able to obtain a location URI
   that belongs to another entity, that attacker could use that location
   URI as if it were their own.  Location Recipients that receive this
   location URI might not be able to determine the true owner of the
   location information.  If the original owner allowed access to the
   Location Recipient, then the Location Recipient might be granted
   location information with no indication of the actual identity
   associated with the location information.  This enables an attacker



Winterbottom, et al.     Expires April 24, 2006                [Page 53]


Internet-Draft                    HELD                      October 2005


   to provide fradulent location information.

   To protect against location fraud in this fashion two methods are
   applicable: protecting the location URI from theft, and providing a
   link between a presentity URI and some other information that a
   Location Recipient can use to associate with a Target.  Note that to
   provide this link, the Location Recipient need only be assured that
   the location information does not belong to someone else, it does not
   necessarily need to obtain identity information.

   Recommendations that reduce the potential for location URI theft are
   described in Section 8.2.  In addition to these, a Target MUST NOT
   convey a location URI on an unsecure communication channel.

   To provide a link between Target and location information, it is
   RECOMMENDED that a Target be able to provide a presentity URI to the
   Location Server.  The Location Recipient can use the presentity URI
   to link location information with some known information.  This
   approach limits the potential for location fraud.  Note that the
   presentity URI remains an unlinked pseudonym that protects a users
   identity information, a user may still limit the amount of
   information that is revealed to the Location Recipient.

   If a presentity URI is provided by the Target, anonymity might not be
   possible depending on whether the Location Recipient is able to link
   the provided presentity URI to other identify information.  A Rule
   Maker needs to be aware of this factor when creating authorization
   policies.

   If a Location Server generates a presentity URI, a layer of identity
   protection can be added.  However, this limits the ability of a
   Location Recipient to associate location information with the
   Target's identity.


















Winterbottom, et al.     Expires April 24, 2006                [Page 54]


Internet-Draft                    HELD                      October 2005


14.  IANA Considerations

14.1.  DHCP Option Code Registration

   IANA has assigned a DHCPv4 option code of TBD for the Location Server
   URI (LOCSERV_URI) option defined in this document.

   IANA has assigned a DHCPv6 option code of TBD for the Location Server
   URI (OPTION_LOCSERV_URI) option defined in this document.

14.2.  SLP Service Template Registration

   [NOTE: This template has not been sent to svrloc-list@iana.org for
   submission.]


   Name of submitter: "Martin Thomson" <martin.thomson@andrew.com>
   Language of service template: en
   Security Considerations:
     A service that implements this protocol needs to conform with the
     requirements of a GEOPRIV using protocol, as defined in RFC 3693.
     Connection security and authentication are described in RFC XXXX.

   Template Text:
   -------------------------template begins here-----------------------
   template-type=service:locserv

   template-version=0.0

   template-description=
     A location service provides network devices with their location
     and enables the dissemination of that location information to
     selected hosts.

   template-url-syntax=
     url-path = absoluteURI ; as defined in RFC 3986
   ; For example:
   ;    service:locserv:https://lis.example.com:54462/locserv

   locserv-domain = STRING O M L
   # The name of the domain or domains served.

   locserv-target-auth = STRING O M L
   none
   # Specifies what authentication options are required by the server
   # for targets that request their own location:
   #  - none - return routability is considered adequate
   #  - basic - HTTP basic authentication RFC 2617 (not recommended)



Winterbottom, et al.     Expires April 24, 2006                [Page 55]


Internet-Draft                    HELD                      October 2005


   #  - digest - HTTP digest authentication RFC 2617/3310
   #  - x509 - an X.509 certificate attached to the TLS session
   # Multiple values indicate a choice.
   none,basic,digest,x509

   locserv-recipient-auth = STRING O M L
   x509
   # The authentication that is required for location recipients.
   # The same as locserv-target-auth, except with X.509 as default.
   none,basic,digest,x509

   locserv-response-times = INTEGER O M L
   # A set of response times (in milliseconds) that location
   # generators available to the location service are capable of.
   # These values provide a hint to a SLP UA only.
   #  - A value of 0 indicates that the service caches location.
   #  - A negative value indicates the timeliness of a location
   #    generator is unknown.

   locserv-pidf-lo-accepted = STRING O L
   no
   # Indicates if the location service accepts user-provided PIDF-LO
   # documents.
   #  - no indicates that the pidf-lo parameter is ignored.
   #  - template-only indicates that only the template is used.
   #  - loc-only indicates that only the location information is used.
   #  - yes indicates that the pidf-lo parameters is fully supported.
   no,template-only,loc-only,yes

   locserv-locuri-supported = BOOLEAN O L
   # Indicates if the location service can provide a location URI.

   locserv-update-supported = BOOLEAN O L
   # Indicates if the location service can query for updates.

   locserv-ruleset-supported = BOOLEAN O L
   # Indicates if the location service applies user-provided
   # authorization policies.

   locserv-dsig-supported = BOOLEAN O L
   # Indicates if the location service supports the application of
   # digital signatures to provided location information.

   locserv-lero-supported = BOOLEAN O L
   # Indicates if the location service can provide Local
   # Emergency Routing Option information





Winterbottom, et al.     Expires April 24, 2006                [Page 56]


Internet-Draft                    HELD                      October 2005


15.  Acknowledgements

   The authors wish to thank Hannes Tschofenig and John Schnizlein for
   their early comments and guidance.















































Winterbottom, et al.     Expires April 24, 2006                [Page 57]


Internet-Draft                    HELD                      October 2005


16.  References

16.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.

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

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 2000.

   [RFC2388]  Masinter, L., "Returning Values from Forms:  multipart/
              form-data", RFC 2388, August 1998.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

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

   [I-D.ietf-geopriv-common-policy]
              Schulzrinne, H., "A Document Format for Expressing Privacy
              Preferences", draft-ietf-geopriv-common-policy-05 (work in
              progress), July 2005.

   [I-D.ietf-geopriv-policy]
              Schulzrinne, H., "A Document Format for Expressing Privacy
              Preferences for Location  Information",
              draft-ietf-geopriv-policy-06 (work in progress),
              July 2005.



Winterbottom, et al.     Expires April 24, 2006                [Page 58]


Internet-Draft                    HELD                      October 2005


   [I-D.thomson-domain-auth]
              Thomson, M. and J. Winterbottom, "Domain Authorization for
              PIDF-LO", draft-thomson-domain-auth-01 (work in progress),
              June 2005.

   [I-D.winterbottom-location-uri]
              Winterbottom, J., "Rationale for Location by Reference",
              draft-winterbottom-location-uri-00 (work in progress),
              July 2005.

   [W3C.REC-xmlschema-2-20041028]
              Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004.

16.2.  Informative references

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

   [RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
              "Threat Analysis of the Geopriv Protocol", RFC 3694,
              February 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-07 (work in progress),
              September 2005.

   [I-D.ietf-geopriv-pdif-lo-profile]
              Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
              Considerations and Recommendations",
              draft-ietf-geopriv-pdif-lo-profile-01 (work in progress),
              July 2005.

   [I-D.thomson-revised-civic-lo]
              Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for PIDF-LO", draft-thomson-revised-civic-lo-01
              (work in progress), October 2005.

   [GML3]     Cox, S., Lake, R., Portele, C., and A. Whiteside,
              "Geographic information - Geography Markup Language



Winterbottom, et al.     Expires April 24, 2006                [Page 59]


Internet-Draft                    HELD                      October 2005


              (GML)", OpenGIS d02-023r4, January 2003.


















































Winterbottom, et al.     Expires April 24, 2006                [Page 60]


Internet-Draft                    HELD                      October 2005


Authors' Addresses

   James Winterbottom
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Email: james.winterbottom@andrew.com


   Martin Dawson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Email: martin.dawson@andrew.com


   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Email: martin.thomson@andrew.com


   Barbara Stark
   BellSouth
   Room 7A41
   725 W Peachtree St.
   Atlanta, GA  30308
   US

   Email: barbara.stark@bellsouth.com














Winterbottom, et al.     Expires April 24, 2006                [Page 61]


Internet-Draft                    HELD                      October 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 April 24, 2006                [Page 62]


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