Internet DRAFT - draft-daviel-http-geo-header
draft-daviel-http-geo-header
INTERNET-DRAFT Vancouver Webpages
<draft-daviel-http-geo-header-05> December 7, 2007
Expires: Jun 7, 2008
Intended status: Standards Track
Geographic extensions for HTTP transactions
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on March 1, 2008.
Abstract
This memo describes a method of adding simple geographic position or
region information to HTTP transactions using extension headers. It
allows location-based services on the World Wide Web, without the
additional overhead of geographic query requests and possibly
graphical input. Extension headers transmit predefined or detected
position information to reflect a location 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 or weather maps.
1. Introduction
Daviel,Kaegi,Kofahl [Page 1]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
Many resources on the World-Wide-Web are associated with a particular
place on the Earth's surface. HTML documents may contain geo tags as
described in [RFC2731],[1] but more information with geographic data
is stored in databases (e.g. "yellow pages"). Resource discovery on
the Web has thus far focused on document title and open-text keyword
searching, in the case of yellow pages postcodes or map selection are
also used. However, resource discovery based on geographic criteria
is not widespread because it calls for extensive user-input in terms
of graphical selection. Mobile devices especially will make use of
geographic search but can only with difficulty specify the required
location data (e.g. due to small displays or limited keypads). On
the other hand, mobile devices often integrate a GPS receiver or can
make benefit of network based positioning. It may be beneficial to
facilitate automatic, but user- driven use of geographic information
on the Web. A specification for standardized transmission of
position data will allow advanced search modes, more user-friendly
web pages (e.g. bus schedules in conjunction with nearest stations)
and new location based services which are currently not available on
the World-Wide-Web (e.g. local advertising at small scale). By
including geographic extension headers in HTTP requests, 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 [RFC2616].
2. Example Usage
An example of a commonly used resource on the World-Wide-Web is a
weather map, used by a traveling person. Such a service usually
covers different regions. On a map, the traveler could select the
current position and even store it using cookie methodology
[RFC2965]. However, when moving to another region the cookie will
represent invalid location information.
Beside using cookies, this service is also able to process specific
position information. It announces this capability by sending the
following header: "Vary: Geo-Position". A browser can use this
header if it is connected to a positioning source such as GPS or has
preconfigured data (see region codes, section 3.3). Once the user
decides to send position information in this specific case or in
general, each request to this service includes another header
representing the current position, e.g. "Geo-Position:
48.541;-123.843". In this case, the server may tailor the weather
map to Vancouver Island without further input.
Other services may include positioning metadata such as accuracy and
other parameters for identifying a nearby or distant object.
Daviel,Kaegi,Kofahl [Page 2]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
3. Implementation
3.1 Geographic Position
A request MAY include a geographic position using an HTTP extension
header. The identifier "Geo-Position" is used for this purpose.
Latitude, longitude and altitude are separated by a semicolon. Other
values are given as key-value-pairs (e.g. hdn=130), separated by a
whitespace. Latitude and longitude are mandatory and MUST be
included in each geo-position request. Optional key-value-pairs:
epu - estimated position uncertainty
hdn - heading clockwise from true north
spd - speed
Latitude (degrees north of the equator) and longitude (degrees east
of the prime meridian on the [WGS-84] spheroid) values 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 MUST be separated from the whole number of degrees by a
decimal point (the period character, "."). The number of decimal
places given should reflect the precision of the position
determination method or be reduced in order to reflect privacy issues
(see section 5)
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 MAY 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.
Altitude is expressed as a signed decimal number of metres above
datum, which is [WGS-84]. Decimal places (if required) MUST be
Daviel,Kaegi,Kofahl [Page 3]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
separated by a decimal point ("."). Points having zero or positive
elevation MAY omit the plus sign.
The estimated position uncertainty states the quality of the
submitted position (latitude, longitude, altitude). It is expressed
in metres, and describes a circle or sphere of 95% positioning
probability.
Heading is expressed in decimal degrees clockwise from true north.
Speed is given in metres per second.
If a parameter is intended to be transmitted but the value cannot be
ascertained due to technical reasons, it shall be given as "N/A"
(without quotes).
3.1.1 Examples
(Host headers [RFC2616] are for exemplification only)
Host: maps.example.com
Geo-Position: -10;+60
requests for a map at position 10 degrees south, 60 degrees east. It
must be assumed that a more precise position is not available.
Host: weather.example.com
Geo-Position: -10.28;60.84;120 epu=50
requests for a weather forecast for instance at position 10.28000
degrees south, 60.84000 degrees east, 120 metres above datum
([WGS-84]) with a 95%-confidence boundary of 50 metres (radius).
Host: tourism.example.com
Geo-Position: -10.28;60.84 epu=50 hdn=45
requests for information about an object in north-east direction from
the given position (e.g. the city hall on a place).
Host: traffic.example.com
Geo-Position: -10.28;60.84 epu=50 hdn=45 spd=15
requests for traffic congestion reports for the area at the given
position but traffic in north-east direction only. The service may
assume an average speed for further area selections.
3.2 Negotiation
Daviel,Kaegi,Kofahl [Page 4]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
Use of negotiation is RECOMMENDED.
A geo-enabled server implicitly uses server-driven negotiation as
described in [RFC2616]. For proper operation of HTTP caches, a Vary
header SHOULD be send by the server to indicate that it will serve
different content for requests with different values of the specified
headers, and that a cache should not re-use a cached response unless
a new request has matching headers.
A geo-enabled server SHOULD send appropriate Vary headers to indicate
which client Geo headers will cause a tailored response to be
generated.
A Vary header MAY be used as a means for a server to announce to a
client that it will accept geo headers, triggering a filter dialogue
(section 3.4).
3.2.1 Examples
Vary: Geo-Position
indicates that a server will serve different content in response to
different values of Geo-Position header sent by the client.
Vary: Geo-Country, Geo-A1
indicates that a server will serve different content in response to
to different values of either Geo-Country or Geo-A1 (national
subdivision) headers.
3.3 Region Codes
Instead of position (or even additionally), a client may name an
administrative area it is interested in. The identifier "Geo-
Country" is used to specify a country code from [ISO3166-1]. The
identifiers "Geo-A1", "Geo-LMK" etc. are used to specify a civic
address or region [PIDF-LO]
They are used as extension headers. As an example,
Geo-Country: CA
Geo-A1: ON
requests a resource tailored to Ontario, Canada.
3.4 User Filters
While a geo position header in an HTTP request directs the server to
Daviel,Kaegi,Kofahl [Page 5]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
return information pertaining to a particular position, the server
may infer that the position requested is the current location of the
client. In order to protect the privacy of users against inadvertent
leakage of their personal location information, a user must be able
to control what information is sent to servers.
A Web browser, client or geo-enabling proxy MUST implement a
mechanism for filtering geographic information sent to servers
([RFC3693]). It may maintain a list of trusted sites to which
position data may be sent, or it may maintain a list of regular
expressions which is applied to requested URLs. Position data sent
to remote servers must be filtered using rules based on this list.
The user MUST be provided with tools to maintain this list.
Such a list might contain fields for "address of web site",
"allow/block", "precision", "auth" and "secure". The browser will
send the current position in request headers providing that the site
address is listed and allowed. Position information would be sent to
the defined precision. If the "secure" field is present, then the
browser will only send position information using an encrypted
protocol ([3],[RFC4346]). If the "auth" field is present, then the
browser will only send position information during an authenticated
HTTP session (one in which an Authorization header is sent)
([RFC2617]).
If the client receives an HTTP response containing a Vary header
which specifies a Geo header, and if the site is not in the filter
list, the browser should open a dialogue 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
and will save this information appropriately. It may also ask for
optional data to be sent.
Fuzzing of position information (decreasing its precision) may
typically be done by rounding or reducing the number of decimal
places in latitude and longitude. In order to avoid a "line
crossing" effect, where the exact position of a moving client may be
deduced as, for example, 43.13000 at the instant its declared
coordinate changes from 43.12 to 43.13, it is recommended that a
random offset be added before truncation.
The filter may support a default setting for unlisted sites, for
instance to use a 10km precision for secure sites and to block
insecure sites. The installation value of such a default setting
must be chosen to minimize privacy impact. It should not send more
precise positions than may typically derived from the client Internet
address, such as a metropolitan area or university campus.
Daviel,Kaegi,Kofahl [Page 6]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
3.4.1 Disposition of Location Information
Location information MUST NOT be forwarded to another entity by the
server to which it was sent (the entity that has satisfied the user's
privacy filter). For instance, if alpha.example.com is trusted but
redirects an HTTP request to beta.example.com, a Geo-Position header
must not be sent to beta.example.com unless that site is also
trusted.
3.5 Proxy
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. If location data is added by an
external proxy agent, the user MUST be able to filter such data.
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 non-geo-enabled
proxy agents.
4. Formal Syntax
The syntax uses augmented BNF, described in [RFC2616].
DIGIT = %x30-39 ; 0-9
UCASE = %x41-5A ; A-Z
PLUS = %x2B ; +
MINUS = %x2D ; -
DECIMAL = %x2E ; .
CRLF = %x0D.%x0A ; return, linefeed
SIGN = MINUS / PLUS
country = 2UCASE ; [ISO3166-1]
latitude = [ SIGN ] 1*2DIGIT [ DECIMAL 1*DIGIT ] ; -90 - 90
longitude = [ SIGN ] 1*3DIGIT [ DECIMAL 1*DIGIT ] ; -180 - 180
altitude = [ SIGN ] 1*DIGIT [ DECIMAL 1*DIGIT ] ; metres
uncertainty = 1*DIGIT [ DECIMAL 1*DIGIT ] ; metres
heading = 1*3DIGIT [ DECIMAL 1*DIGIT ] ; 0-360
speed = 1*DIGIT [ DECIMAL 1*DIGIT ] ; metre/sec.
Daviel,Kaegi,Kofahl [Page 7]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
lat = latitude
lon = longitude
alt = altitude
epu = "epu" "=" uncertainty *LWS
hdn = "hdn" "=" heading *LWS
spd = "spd" "=" speed *LWS
Vary = "Vary" ":" ( "*" | 1#field-name )
region-header = "Geo-Country:" country-code CRLF
position-header = "Geo-Position:" LWS
lat;lon[;alt] *( epu | hdn | spd ) CRLF
response-header = accept-header
request-header = [ region-header ] [ position-header ]
4.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
5. Security Considerations
This draft raises certain issues of privacy. 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. However, if geo extensions are added to an HTTP
request, the server may infer the location 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 street
address. If no controls are implemented, it would be possible to
identify a person's location and perhaps identity from their general
Web browsing activity.
In cases where a portion of the data path from client to server
includes an unencrypted 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.
5.1 Encryption
It is suggested that, where possible, HTTP requests including geo
Daviel,Kaegi,Kofahl [Page 8]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
headers be encrypted using an encryption scheme such as SSL or TLS
[3],[RFC4346]. 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 [4]. 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 [RFC2965] may be possible if
these are enabled, or by "web bugs" [5].
6. IANA considerations
The message header fields below should be added to the permanent
registry (see [RFC3864]).
6.1. Geo-Position
Header field name: Geo-Position Applicable protocol: http Status:
standard Author/Change controller: IETF Specification document: this
specification (Section 3.2)
6.2. Geo-Country
Header field name: Geo-Country Applicable protocol: http Status:
standard Author/Change controller: IETF Specification document: this
specification (Section 3.3)
7. Internationalization considerations
Geo-Position, Geo-Velocity and Geo-Country values are defined using
US-ASCII.
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, Gettys, Mogul, Frystyk, Masinter,
Leach, Berners-Lee, "Hypertext Transfer Protocol
HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, Nottingham, Mogul, "Registration
Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004.
Daviel,Kaegi,Kofahl [Page 9]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
[WGS-84] 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;
[ISO3166-1] International Organization For Standardiza-
tion, "Codes for the representation of names
of countries and their subdivisions - Part 1:
Country codes", Standard ISO 3166-1:2006,
November 2006.
10.2 Informative References
[1] Daviel, Kaegi, "Geographic registration of HTML
documents", Internet Draft draft-daviel-html-geo-tag-08,
Sept. 2007
[3] Frier, Karlton, Kocher, "The SSL 3.0 Protocol",
November 1996.
[4] Wessels, Claffy, "ICP and the Squid web cache", IEEE
Journal on Selected Areas in Communication,
April 1998.
[5] Smith, "The Web Bug FAQ", November 1999.
[RFC2731] Kunze, "Encoding Dublin Core Metadata in HTML",
RFC 2731, December 1999.
[RFC2965] Kristol, Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC4346] Dierks, Rescorla, "The Transport Layer Security
(TLS) Protocol", RFC 4346, April 2006.
[RFC2617] Franks, Hallam-Baker et al., "HTTP Authentication: Basic
and Digest Access Authentication", RFC 2617. June 1999
[RFC3693] Cuellar, Morris et al., "Geopriv Requirements", RFC 3693,
February 2004
[PIDF-LO] M. Thomson, J. Winterbottom,
Revised Civic Location Format for PIDF-LO,
draft-ietf-geopriv-revised-civic-lo-07, December 2007
9. Acknowledgments
Daviel,Kaegi,Kofahl [Page 10]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
Rohan Mahy and Patrik Faltstrom of Cisco Systems, for semantics.
10. Authors' Addresses
Andrew Daviel, BSc.
Vancouver Webpages, Box 357
185-9040 Blundell Rd
Richmond BC
V6Y 1K3
Canada
Tel. (604)-377-4796
Fax. (604)-270-8285
advax@triumf.ca
Felix A. Kaegi
Dipl.Informatik Ing. ETH (M.Sc.)
Friedensgasse 51
CH-4056 Basel
SWITZERLAND
Phone +41 61 383 10 01
Fax +41 79 625 27 41
skype felix_kaegi
felix.kaegi@gmail.com
Martin Kofahl
University Rostock
Geodesy and Geoinformatics
D-18051 Rostock
GERMANY
Phone +49 381 498 3212
Fax +49 381 498 3202
m.kofahl@gmx.net
Daviel,Kaegi,Kofahl [Page 11]
<draft-daviel-http-geo-header-05> Dec. 2007 (Expires Jun 2008)
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daviel,Kaegi,Kofahl [Page 12]
