idnits 2.17.1 draft-thomson-geopriv-held-get-02.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 date (May 27, 2010) is 5082 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Andrew 4 Intended status: Standards Track May 27, 2010 5 Expires: November 28, 2010 7 Using HTTP GET with HTTP-Enabled Location Delivery (HELD) 8 draft-thomson-geopriv-held-get-02 10 Abstract 12 This document describes how an HTTP GET request to an HTTP-Enabled 13 Location Delivery (HELD) resource is handled by the server 14 responsible for that resource. This ensures that requests generated 15 by user agents that are unaware of the special status of a URI do not 16 result in unhelpful responses and enables the use of HTTP GET for 17 location configuration and dereference. 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 November 28, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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. HTTP GET Behaviour . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 The HTTP-Enabled Location Delivery (HELD) protocol 65 [I-D.ietf-geopriv-http-location-delivery] prohibits the use of the 66 HTTP GET method. It does this because a HELD request is not always 67 safe and idempotent [RFC2616], an attribute necessary for use of GET. 69 The behaviour that is expected when a client makes an HTTP GET 70 request to the a HELD URI is therefore undefined. GET is the method 71 assumed by generic user agents, therefore unless context identifies 72 an "https:" URI as a HELD URI, such a user agent might simply send an 73 HTTP GET. 75 Rather than providing an HTTP 405 (Method Not Allowed) response 76 indicating that POST is the only permitted method, this document 77 describes a way for a LIS to provide a HELD location response if it 78 receives an HTTP GET request. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. HTTP GET Behaviour 88 A HELD URI is an "https:" or "http:" URI that is either the product 89 of LIS discovery [I-D.ietf-geopriv-lis-discovery] or a location URI 90 generated by a LIS [I-D.winterbottom-geopriv-deref-protocol]. 92 An HTTP GET request to a HELD URI produces a HELD response as if the 93 following HELD request had been sent using HTTP POST: 95 96 97 geodetic civic 98 99 101 If the URI is a location URI, this request complies with the limited 102 profile of HELD described in 103 [I-D.winterbottom-geopriv-deref-protocol]. However, a location URI 104 MUST NOT be provided in response to a location dereferencing request. 106 HTTP GET requests must be safe and idempotent - that is, there are no 107 side-effects of making the request and repeating the request does not 108 change the result. If the response provides a location object, this 109 does not pose a problem. Changes in the location information do not 110 occur as a result of requests, they are a result of a change in the 111 value of the resource (the resource being the location of the 112 Target). 114 To ensure that these requests are idempotent, a LIS MUST NOT generate 115 a location URI as a result of serving a GET request. However, if a 116 location URI for the target already exists, it MAY be provided. This 117 approach only works as long as the location URI operates on the 118 "authorization by possession" authorization model ([RFC5808]). 120 4. Security Considerations 122 The security considerations of HELD 123 [I-D.ietf-geopriv-http-location-delivery] apply. This document 124 introduces no further security considerations. 126 5. IANA Considerations 128 This document has no IANA actions. 130 [RFC Editor: please remove this section prior to publication.] 132 6. References 134 6.1. Normative References 136 [RFC2119] Bradner, S., "Key words 137 for use in RFCs to 138 Indicate Requirement 139 Levels", BCP 14, RFC 2119, 140 March 1997. 142 [RFC2616] Fielding, R., Gettys, J., 143 Mogul, J., Frystyk, H., 144 Masinter, L., Leach, P., 145 and T. Berners-Lee, 146 "Hypertext Transfer 147 Protocol -- HTTP/1.1", 148 RFC 2616, June 1999. 150 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 151 J., Thomson, M., and B. 152 Stark, "HTTP Enabled 153 Location Delivery (HELD)", 154 draft-ietf-geopriv-http- 155 location-delivery-16 (work 156 in progress), August 2009. 158 6.2. Informative References 160 [RFC5808] Marshall, R., 161 "Requirements for a 162 Location-by-Reference 163 Mechanism", RFC 5808, 164 May 2010. 166 [I-D.ietf-geopriv-lis-discovery] Thomson, M. and J. 167 Winterbottom, "Discovering 168 the Local Location 169 Information Server (LIS)", 170 draft-ietf-geopriv-lis- 171 discovery-15 (work in 172 progress), March 2010. 174 [I-D.winterbottom-geopriv-deref-protocol] Winterbottom, J., 175 Tschofenig, H., 176 Schulzrinne, H., Thomson, 177 M., and M. Dawson, "A 178 Location Dereferencing 179 Protocol Using HELD", draf 180 t-winterbottom-geopriv- 181 deref-protocol-05 (work in 182 progress), January 2010. 184 Author's Address 186 Martin Thomson 187 Andrew 188 Andrew Building (39) 189 University of Wollongong 190 Northfields Avenue 191 Wollongong, NSW 2522 192 AU 194 Phone: +61 2 4221 2915 195 EMail: martin.thomson@andrew.com 196 URI: http://www.andrew.com/