GEOPRIV M. Thomson
Internet-Draft Andrew Corporation
Intended status: Standards Track F. Ribeiro
Expires: September 08, 2011 R. Barnes
BBN Technologies
March 07, 2011

HTTP Geolocation


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

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

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

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
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"
  <tuple id="circle">
          <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">

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

GET /resource HTTP/1.1
Geolocation: <>

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

HTTP/1.1 427 Bad Geolocation
Content-Type: text/plain;charset=utf-8
Content-Length: 95

<> 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:
Applicable protocol:
Author/change controller:
Internet Engineering Task Force, IETF (
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:
Bad Geolocation
RFCXXXX (this document)

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3864] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-sipcore-location-conveyance] Polk, J, Rosen, B and J Peterson, "Location Conveyance for the Session Initiation Protocol", Internet-Draft draft-ietf-sipcore-location-conveyance-09, September 2011.
[I-D.ietf-httpbis-p1-messaging] Fielding, R, Gettys, J, Mogul, J, Nielsen, H, Masinter, L, Leach, P, Berners-Lee, T, Lafon, Y and J Reschke, "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Internet-Draft draft-ietf-httpbis-p1-messaging-17, October 2011.
[I-D.ietf-httpbis-p2-semantics] Fielding, R, Gettys, J, Mogul, J, Nielsen, H, Masinter, L, Leach, P, Berners-Lee, T, Lafon, Y and J Reschke, "HTTP/1.1, part 2: Message Semantics", Internet-Draft draft-ietf-httpbis-p2-semantics-17, October 2011.

9.2. Informative References

[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010.
[I-D.ietf-geopriv-arch] Barnes, R, Lepinski, M, Cooper, A, Morris, J, Tschofenig, H and H Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", Internet-Draft draft-ietf-geopriv-arch-03, October 2010.
[I-D.ietf-geopriv-deref-protocol] Winterbottom, J, Tschofenig, H, Schulzrinne, H, Thomson, M and M Dawson, "A Location Dereferencing Protocol Using HELD", Internet-Draft draft-ietf-geopriv-deref-protocol-04, October 2011.
[I-D.ietf-geopriv-loc-filters] Mahy, R, Rosen, B and H Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol (SIP)", Internet-Draft draft-ietf-geopriv-loc-filters-11, March 2010.

Authors' Addresses

Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU Phone: +61 2 4221 2915 EMail:
Fernando Ribeiro BR EMail:
Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD, 21046 USA Phone: +1 410 290 6169 EMail: