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: Content-ID: Content-Length: TBD Content-Type: application/pidf+xml 42.5463 -73.2512 850.24 OTDOA In the following example, location is included by reference to an HTTP resource. GET /resource HTTP/1.1 Host: example.com:8443 Geolocation: 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 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]