INTERNET-DRAFT Vancouver Webpages <draft-daviel-http-geo-header-02.txt> Sept 2000 (Expires Mar. 2001) Geographic extensions for HTTP transactions Andrew Daviel 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. 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]
<draft-daviel-http-geo-header-02.txt> Sept 2000 (Expires Mar. 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 or shipwrecks. 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]). 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 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 (with SA off). 3. Implementation A.Daviel [Page 2]
<draft-daviel-http-geo-header-02.txt> Sept 2000 (Expires Mar. 2001) 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]. 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). 5. Applicability As stated in the introduction, certain HTML documents may be associated with a geographic position, while other documents are not. For proper use of the "geo" headers as described in this draft, the resource described in an HTML document should be associated with a particular location for the lifetime of the document. The tags may be properly used to describe, for instance, a retail store, a mountain peak or a railway station but not an oil company, river, aircraft or mathematical theory. The geographic position given 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. A.Daviel [Page 3]
<draft-daviel-http-geo-header-02.txt> Sept 2000 (Expires Mar. 2001) 6. 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. 7. Further information Further information may be obtained at http://geotags.com/geo 8. 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 location such as a private residence, the server may be able to uniquely identify the requestor, perhaps by street address. It is suggested that agents incorporating geo extensions do so in a manner such that the user may disable this feature, and that users with moderate privacy concerns limit the accuracy of their position information, perhaps indicating their city or neighorbood rather than their house. User agents such as Web browsers may implement privacy protection similar to that provided for cookies [6] whereby the user can control whether geo headers are generated, or to which Internet domains geo headers are sent. 9. Internationalization considerations Geo.position and geo.region values should use US-ASCII or UTF-8. 10. 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 A.Daviel [Page 4]
<draft-daviel-http-geo-header-02.txt> Sept 2000 (Expires Mar. 2001) 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 code". [8] F. Dawson, T. Howes ; vCard MIME Directory Profile ; RFC 2426 http://www.alternic.org/rfcs/rfc2400/rfc2426.txt 11. Author's Address Andrew Daviel 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 A.Daviel [Page 5]