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-

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

   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

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

   [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: 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

   [9]  Secure Socket Layer ; Netscape Communications Corporation

   [10] The Freedom Internet Privacy Suite ; Zero-Knowledge Systems

   [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

   [12] Web Bugs; Richard M Smith ; Privacy Foundation

   [13] The TLS Protocol ; Dierks, Allen

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

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

   Felix A. Kaegi
   Dipl.Informatik Ing. ETH (M.Sc.)
   Friedensgasse 51
   CH-4056 Basel
   +41 61 383 10 01

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

      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

Daviel,Kaegi                                                   [Page 10]
<draft-daviel-http-geo-header-04.txt>       July 2003 (Expires Feb 2004)

Daviel,Kaegi                                                   [Page 11]