idnits 2.17.1 draft-thomson-geopriv-http-geolocation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 7, 2011) is 4798 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5870' is defined on line 368, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-12 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-12 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-06 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-deref-protocol-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Andrew Corporation 4 Intended status: Standards Track F. Ribeiro 5 Expires: September 8, 2011 6 R. Barnes 7 BBN Technologies 8 March 7, 2011 10 HTTP Geolocation 11 draft-thomson-geopriv-http-geolocation-00 13 Abstract 15 A Geolocation header is defined for HTTP. The Geolocation header 16 provides a reference to location information in an HTTP request. A 17 server can use this information in processing the request. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 8, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Geolocation Header . . . . . . . . . . . . . . . . . . . . . . 3 56 4. 427 (Bad Geolocation) Status Code . . . . . . . . . . . . . . . 4 57 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Geolocation Header Registration . . . . . . . . . . . . . . 7 62 8.2. 427 (Bad Geolocation) Status Code Registration . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 This document describes a header for Hypertext Transfer Protocol 71 (HTTP) [RFC2616] that includes a reference location information. 73 The "Geolocation" request header includes a URI to a resource that 74 includes location information. A server can choose to use this 75 information in serving the request. How this affects the response is 76 up to the server, but this could be used to select content that is 77 more appropriate for a recipient at the given location. 79 2. Terminology 81 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 82 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 83 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 84 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 85 levels for compliant implementations. 87 Some terminology from [I-D.ietf-geopriv-arch] is used. 89 3. Geolocation Header 91 The "Geolocation" header is a end-to-end request header that includes 92 a reference to location information. This reference is an absolute 93 URI [RFC3986] that identifies a resource that contains location 94 information. 96 The following ABNF [RFC5234] defines the syntax of the Geolocation 97 header. This ABNF uses the modified syntax and existing rules for 98 HTTP from [I-D.ietf-httpbis-p1-messaging]. 100 Geolocation-Header = "Geolocation:" OWS "<" absolute-URI ">" 101 *geoloc-param 102 geoloc-param = OWS ";" OWS token [ "=" word ] 104 The value of location information can be carried in the body of a 105 request using a "cid:" URI [RFC2392]. The "geo:" URI 106 [RFC5870]provides another means of including location information 107 directly. 109 Location information that is included by reference to an independent 110 resource means that the server has some control over how location 111 information is acquired. Depending on the needs of the server, it 112 may need to follow this reference before responding to the request. 114 A location that is provided by reference to a constantly updating 115 resource could permit a server to request information that better 116 suits their end by a variety of methods. Content negotiation, HTTP- 117 Enabled Location Delivery [I-D.ietf-geopriv-deref-protocol] and 118 location filtering [I-D.ietf-geopriv-loc-filters] could be used, 119 depending on the type and capabilities of the identified resource. 120 Providing location by reference allows a server to request location 121 information some time after receiving the request, enabling 122 applications that operate outside the time of the client-server 123 interaction. This has potential privacy implications, see Section 6. 125 Servers that implement support for the Geolocation header MUST 126 support "cid:", "https:" and "http:" URIs. Servers MUST support 127 location information in the form of a Presence Information Data 128 Format - Location Object (PIDF-LO) [RFC4119]. 130 A client SHOULD NOT include multiple Geolocation headers in the same 131 request. Though it is permitted, a server that doesn't have 132 additional information about each URI might find it difficult to 133 select a single location or reconcile different locations. 134 [I-D.ietf-sipcore-location-conveyance] provides a discussion on the 135 consequences of including multiple location values. 137 Resources that provide different representations based on the value 138 of the Geolocation header typically need a Vary header containing 139 "Geolocation" if they can be cached. 141 4. 427 (Bad Geolocation) Status Code 143 A status code of 427 indicates that the request contained missing, 144 badly formed, unsupported or inaccessible location information. 146 This indicates that a request might be successful if it contained 147 different location information. The client might: 149 o include a Geolocation header (after gaining permission), if one 150 was absent 152 o include a location value directly, if a location reference was 153 provided 155 o include a different URI type, if alternatives are available 157 o modify any authorization rules on the identified resource to 158 permit the server access 160 A representation included in the response SHOULD provide what 161 guidance the server can provide the client in providing a request 162 that will succeed. 164 5. Examples 166 In the following example, location is included by value. The 167 Geolocation header references a PIDF-LO document in the body of the 168 request. 170 GET /resource HTTP/1.1 171 Host: example.com:8443 172 Geolocation: 173 Content-ID: 174 Content-Length: TBD 175 Content-Type: application/pidf+xml 177 182 183 184 185 186 187 42.5463 -73.2512 188 189 850.24 190 191 192 193 194 OTDOA 195 196 197 198 200 In the following example, location is included by reference to an 201 HTTP resource. 203 GET /resource HTTP/1.1 204 Host: example.com:8443 205 Geolocation: 206 In the following example, an error response indicates that the 207 Geolocation was not accessible by the server. 209 HTTP/1.1 427 Bad Geolocation 210 Host: example.com:8443 211 Content-Type: text/plain;charset=utf-8 212 Content-Length: 95 214 was not accessible. 215 HTTP Error: 403 Forbidden 217 6. Privacy Considerations 219 Location information is highly privacy-sensitive. A discussion of 220 the privacy considerations as they relate to location information in 221 general, and a terminology framework can be found in 222 [I-D.ietf-geopriv-arch]. Most importantly, a client MUST NOT send 223 location information without the permission of a Rule Maker. 225 [I-D.ietf-geopriv-arch] defines rules for the server that are 226 included in the Location Object [RFC4119]. A conforming server MUST 227 respect the rules regarding location retention and retransmission in 228 PIDF-LO. 230 Confidentiality protection, as provided by HTTP over TLS [RFC2818] 231 MUST be used to protect location information, unless other forms of 232 protection are provided, or a Rule Maker has provided permission for 233 information to be universally distributed. This applies whether the 234 request contains location information by value or by reference; the 235 guidance in [RFC5808] recommends confidentiality protection for some 236 URIs that reference location. 238 Location information that is included by reference to a resource 239 allows the server to retrieve location information outside of the 240 context of the request. An access control policy on the referenced 241 resource may be used to control access. 243 The privacy considerations for this document are similar to those for 244 SIP location conveyance [I-D.ietf-sipcore-location-conveyance], with 245 one major exclusion. The intermediary architecture for HTTP doesn't 246 support routing in the same way that SIP does and routing based on 247 location information is not possible in the same manner. For this 248 reason, the privacy concerns relating to routing and the related 249 "Routing-Allowed" header are not relevant to HTTP. 251 7. Security Considerations 253 In addition to the privacy considerations, HTTP over TLS [RFC2818] 254 provides integrity protection for location information on a hop-by- 255 hop basis. 257 Servers that support Geolocation headers need to be aware of the 258 potential attacks that accepting URIs provided by clients could 259 enable. The security considerations of [RFC3986] contains guidance 260 on using URIs. 262 8. IANA Considerations 264 [[Note to IANA/RFC Editor: Please replace instances of RFCXXXX with 265 the number of the published RFC and remove this note.]] 267 8.1. Geolocation Header Registration 269 This section registers the "Geolocation" HTTP header in the 270 "Permanent Message Header Fields" registry established by [RFC3864]. 272 Header field: Geolocation 274 Applicable protocol: HTTP 276 Status: standard 278 Author/change controller: Internet Engineering Task Force, IETF 279 (iesg@ietf.org) 281 Specification document(s): RFCXXXX (this document) 283 8.2. 427 (Bad Geolocation) Status Code Registration 285 This section registers the "Bad Geolocation" HTTP status code in the 286 "Hypertext Transfer Protocol (HTTP) Status Code Registry" registry 287 established by [I-D.ietf-httpbis-p2-semantics]. 289 Status Code Value: 427 291 Description: Bad Geolocation 293 Reference: RFCXXXX (this document) 295 9. References 296 9.1. Normative References 298 [I-D.ietf-httpbis-p1-messaging] 299 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 300 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 301 "HTTP/1.1, part 1: URIs, Connections, and Message 302 Parsing", draft-ietf-httpbis-p1-messaging-12 (work in 303 progress), October 2010. 305 [I-D.ietf-httpbis-p2-semantics] 306 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 307 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 308 "HTTP/1.1, part 2: Message Semantics", 309 draft-ietf-httpbis-p2-semantics-12 (work in progress), 310 October 2010. 312 [I-D.ietf-sipcore-location-conveyance] 313 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 314 for the Session Initiation Protocol", 315 draft-ietf-sipcore-location-conveyance-06 (work in 316 progress), February 2011. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 322 Locators", RFC 2392, August 1998. 324 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 325 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 326 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 328 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 330 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 331 Procedures for Message Header Fields", BCP 90, RFC 3864, 332 September 2004. 334 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 335 Resource Identifier (URI): Generic Syntax", STD 66, 336 RFC 3986, January 2005. 338 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 339 Format", RFC 4119, December 2005. 341 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 342 Specifications: ABNF", STD 68, RFC 5234, January 2008. 344 9.2. Informative References 346 [I-D.ietf-geopriv-arch] 347 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 348 Tschofenig, H., and H. Schulzrinne, "An Architecture for 349 Location and Location Privacy in Internet Applications", 350 draft-ietf-geopriv-arch-03 (work in progress), 351 October 2010. 353 [I-D.ietf-geopriv-deref-protocol] 354 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 355 Thomson, M., and M. Dawson, "A Location Dereferencing 356 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 357 (work in progress), December 2010. 359 [I-D.ietf-geopriv-loc-filters] 360 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 361 Location Notifications in the Session Initiation Protocol 362 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 363 progress), March 2010. 365 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 366 Mechanism", RFC 5808, May 2010. 368 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 369 Identifier for Geographic Locations ('geo' URI)", 370 RFC 5870, June 2010. 372 Authors' Addresses 374 Martin Thomson 375 Andrew Corporation 376 Andrew Building (39) 377 Wollongong University Campus 378 Northfields Avenue 379 Wollongong, NSW 2522 380 AU 382 Phone: +61 2 4221 2915 383 Email: martin.thomson@andrew.com 385 Fernando Ribeiro 386 BR 388 Email: webmaster@fernandoribeiro.eti.br 389 Richard Barnes 390 BBN Technologies 391 9861 Broken Land Pkwy, Suite 400 392 Columbia, MD 21046 393 USA 395 Phone: +1 410 290 6169 396 Email: rbarnes@bbn.com