[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/