Original text:
1. <del> This specification updates the HTTP SEARCH method originally defined in RFC5323. </del>  <del> Many existing HTTP-based applications use the HTTP GET and POST methods in various ways to implement the functionality provided by SEARCH. </del>  <del> Using a GET request with some combination of query parameters included within the request URI (as illustrated in the example below) is arguably the most common mechanism for implementing search in web applications.  With this approach, implementations are required to parse the request URI into distinct path (everything before the '?') and query elements (everything after the '?').  The path identifies the resource processing the query (in this case 'http://example.org/ feed') while the query identifies the specific parameters of the search operation. </del>  <del> A typical use of HTTP GET for requesting a search While there are definite advantages to using GET requests in this manner, the disadvantages should not be overlooked.  Specifically: </del>  As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example

Reviewer comments:
(opening this so it has a discussion venue) Currently, the spec uses "SEARCH" (for the reasons given in the spec). Alternatives: 1) pick a new name 2) use GET with payload (probably unrealistic, just listed for completeness) 3) use POST and find a way to label it as safe 4) re-use another existing safe method that takes a body (PROPFIND, REPORT) (just listed for completeness) The obvious drawback in "pick a new name" is the forseealke bike-shedding.
Just my .02. Using is initially attractive because it's familiar; effectively we'd be extending the semantics of the method with a header. However, I'm not sure it's a good idea. implies certain guarantees to clients, servers and intermediaries -- e.g., write-through. If an extension can change those guarantees, it's important that they're visible to all components, and an extension (e.g., a header) by nature can't guarantee that. It seems to me that one of the critical things to do is to get a positive indication from the user agent that the request they're sending doesn't have write-through, so a extension would need to carry an indication from the client. However, the origin server is also likely to need to convey a cache key and perhaps additional information, which leads this approach to something that's looking complex; the client has to send a certain header, the server has to send a certain header, and an intermediary still might not understand what's going on (which might be good or bad). So that makes me lean towards the status quo, (1), or (4) as being more straightforward. Reusing an already-deployed name has been discussed elsewhere; I'm not convinced that it's going to add a lot of value, considering that most traffic is HTTPS now and so intermediaries with fixed lists of supported methods are much less common. If we had data that they'd get through e.g., an enterprise virus scanning proxy whereas a new method wouldn't, I'd be interested to see that. Still, if fits the bill adequately, I think it's fine. The real test will be whether folks (especially HTTP API developers) find it compelling enough to use; I'm not sure quite gets there, but it's in the ballpark. If we're going to consider new names, I'd suggest .
If the point of this exercise is to make safe-ness visible to intermediaries, then a method is the right place to put that signal. I'm comfortable enough with , though an entirely name would be equally good. (I think that we should continue discussion about cache keys separately.)
I value a lot the ability for intermediaries to filter out write requests before they reach an application. Reusing won't have this advantage.
Interim discussion: switch document to use , which has good support from the attendees, and see how it seems to people who would be adopting.
Que? This is far more than the simple rename I was expecting. I had a similar double-take on first read, but most of the additional changes appear to be excising the WebDAV references, which is reasonable to do along with the rename.

Revised text:
1.  <ins> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. </ins>  <ins> Most often, this is desirable when the data conveyed in a request is too voluminous to be encoded into the request's URI.  For example, while this is an common and interoperable query: </ins>  <ins> if the query parameters extend to several kilobytes or more of data it may not be, because many implementations place limits on their size.  Often these limits are not known or discoverable ahead of time, because a request can pass through many uncoordinated systems. Additionally, expressing some data in the target URI is inefficient, because it needs to be encoded to be a valid URI. </ins>  <ins> Encoding query parameters directly into the request URI also effectively casts every possible combination of query inputs as distinct resources.  Depending on the application, that may not be desirable. </ins> As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example