[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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


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

   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

   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

   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

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

   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

   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

              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.

              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.

              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

              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.

              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.

              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

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com

   Fernando Ribeiro

   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

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com

Thomson, et al.         Expires September 8, 2011              [Page 10]