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 -34.407 150.88001 2005-07-13T01:59:45+00:00 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 AU NSW Wollongong North Wollongong Northfields Avenue University of Wollongong Building 3 no 2005-07-13T07:54:47Z DHCP 2005-07-13T01:54:47Z 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 AU NSW Wollongong North Wollongong Northfields Avenue University of Wollongong Building 3 no 2005-07-13T07:54:47Z DHCP 2005-07-13T01:54:47Z 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 helpme@roadside.assistance.com ---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 -34.407 150.88001 2005-07-13T01:59:45+00:00 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 -34.407 150.88001 no GPS 2005-07-13T01:54:32Z ---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 -34.407 150.88001 no 2005-07-13T02:04:32Z GPS 99999 tel:555-99 https://www.example.com/ 2005-07-13T01:54:32Z 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" 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]