INTERNET-DRAFT Vancouver Webpages
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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
Daviel,Kaegi [Page 1]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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
Daviel,Kaegi [Page 2]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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.
In cases where the object being described is an area, such as a lake
or a building, the position of the object should not in general be
given to greater precision than the width of the object. If desired,
features within the object may be described in another page and their
position given with greater precision.
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.
Geo headers may be generated directly in a client, such as a geo-
enabled Web browser, or may be added by a geo-enabled HTTP proxy
agent, allowing a standard browser to be used. The proxy agent may be
included on the same platform as the client, as might be the case
where location data is available from an integral GPS receiver.
Alternatively, the proxy agent may be external, as might be the case
where location data is determined by wireless triangulation from a
number of fixed base stations.
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
Daviel,Kaegi [Page 3]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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,
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
Daviel,Kaegi [Page 4]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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
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 ; :
Daviel,Kaegi [Page 5]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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 <delimiter> longitude [ <delimiter> elevation ]
georegion = country [ HYPHEN region ]
accept-field = "position" / "region"
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
Daviel,Kaegi [Page 6]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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
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
Daviel,Kaegi [Page 7]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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.
If the client device, for reasons of size or otherwise, is not
capable of dialog to create and update access control lists, then
provision should be made for such an access control list to be
created elsewhere and downloaded into the client device or held in an
external location server.
9.2 Encryption
It is suggested that, where possible, HTTP requests including
geo.position headers be encrypted using an encryption scheme such as
SSL or TLS [9][13]. This mechanism provides a degree of trust in the
identity of the server, and guards against disclosure of possibly
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.ietf.org/rfc/rfc1945.txt
Daviel,Kaegi [Page 8]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
[2] Fielding, Gettys, Mogul, Frystyk, Berners-Lee
Hypertext Transfer Protocol HTTP/1.1, RFC 2068 January 1997
http://www.ietf.org/rfc/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.ietf.org/rfc/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.ietf.org/rfc/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.squid-cache.org/Doc/FAQ/FAQ-1.html
[12] Web Bugs; Richard M Smith ; Privacy Foundation
http://www.privacyfoundation.org/resources/index.asp#webbugs
[13] The TLS Protocol ; Dierks, Allen
http://www.ietf.org/rfc/rfc2246.txt
10. Acknowledgments Rohan Mahy and Patrik F"altstr"om of Cisco Systems,
for semantics.
Daviel,Kaegi [Page 9]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
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
12. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Daviel,Kaegi [Page 10]
<draft-daviel-http-geo-header-04.txt> July 2003 (Expires Feb 2004)
Daviel,Kaegi [Page 11]