INTERNET-DRAFT Vancouver Webpages Apr 2001 (Expires Oct 2001) Geographic extensions for HTTP transactions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo describes a method of adding simple geographic position information to HTTP transactions using extension headers. In the case of an HTTP request, the extensions indicate a geographic position or region that the requesting agent is interested in. This information may be used by a server to present appropriate position- dependent responses, such as search engine results, without the additional overhead of geographic query requests and possibly graphical input. In the case of an HTTP response, the extensions indicate a geographic position or region relevant to the resource described in the body of the response. This information may be used for automated resource discovery. 1. Introduction Many resources described by HTML documents on the World-Wide-Web are associated with a particular place on the Earth's surface. While resource discovery on the Web has thus far focussed on document title A.Daviel [Page 1] Apr 2001 (Expires Oct 2001) and open-text keyword searching, in these cases it may be beneficial to facilitate geographic searching. Examples of this kind of resource include pages describing restaurants, shipwrecks, retail stores etc. By including geographic extension headers in HTTP requests and responses, it is possible to tailor responses to the location of the requestor, in the same way that the language of the response may be tailored by using the Accept-Language header ([1]). The use of geographic extension headers may make it more practical to use a small text-based client or embedded device to perform location- based queries. It facilitates the automatic inclusion of current position in queries by defining a standard interface. While position data may be sent in the body of HTTP requests, typically each server- based application will use a different format. 2. Example Usage An example of a commonly used resource on the World-Wide-Web is a weather map. This service is provided by many different organizations which cover different regions. In some cases it is possible to select the map for a particular area by choosing a corresponding URL, and it may be possible to customize the response by accepting a cookie [6] from a particular server. If the user moves to another location, and wishes to locate a map for that area instead, there is currently no transparent way to generate the appropriate URL. If the service is provided from a different Internet domain, the cookie mechanism cannot be used to register user preferences. If geographic extension headers are used, they may be used to transparently indicate the user's preference for a particular geographic area. A portable computer might be fitted with a navigation system such as GPS [4] which provides positional information, and this could be used to automatically generate appropriate extension header values which would retrieve weather maps for the user's current position, or other information such as locations of hotels, repair facilities etc. 2. Coordinate Systems Resource positions on the Earth's surface should be expressed in degrees North of Latitude, degrees East of Longitude as signed decimal numbers. Elevation should be expressed as a signed decimal number of metres above datum. The number of decimal places given should reflect the precision of the coordinates, with zeroes being used as placeholders. A decimal point is optional where the precision is less than one degree. Where the precision of the coordinates is such that the datum used is significant, typically more precise than one kilometre distance, positions should be A.Daviel [Page 2] Apr 2001 (Expires Oct 2001) converted to the WGS 84 datum [3]. Positions given by a GPS set [4] with datum set to "WGS 84" will in most cases be adequate, of the order of 15 metres accuracy. 3. Implementation Geographic information is included as "extension-headers" in HTTP requests and responses (the HTTP Hypertext Transfer Protocol [1][2]). The identifier "geo.position" is used for Latitude, Longitude and optionally Elevation values. These should be ordered (Latitude Longitude [Elevation]) separated by semicolons (";"), similar to the vCard GEO element [8]. The identifier "geo.region" is taken from the reserved list, ISO 3166-2 [7]. The identifier "Accept-Geo" is used by an agent or server to indicate a willingness to accept geo headers in HTTP transactions. Geo headers may be sent either by a server or by a client. It is anticipated that in most applications the headers will be included in a client request. 3.1 Negotiation Use of negotiation is recommended. If negotiation is not used, a client may be configured to return geo headers for all HTTP requests, or only in requests to certain servers. Negotiation is used to establish a trust relationship between the client and server, that is to say between the person initiating the request and the organization providing the requested information. The user agent may maintain a list of trusted sites to which position data is sent, with optional accuracy information. The user may wish to send precise data to one site, approximate position data to others, and none to those not listed. It is recommended that specific provision be made to control position data sent in response to an HTML email message. If the user requests a geo-enabled document from a server, the server responds with an Accept-Geo. header. If the server is not in the list of trusted sites, the user agent should open a dialog with the user to ask them whether position data should be sent. The agent may ask, for instance, whether position data should be sent once, always, or never. it may also ask to what precision the data should be given, A.Daviel [Page 3] Apr 2001 (Expires Oct 2001) for instance to the nearest 10km, 1km or 10m. The user agent may also provide a means to require certain security features, for instance that the server is using a valid SSL certificate from a trusted CA, or a certain level of encryption. The agent configuration may allow default settings, such as sending approximate position data to any unlisted site, or sending position data only to trusted sites using SSL. 4. Examples geo.position: 48.54;-123.84;120 describes a resource 120 metres above datum at position 48.54 degrees North, 123.84 degrees West, while geo.position: -10;60 describes a resource at position 10 degrees South, 60 degrees East. geo.region: CA-ON describes a resource in Ontario, Canada while geo.region: GB describes a resource in England (Great Britain). Accept-Geo: position,region is sent by a server or agent willing to accept both geo.position and geo.region headers 5. Semantics Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point (the period character, "."). Decimal fractions of a degree should be expressed to the precision available, with trailing zeroes being used as placeholders if required. A decimal point is optional where the precision is less than one degree. Latitudes north of the equator MAY be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Latitudes south of the Equator MUST be designated by a A.Daviel [Page 4] Apr 2001 (Expires Oct 2001) minus sign (-) preceding the digits designating degrees. Latitudes on the Equator MUST be designated by a latitude value of 0. Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Longitudes west of the prime meridian MUST be designated by a minus sign (-) preceding the digits designating degrees. Longitudes on the prime meridian MUST be designated by a longitude value of 0. A point on the 180th meridian shall be taken as 180 degrees West, and shall include a minus sign. Any spatial address with a latitude of +90 (90) or -90 degrees will specify a position at the True North or True South Poles, respectively. The component for longitude may have any legal value. The vertical coordinate (Elevation) must be expressed in meters above WGS-84 datum. Points having zero elevation must not have a negative sign. 6. Formal Syntax DIGIT = %x30-39 ; 0-9 COMMA = "," ; , PLUS = %x2B ; + MINUS = %x2D ; - DECIMAL = %x2E ; . SEMI = %x3B ; ; COLON = %x3A ; : UCASE = %x41-5A ; A-Z HYPHEN = %x2D ; - country = 2UCASE ; 2-letter code from ISO3166 region = 1*3UCASE / 2DIGIT ; region code from ISO3166-2 delimiter = SEMI CRLF = %x0D.%x0A ; return, linefeed SP = %x20 ; space HTAB = %x09 ; tab WSP = SP / HTAB ; LWSP = (WSP / CRLF WSP) ; linear whitespace latitude = [ MINUS / PLUS ] 0*2DIGIT [ DECIMAL *DIGIT] longitude = [ MINUS / PLUS ] 0*3DIGIT [ DECIMAL *DIGIT] elevation = [ MINUS / PLUS ] 0*DIGIT [ DECIMAL *DIGIT] position = latitude longitude [ elevation ] georegion = country [ HYPHEN region ] accept-field = "position" / "region" A.Daviel [Page 5] Apr 2001 (Expires Oct 2001) message-header = position-header / region-header / accept-header position-header = "geo.position" COLON *WSP position CRLF region-header = "geo.region" COLON *WSP georegion CRLF accept-header = "Accept-Geo" COLON *WSP accept-field [ COMMA accept-field ] 7. Applicability As stated in the introduction, certain HTTP response bodies such as HTML documents may be associated with a geographic position, while other responses are not. For proper use of the GEO headers as described in this draft, the resource described in an HTTP response should be associated with a particular location for the lifetime of the response. The geographic position given in a response is associated with the resource described by the HTTP body, not with the location of the server or the location of the organization responsible for publishing or hosting the document. Thus, in some cases the country code used in "geo.region" may differ from the country code forming part of the host address in the document URL. The position information sent in a request is a qualification of the HTTP request, and does not necessarily represent the actual position of the requesting agent. The extension headers described in this draft are not intended to permit the accurate communication of the position of mobile networked devices, but rather to facilitate the identification of location-based resources or documents. 8. Treatment of geo headers by proxy agents Geo extension headers are end-to-end header fields and should be transmitted to the ultimate destination of the declaration (the server). They should be forwarded and ignored by proxy agents. Although the use of geo headers may have some caching implications, since a response to a query which was valid at one location may not be valid at a different location, it is not expected that proxy agents will be aware of geo header content. User agents should therefore send appropriate cache control directives to ensure that valid data is received. 9. Security Considerations This draft raises certain issues of privacy. If geo extensions are added to an HTTP request, the server may guess the ethnic origin of the person making the request. If a geo.position extension is given to a high degree of accuracy for a request made from a fixed A.Daviel [Page 6] Apr 2001 (Expires Oct 2001) location such as a private residence, the server may be able to uniquely identify the requestor, or their street address. If no controls are implemented, it would be possible to identify a persons location and perhaps identity from their general Web browsing activity, or by sending them an HTML mail message. If geo extensions are added to an HTTP response by a server which is included in a mobile device with positioning capability, then remote clients will be able to determine the location of the device. This may lead to a loss of privacy. An example of such a device might be an embedded diagnostic system in an automobile. In cases where a portion of the data path from client to server includes an unencrypted wireless link, it may be possible for data including position information to be intercepted by a third party. This third party may be able to determine the location of the mobile device, and may be able to associate the mobile device with a particular person visually based on location data. This association may exacerbate the loss of privacy inherent in using an unencrypted wireless data path. 9.1 User Control Agents and servers incorporating geo extensions should do so in a manner such that the user may disable their use. Agents should provide a mechanism to control sending of position data to certain sites, and optionally a method to degrade the accuracy of position data if this position is obtained automatically from navigation equipment such as GPS. Where the user agent is in a fixed location and the position data is entered manually by the user, the configuration procedure should include privacy warnings. User agents may also allow the user to configure them so that position data is sent only to those servers having a valid SSL certificate issued by a trusted Certificate Authority. It is recommended that, where sensitive position data is returned by a server such as a mobile device, and authentication is used to control access to the server, that position data not be returned to the client before authentication has taken place, regardless of any Accept headers that may have been sent by the client. 9.2 Encryption It is suggested that, where possible, HTTP requests including geo.position headers be encrypted using an end-to-end encryption scheme such as SSL [9]. This mechanism provides a degree of trust in the identity of the server, and guards against disclosure of possibly A.Daviel [Page 7] Apr 2001 (Expires Oct 2001) sensitive position information by proxy agents, firewalls or recording devices. Another mechanism which may be used to protect the privacy of the user is to use a trusted proxy agent such as Squid [11]. Use of a proxy which does not forward the client address will prevent an untrusted server from tracking the position of a particular client by address, though tracking by cookies [6] may be possible if these are enabled, or by "web bugs" [12]. A more sophisticated proxy system such as the Freedom client [10] offers more protection such as encryption, anonymous redirection and cookie filtering. 10. Internationalization considerations Geo.position and geo.region values are defined using US-ASCII. 11. References [1] Berners-Lee, Fielding, Frystyk Hypertext Transfer Protocol -- HTTP/1.0 RFC 1945, May 1996 http://www.alternic.org/rfcs/rfc1900/rfc1945.txt [2] Fielding, Gettys, Mogul, Frystyk, Berners-Lee Hypertext Transfer Protocol HTTP/1.1, RFC 2068 January 1997 http://www.alternic.org/rfcs/rfc2000/rfc2068.txt [3] United States Department of Defense; DoD WGS-1984 - Its Definition and Relationships with Local Geodetic Systems; Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R- 138-R; CV, KV; [4] ARINC Research Corporation, "Navstar GPS Space Segment / Navigation User Interfaces", IRN-200C-002, September 1997 [5] International Organization For Standardization / Organisation Internationale De Normalisation (ISO), "Standard ISO 3166-1:1997: Codes for the representation of names of countries and their subdivisions - Part 1: Country codes". [6] Kristol & Montulli; HTTP State Management Mechanism; RFC 2109 http://www.alternic.org/rfcs/rfc2100/rfc2109.txt [7] International Organization For Standardization / Organisation Internationale De Normalisation (ISO), "Standard ISO 3166-2:1998: Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision A.Daviel [Page 8] Apr 2001 (Expires Oct 2001) code". [8] F. Dawson, T. Howes ; vCard MIME Directory Profile ; RFC 2426 http://www.alternic.org/rfcs/rfc2400/rfc2426.txt [9] Secure Socket Layer ; Netscape Communications Corporation http://home.netscape.com/eng/ssl3/ [10] The Freedom Internet Privacy Suite ; Zero-Knowledge Systems http://www.freedom.net/ [11] The Squid Web Cache ; Duane Wessels and K Claffy ; IEEE Journal on Selected Areas in Communication, April 1998, Vol 16 #3, pages 345-357 http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz [12] Web Bugs; Richard M Smith ; Privacy Foundation http://www.privacyfoundation.org/education/webbug.html 10. Acknowledgments Rohan Mahy and Patrik F"altstr"om of Cisco Systems, for semantics. 11. Author's Address Andrew Daviel, BSc. Vancouver Webpages, Box 357 185-9040 Blundell Rd Richmond BC V6Y 1K3 Canada Tel. (604)-377-4796 Fax. (604)-270-8285 mailto:andrew@vancouver-webpages.com Felix A. Kaegi Dipl.Informatik Ing. ETH (M.Sc.) Friedensgasse 51 CH-4056 Basel SWITZERLAND +41 61 383 10 01 felix_kaegi@hotmail.com A.Daviel [Page 9]