INTERNET-DRAFT Andrew Daviel
Vancouver Webpages
draft-daviel-http-geo-header-00.txt Sept. 1999 (Expires March 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.
This document is an Internet-Draft. 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.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
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-
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
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
and open-text keyword searching, in these cases it may be beneficial
to facilitate geographic searching. Examples of this kind of resource
A.Daviel [Page 1]
<draft-daviel-http-geo-header-00.txt> August 1999 (Expires Sept. 1999)
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]).
The identifier "geo.position" is used for Latitude and Longitude
values. These should be ordered (Latitude Longitude) separated by a
A.Daviel [Page 2]
<draft-daviel-http-geo-header-00.txt> August 1999 (Expires Sept. 1999)
semicolon (";"), similar to the vCard GEO element [8].
The identifier "geo.placename" is used for a free text
representation of the position, for example "city, province" or
"town, county, state". The identifier "geo.country" is used for the
2-character country code from ISO 3166-1 [5]. The identifier
"geo.region" is taken from a reserved list, typically ISO 3166-2 [7].
It is anticipated that the "geo.placename" tag be used for resource
recognition, rather than resource discovery, due to possible
ambiguities in naming convention, language, word ordering and
placename duplicates.
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 West.
geo.placename: London, Ont
geo.country: ca
describes a resource in London, Ontario, Canada while
geo.placename: London
geo.country: gb
describes a resource in London, 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
A.Daviel [Page 3]
<draft-daviel-http-geo-header-00.txt> August 1999 (Expires Sept. 1999)
"geo.country" 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
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. 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 3166-2:1998
A.Daviel [Page 4]
<draft-daviel-http-geo-header-00.txt> August 1999 (Expires Sept. 1999)
:
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
9. 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]