INTERNET-DRAFT                                     Vancouver Webpages
<draft-daviel-http-geo-header-01.txt>  April 2000 (Expires Nov. 2000)

              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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


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

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-01.txt>     April 2000 (Expires Nov. 2000)

   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 ths
   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 organisations
   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 customise 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. 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 200 metres accuracy.

3.  Implementation

   Geographic information is included as "extension-headers" in HTTP
   requests and responses (the HTTP Hypertext Transfer Protocol [1][2]).

A.Daviel                                                        [Page 2]
<draft-daviel-http-geo-header-01.txt>     April 2000 (Expires Nov. 2000)

   The identifier "geo.position" is used for Latitude and Longitude
   values. These should be ordered (Latitude Longitude) separated by a
   semicolon (";"), 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

   describes a resource 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 organisation 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.

6.  Further information

   Further information may be obtained at http://geotags.com/geo

A.Daviel                                                        [Page 3]
<draft-daviel-http-geo-header-01.txt>     April 2000 (Expires Nov. 2000)

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

8.  Internationalization considerations

   Geo.position and geo.region values  should use US-ASCII or UTF-8.

9.  References

   [1]  Berners-Lee, Fielding, Frystyk
        Hypertext Transfer Protocol -- HTTP/1.0
        RFC 1945, May 1996

   [2]  Fielding, Gettys, Mogul, Frystyk, Berners-Lee
        Hypertext Transfer Protocol HTTP/1.1, RFC 2068  January 1997

   [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

   [7]  International Organization For Standardization / Organisation
        Internationale De Normalisation (ISO), "Standard ISO

A.Daviel                                                        [Page 4]
<draft-daviel-http-geo-header-01.txt>     April 2000 (Expires Nov. 2000)

        3166-2:1998: Codes for the representation of names of
        countries and their subdivisions - Part 2: Country subdivision

   [8]  F. Dawson, T. Howes ; vCard MIME Directory Profile ; RFC 2426

   10.  Author's Address

   Andrew Daviel
   Vancouver Webpages, Box 357
   185-9040 Blundell Rd
   Richmond BC
   V6Y 1K3

   Tel. (604)-377-4796
   Fax. (604)-270-8285

A.Daviel                                                        [Page 5]