GEOPRIV M. Thomson
Internet-Draft Andrew Corporation
Intended status: Standards Track F. Ribeiro
Expires: September 8, 2011
R. Barnes
BBN Technologies
March 7, 2011
HTTP Geolocation
draft-thomson-geopriv-http-geolocation-00
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 8, 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
Thomson, et al. Expires September 8, 2011 [Page 1]
Internet-Draft HTTP Geolocation March 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Geolocation Header . . . . . . . . . . . . . . . . . . . . . . 3
4. 427 (Bad Geolocation) Status Code . . . . . . . . . . . . . . . 4
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Geolocation Header Registration . . . . . . . . . . . . . . 7
8.2. 427 (Bad Geolocation) Status Code Registration . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Thomson, et al. Expires September 8, 2011 [Page 2]
Internet-Draft HTTP Geolocation March 2011
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.
Thomson, et al. Expires September 8, 2011 [Page 3]
Internet-Draft HTTP Geolocation March 2011
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:
o include a Geolocation header (after gaining permission), if one
was absent
o include a location value directly, if a location reference was
provided
o include a different URI type, if alternatives are available
o modify any authorization rules on the identified resource to
permit the server access
A representation included in the response SHOULD provide what
Thomson, et al. Expires September 8, 2011 [Page 4]
Internet-Draft HTTP Geolocation March 2011
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>
Thomson, et al. Expires September 8, 2011 [Page 5]
Internet-Draft HTTP Geolocation March 2011
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.
Thomson, et al. Expires September 8, 2011 [Page 6]
Internet-Draft HTTP Geolocation March 2011
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
Thomson, et al. Expires September 8, 2011 [Page 7]
Internet-Draft HTTP Geolocation March 2011
9.1. Normative References
[I-D.ietf-httpbis-p1-messaging]
Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
"HTTP/1.1, part 1: URIs, Connections, and Message
Parsing", draft-ietf-httpbis-p1-messaging-12 (work in
progress), October 2010.
[I-D.ietf-httpbis-p2-semantics]
Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
"HTTP/1.1, part 2: Message Semantics",
draft-ietf-httpbis-p2-semantics-12 (work in progress),
October 2010.
[I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-06 (work in
progress), February 2011.
[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.
Thomson, et al. Expires September 8, 2011 [Page 8]
Internet-Draft HTTP Geolocation March 2011
9.2. Informative References
[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",
draft-ietf-geopriv-arch-03 (work in progress),
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", draft-ietf-geopriv-deref-protocol-02
(work in progress), December 2010.
[I-D.ietf-geopriv-loc-filters]
Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
Location Notifications in the Session Initiation Protocol
(SIP)", draft-ietf-geopriv-loc-filters-11 (work in
progress), March 2010.
[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.
Authors' Addresses
Martin Thomson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
Fernando Ribeiro
BR
Email: webmaster@fernandoribeiro.eti.br
Thomson, et al. Expires September 8, 2011 [Page 9]
Internet-Draft HTTP Geolocation March 2011
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
Thomson, et al. Expires September 8, 2011 [Page 10]