HTTP Geolocation

Abstract

A Geolocation header is defined for HTTP. The Geolocation header provides a reference to location information in an HTTP request. A server can use this information in processing the request.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on September 08, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Geolocation Header
• 4. 427 (Bad Geolocation) Status Code
• 5. Examples
• 6. Privacy Considerations
• 7. Security Considerations
• 8. IANA Considerations
• 8.1. Geolocation Header Registration
• 8.2. 427 (Bad Geolocation) Status Code Registration
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

This document describes a header for Hypertext Transfer Protocol (HTTP) [RFC2616] that includes a reference location information.

The Geolocation request header includes a URI to a resource that includes location information. A server can choose to use this information in serving the request. How this affects the response is up to the server, but this could be used to select content that is more appropriate for a recipient at the given location.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.

Some terminology from [I-D.ietf-geopriv-arch] is used.

3. Geolocation Header

The Geolocation header is a end-to-end request header that includes a reference to location information. This reference is an absolute URI [RFC3986] that identifies a resource that contains location information.

The following ABNF [RFC5234] defines the syntax of the Geolocation header. This ABNF uses the modified syntax and existing rules for HTTP from [I-D.ietf-httpbis-p1-messaging].

Geolocation-Header = "Geolocation:" OWS "<" absolute-URI ">"
                     *geoloc-param
geoloc-param       =  OWS ";" OWS token [ "=" word ]
        

The value of location information can be carried in the body of a request using a cid: URI [RFC2392]. The geo: URI [RFC5870]provides another means of including location information directly.

Location information that is included by reference to an independent resource means that the server has some control over how location information is acquired. Depending on the needs of the server, it may need to follow this reference before responding to the request.

A location that is provided by reference to a constantly updating resource could permit a server to request information that better suits their end by a variety of methods. Content negotiation, HTTP-Enabled Location Delivery [I-D.ietf-geopriv-deref-protocol] and location filtering [I-D.ietf-geopriv-loc-filters] could be used, depending on the type and capabilities of the identified resource. Providing location by reference allows a server to request location information some time after receiving the request, enabling applications that operate outside the time of the client-server interaction. This has potential privacy implications, see Section 6.

Servers that implement support for the Geolocation header MUST support cid:, https: and http: URIs. Servers MUST support location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) [RFC4119].

A client SHOULD NOT include multiple Geolocation headers in the same request. Though it is permitted, a server that doesn't have additional information about each URI might find it difficult to select a single location or reconcile different locations. [I-D.ietf-sipcore-location-conveyance] provides a discussion on the consequences of including multiple location values.

Resources that provide different representations based on the value of the Geolocation header typically need a Vary header containing Geolocation if they can be cached.

4. 427 (Bad Geolocation) Status Code

A status code of 427 indicates that the request contained missing, badly formed, unsupported or inaccessible location information.

This indicates that a request might be successful if it contained different location information. The client might:

• include a Geolocation header (after gaining permission), if one was absent
• include a location value directly, if a location reference was provided
• include a different URI type, if alternatives are available
• modify any authorization rules on the identified resource to permit the server access

A representation included in the response SHOULD provide what guidance the server can provide the client in providing a request that will succeed.

5. Examples

In the following example, location is included by value. The Geolocation header references a PIDF-LO document in the body of the request.

GET /resource HTTP/1.1
Host: example.com:8443
Geolocation: <cid:rf*c36n89@r.213562>
Content-ID: <rf*c36n89@r.213562>
Content-Length: TBD
Content-Type: application/pidf+xml

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:gs="http://www.opengis.net/pidflo/1.0"
          entity="pres:circle@example.com">
  <tuple id="circle">
    <status>
      <gp:geopriv>
        <gp:location-info>
          <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
            <gml:pos>42.5463 -73.2512</gml:pos>
            <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
              850.24
            </gs:radius>
          </gs:Circle>
        </gp:location-info>
        <gp:usage-rules/>
        <gp:method>OTDOA</gp:method>
      </gp:geopriv>
    </status>
  </tuple>
</presence>

In the following example, location is included by reference to an HTTP resource.

GET /resource HTTP/1.1
Host: example.com:8443
Geolocation: <https://lis.example.net/location/scey89pse>

In the following example, an error response indicates that the Geolocation was not accessible by the server.

HTTP/1.1 427 Bad Geolocation
Host: example.com:8443
Content-Type: text/plain;charset=utf-8
Content-Length: 95

<https://lis.example.net/location/scey89pse> was not accessible.
HTTP Error: 403 Forbidden

6. Privacy Considerations

Location information is highly privacy-sensitive. A discussion of the privacy considerations as they relate to location information in general, and a terminology framework can be found in [I-D.ietf-geopriv-arch]. Most importantly, a client MUST NOT send location information without the permission of a Rule Maker.

[I-D.ietf-geopriv-arch] defines rules for the server that are included in the Location Object [RFC4119]. A conforming server MUST respect the rules regarding location retention and retransmission in PIDF-LO.

Confidentiality protection, as provided by HTTP over TLS [RFC2818] MUST be used to protect location information, unless other forms of protection are provided, or a Rule Maker has provided permission for information to be universally distributed. This applies whether the request contains location information by value or by reference; the guidance in [RFC5808] recommends confidentiality protection for some URIs that reference location.

Location information that is included by reference to a resource allows the server to retrieve location information outside of the context of the request. An access control policy on the referenced resource may be used to control access.

The privacy considerations for this document are similar to those for SIP location conveyance [I-D.ietf-sipcore-location-conveyance], with one major exclusion. The intermediary architecture for HTTP doesn't support routing in the same way that SIP does and routing based on location information is not possible in the same manner. For this reason, the privacy concerns relating to routing and the related Routing-Allowed header are not relevant to HTTP.

7. Security Considerations

In addition to the privacy considerations, HTTP over TLS [RFC2818] provides integrity protection for location information on a hop-by-hop basis.

Servers that support Geolocation headers need to be aware of the potential attacks that accepting URIs provided by clients could enable. The security considerations of [RFC3986] contains guidance on using URIs.

8. IANA Considerations

[[Note to IANA/RFC Editor: Please replace instances of RFCXXXX with the number of the published RFC and remove this note.]]

8.1. Geolocation Header Registration

This section registers the Geolocation HTTP header in the "Permanent Message Header Fields" registry established by [RFC3864].

Header field:

Geolocation

Applicable protocol:

HTTP

Status:

standard

Author/change controller:

Internet Engineering Task Force, IETF (iesg@ietf.org)

Specification document(s):

RFCXXXX (this document)

8.2. 427 (Bad Geolocation) Status Code Registration

This section registers the Bad Geolocation HTTP status code in the "Hypertext Transfer Protocol (HTTP) Status Code Registry" registry established by [I-D.ietf-httpbis-p2-semantics].

Status Code Value:

427

Description:

Bad Geolocation

Reference:

RFCXXXX (this document)

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses