idnits 2.17.1 draft-daviel-http-geo-header-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 196: '...h of the equator MAY be specified by a...' RFC 2119 keyword, line 198: '...h of the Equator MUST be designated by...' RFC 2119 keyword, line 203: '... on the Equator MUST be designated by...' RFC 2119 keyword, line 207: '...des west of the prime meridian MUST be...' RFC 2119 keyword, line 209: '... prime meridian MUST be designated by...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 5 has weird spacing: '...ensions for H...' == Line 111 has weird spacing: '...ated by semic...' == Line 281 has weird spacing: '...ers are end-t...' == Line 297 has weird spacing: '...ccuracy for a...' == Line 365 has weird spacing: '... values are d...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Elevation' on line 111 == Unused Reference: '5' is defined on line 386, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '1') ** Obsolete normative reference: RFC 2068 (ref. '2') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2109 (ref. '6') (Obsoleted by RFC 2965) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2426 (ref. '8') (Obsoleted by RFC 6350) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Vancouver Webpages 3 Apr 2001 (Expires Oct 2001) 5 Geographic extensions for HTTP transactions 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This memo describes a method of adding simple geographic position 31 information to HTTP transactions using extension headers. In the 32 case of an HTTP request, the extensions indicate a geographic 33 position or region that the requesting agent is interested in. This 34 information may be used by a server to present appropriate position- 35 dependent responses, such as search engine results, without the 36 additional overhead of geographic query requests and possibly 37 graphical input. In the case of an HTTP response, the extensions 38 indicate a geographic position or region relevant to the resource 39 described in the body of the response. This information may be used 40 for automated resource discovery. 42 1. Introduction 44 Many resources described by HTML documents on the World-Wide-Web are 45 associated with a particular place on the Earth's surface. While 46 resource discovery on the Web has thus far focussed on document title 48 Apr 2001 (Expires Oct 2001) 50 and open-text keyword searching, in these cases it may be beneficial 51 to facilitate geographic searching. Examples of this kind of resource 52 include pages describing restaurants, shipwrecks, retail stores etc. 53 By including geographic extension headers in HTTP requests and 54 responses, it is possible to tailor responses to the location of the 55 requestor, in the same way that the language of the response may be 56 tailored by using the Accept-Language header ([1]). 58 The use of geographic extension headers may make it more practical to 59 use a small text-based client or embedded device to perform location- 60 based queries. It facilitates the automatic inclusion of current 61 position in queries by defining a standard interface. While position 62 data may be sent in the body of HTTP requests, typically each server- 63 based application will use a different format. 65 2. Example Usage 67 An example of a commonly used resource on the World-Wide-Web is a 68 weather map. This service is provided by many different organizations 69 which cover different regions. In some cases it is possible to select 70 the map for a particular area by choosing a corresponding URL, and it 71 may be possible to customize the response by accepting a cookie [6] 72 from a particular server. If the user moves to another location, and 73 wishes to locate a map for that area instead, there is currently no 74 transparent way to generate the appropriate URL. If the service is 75 provided from a different Internet domain, the cookie mechanism 76 cannot be used to register user preferences. 78 If geographic extension headers are used, they may be used to 79 transparently indicate the user's preference for a particular 80 geographic area. A portable computer might be fitted with a 81 navigation system such as GPS [4] which provides positional 82 information, and this could be used to automatically generate 83 appropriate extension header values which would retrieve weather maps 84 for the user's current position, or other information such as 85 locations of hotels, repair facilities etc. 87 2. Coordinate Systems 89 Resource positions on the Earth's surface should be expressed in 90 degrees North of Latitude, degrees East of Longitude as signed 91 decimal numbers. Elevation should be expressed as a signed decimal 92 number of metres above datum. The number of decimal places given 93 should reflect the precision of the coordinates, with zeroes being 94 used as placeholders. A decimal point is optional where the 95 precision is less than one degree. Where the precision of the 96 coordinates is such that the datum used is significant, typically 97 more precise than one kilometre distance, positions should be 99 Apr 2001 (Expires Oct 2001) 101 converted to the WGS 84 datum [3]. Positions given by a GPS set [4] 102 with datum set to "WGS 84" will in most cases be adequate, of the 103 order of 15 metres accuracy. 105 3. Implementation 107 Geographic information is included as "extension-headers" in HTTP 108 requests and responses (the HTTP Hypertext Transfer Protocol [1][2]). 109 The identifier "geo.position" is used for Latitude, Longitude and 110 optionally Elevation values. These should be ordered (Latitude 111 Longitude [Elevation]) separated by semicolons (";"), similar to the 112 vCard GEO element [8]. 114 The identifier "geo.region" is taken from the reserved list, ISO 115 3166-2 [7]. 117 The identifier "Accept-Geo" is used by an agent or server to indicate 118 a willingness to accept geo headers in HTTP transactions. 120 Geo headers may be sent either by a server or by a client. It is 121 anticipated that in most applications the headers will be included in 122 a client request. 124 3.1 Negotiation 126 Use of negotiation is recommended. 128 If negotiation is not used, a client may be configured to return geo 129 headers for all HTTP requests, or only in requests to certain 130 servers. 132 Negotiation is used to establish a trust relationship between the 133 client and server, that is to say between the person initiating the 134 request and the organization providing the requested information. 135 The user agent may maintain a list of trusted sites to which position 136 data is sent, with optional accuracy information. The user may wish 137 to send precise data to one site, approximate position data to 138 others, and none to those not listed. It is recommended that 139 specific provision be made to control position data sent in response 140 to an HTML email message. 142 If the user requests a geo-enabled document from a server, the server 143 responds with an Accept-Geo. header. If the server is not in the list 144 of trusted sites, the user agent should open a dialog with the user 145 to ask them whether position data should be sent. The agent may ask, 146 for instance, whether position data should be sent once, always, or 147 never. it may also ask to what precision the data should be given, 149 Apr 2001 (Expires Oct 2001) 151 for instance to the nearest 10km, 1km or 10m. The user agent may 152 also provide a means to require certain security features, for 153 instance that the server is using a valid SSL certificate from a 154 trusted CA, or a certain level of encryption. The agent 155 configuration may allow default settings, such as sending approximate 156 position data to any unlisted site, or sending position data only to 157 trusted sites using SSL. 159 4. Examples 161 geo.position: 48.54;-123.84;120 163 describes a resource 120 metres above datum at position 48.54 degrees 164 North, 123.84 degrees West, while 166 geo.position: -10;60 168 describes a resource at position 10 degrees South, 60 degrees East. 170 geo.region: CA-ON 172 describes a resource in Ontario, Canada while 174 geo.region: GB 176 describes a resource in England (Great Britain). 178 Accept-Geo: position,region 180 is sent by a server or agent willing to accept both geo.position and 181 geo.region headers 183 5. Semantics 185 Values for latitude and longitude shall be expressed as decimal 186 fractions of degrees. Whole degrees of latitude shall be represented 187 by a decimal number ranging from 0 through 90. Whole degrees of 188 longitude shall be represented by a decimal number ranging from 0 189 through 180. When a decimal fraction of a degree is specified, it 190 shall be separated from the whole number of degrees by a decimal 191 point (the period character, "."). Decimal fractions of a degree 192 should be expressed to the precision available, with trailing zeroes 193 being used as placeholders if required. A decimal point is optional 194 where the precision is less than one degree. 196 Latitudes north of the equator MAY be specified by a plus sign (+), 197 or by the absence of a minus sign (-), preceding the designating 198 degrees. Latitudes south of the Equator MUST be designated by a 200 Apr 2001 (Expires Oct 2001) 202 minus sign (-) preceding the digits designating degrees. Latitudes 203 on the Equator MUST be designated by a latitude value of 0. 205 Longitudes east of the prime meridian shall be specified by a plus 206 sign (+), or by the absence of a minus sign (-), preceding the 207 designating degrees. Longitudes west of the prime meridian MUST be 208 designated by a minus sign (-) preceding the digits designating 209 degrees. Longitudes on the prime meridian MUST be designated by a 210 longitude value of 0. A point on the 180th meridian shall be taken 211 as 180 degrees West, and shall include a minus sign. 213 Any spatial address with a latitude of +90 (90) or -90 degrees will 214 specify a position at the True North or True South Poles, 215 respectively. The component for longitude may have any legal value. 217 The vertical coordinate (Elevation) must be expressed in meters 218 above WGS-84 datum. Points having zero elevation must not have a 219 negative sign. 221 6. Formal Syntax 223 DIGIT = %x30-39 ; 0-9 224 COMMA = "," ; , 225 PLUS = %x2B ; + 226 MINUS = %x2D ; - 227 DECIMAL = %x2E ; . 228 SEMI = %x3B ; ; 229 COLON = %x3A ; : 230 UCASE = %x41-5A ; A-Z 231 HYPHEN = %x2D ; - 232 country = 2UCASE ; 2-letter code from ISO3166 233 region = 1*3UCASE / 2DIGIT ; region code from ISO3166-2 234 delimiter = SEMI 235 CRLF = %x0D.%x0A ; return, linefeed 236 SP = %x20 ; space 237 HTAB = %x09 ; tab 238 WSP = SP / HTAB ; 239 LWSP = (WSP / CRLF WSP) ; linear whitespace 241 latitude = [ MINUS / PLUS ] 0*2DIGIT [ DECIMAL *DIGIT] 242 longitude = [ MINUS / PLUS ] 0*3DIGIT [ DECIMAL *DIGIT] 243 elevation = [ MINUS / PLUS ] 0*DIGIT [ DECIMAL *DIGIT] 244 position = latitude longitude [ elevation ] 245 georegion = country [ HYPHEN region ] 246 accept-field = "position" / "region" 248 Apr 2001 (Expires Oct 2001) 250 message-header = position-header / region-header / accept-header 252 position-header = "geo.position" COLON *WSP position CRLF 253 region-header = "geo.region" COLON *WSP georegion CRLF 254 accept-header = "Accept-Geo" COLON *WSP accept-field [ COMMA accept-field ] 256 7. Applicability 258 As stated in the introduction, certain HTTP response bodies such as 259 HTML documents may be associated with a geographic position, while 260 other responses are not. For proper use of the GEO headers as 261 described in this draft, the resource described in an HTTP response 262 should be associated with a particular location for the lifetime of 263 the response. 265 The geographic position given in a response is associated with the 266 resource described by the HTTP body, not with the location of the 267 server or the location of the organization responsible for publishing 268 or hosting the document. Thus, in some cases the country code used in 269 "geo.region" may differ from the country code forming part of the 270 host address in the document URL. 272 The position information sent in a request is a qualification of the 273 HTTP request, and does not necessarily represent the actual position 274 of the requesting agent. The extension headers described in this 275 draft are not intended to permit the accurate communication of the 276 position of mobile networked devices, but rather to facilitate the 277 identification of location-based resources or documents. 279 8. Treatment of geo headers by proxy agents 281 Geo extension headers are end-to-end header fields and should be 282 transmitted to the ultimate destination of the declaration (the 283 server). They should be forwarded and ignored by proxy agents. 285 Although the use of geo headers may have some caching implications, 286 since a response to a query which was valid at one location may not 287 be valid at a different location, it is not expected that proxy 288 agents will be aware of geo header content. User agents should 289 therefore send appropriate cache control directives to ensure that 290 valid data is received. 292 9. Security Considerations 294 This draft raises certain issues of privacy. If geo extensions are 295 added to an HTTP request, the server may guess the ethnic origin of 296 the person making the request. If a geo.position extension is given 297 to a high degree of accuracy for a request made from a fixed 299 Apr 2001 (Expires Oct 2001) 301 location such as a private residence, the server may be able to 302 uniquely identify the requestor, or their street address. If no 303 controls are implemented, it would be possible to identify a persons 304 location and perhaps identity from their general Web browsing 305 activity, or by sending them an HTML mail message. 307 If geo extensions are added to an HTTP response by a server which is 308 included in a mobile device with positioning capability, then remote 309 clients will be able to determine the location of the device. This 310 may lead to a loss of privacy. An example of such a device might be 311 an embedded diagnostic system in an automobile. 313 In cases where a portion of the data path from client to server 314 includes an unencrypted wireless link, it may be possible for data 315 including position information to be intercepted by a third party. 316 This third party may be able to determine the location of the mobile 317 device, and may be able to associate the mobile device with a 318 particular person visually based on location data. This association 319 may exacerbate the loss of privacy inherent in using an unencrypted 320 wireless data path. 322 9.1 User Control 324 Agents and servers incorporating geo extensions should do so in a 325 manner such that the user may disable their use. Agents should 326 provide a mechanism to control sending of position data to certain 327 sites, and optionally a method to degrade the accuracy of position 328 data if this position is obtained automatically from navigation 329 equipment such as GPS. Where the user agent is in a fixed location 330 and the position data is entered manually by the user, the 331 configuration procedure should include privacy warnings. User agents 332 may also allow the user to configure them so that position data is 333 sent only to those servers having a valid SSL certificate issued by a 334 trusted Certificate Authority. 336 It is recommended that, where sensitive position data is returned by 337 a server such as a mobile device, and authentication is used to 338 control access to the server, that position data not be returned to 339 the client before authentication has taken place, regardless of any 340 Accept headers that may have been sent by the client. 342 9.2 Encryption 344 It is suggested that, where possible, HTTP requests including 345 geo.position headers be encrypted using an end-to-end encryption 346 scheme such as SSL [9]. This mechanism provides a degree of trust in 347 the identity of the server, and guards against disclosure of possibly 349 Apr 2001 (Expires Oct 2001) 351 sensitive position information by proxy agents, firewalls or 352 recording devices. 354 Another mechanism which may be used to protect the privacy of the 355 user is to use a trusted proxy agent such as Squid [11]. Use of a 356 proxy which does not forward the client address will prevent an 357 untrusted server from tracking the position of a particular client by 358 address, though tracking by cookies [6] may be possible if these are 359 enabled, or by "web bugs" [12]. A more sophisticated proxy system 360 such as the Freedom client [10] offers more protection such as 361 encryption, anonymous redirection and cookie filtering. 363 10. Internationalization considerations 365 Geo.position and geo.region values are defined using US-ASCII. 367 11. References 369 [1] Berners-Lee, Fielding, Frystyk 370 Hypertext Transfer Protocol -- HTTP/1.0 371 RFC 1945, May 1996 372 http://www.alternic.org/rfcs/rfc1900/rfc1945.txt 374 [2] Fielding, Gettys, Mogul, Frystyk, Berners-Lee 375 Hypertext Transfer Protocol HTTP/1.1, RFC 2068 January 1997 376 http://www.alternic.org/rfcs/rfc2000/rfc2068.txt 378 [3] United States Department of Defense; DoD WGS-1984 - Its 379 Definition and Relationships with Local Geodetic Systems; 380 Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R- 381 138-R; CV, KV; 383 [4] ARINC Research Corporation, "Navstar GPS Space Segment / 384 Navigation User Interfaces", IRN-200C-002, September 1997 386 [5] International Organization For Standardization / Organisation 387 Internationale De Normalisation (ISO), "Standard ISO 388 3166-1:1997: Codes for the representation of names of 389 countries and their subdivisions - Part 1: Country codes". 391 [6] Kristol & Montulli; HTTP State Management Mechanism; RFC 2109 392 http://www.alternic.org/rfcs/rfc2100/rfc2109.txt 394 [7] International Organization For Standardization / Organisation 395 Internationale De Normalisation (ISO), "Standard ISO 396 3166-2:1998: Codes for the representation of names of 397 countries and their subdivisions - Part 2: Country subdivision 399 Apr 2001 (Expires Oct 2001) 401 code". 403 [8] F. Dawson, T. Howes ; vCard MIME Directory Profile ; RFC 2426 404 http://www.alternic.org/rfcs/rfc2400/rfc2426.txt 406 [9] Secure Socket Layer ; Netscape Communications Corporation 407 http://home.netscape.com/eng/ssl3/ 409 [10] The Freedom Internet Privacy Suite ; Zero-Knowledge Systems 410 http://www.freedom.net/ 412 [11] The Squid Web Cache ; Duane Wessels and K Claffy ; 413 IEEE Journal on Selected Areas in Communication, April 1998, Vol 414 16 415 #3, pages 345-357 416 http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz 418 [12] Web Bugs; Richard M Smith ; Privacy Foundation 419 http://www.privacyfoundation.org/education/webbug.html 421 10. Acknowledgments Rohan Mahy and Patrik F"altstr"om of Cisco Systems, 422 for semantics. 424 11. Author's Address 426 Andrew Daviel, BSc. 427 Vancouver Webpages, Box 357 428 185-9040 Blundell Rd 429 Richmond BC 430 V6Y 1K3 431 Canada 433 Tel. (604)-377-4796 434 Fax. (604)-270-8285 435 mailto:andrew@vancouver-webpages.com 437 Felix A. Kaegi 438 Dipl.Informatik Ing. ETH (M.Sc.) 439 Friedensgasse 51 440 CH-4056 Basel 441 SWITZERLAND 442 +41 61 383 10 01 443 felix_kaegi@hotmail.com