Original text:
cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- <del> Location field), the URI of this resource SHOULD NOT expose the original request content in plaintext. </del>  6.

Reviewer comments:
Mostly editorial, but touches normative text.
I'm looking for an additional qualification on the statement, something like: Originally posted by NAME in URL
NAME also suggested a reframing to "SHOULD": Originally posted by NAME in URL (Also, should we rename the "safe-method-w-body" label to "query-method", now that that naming thing is settled. It took me a while to remember the right label.)
I'm not confident that implementers will always know what might be sensitive and probably should not expose any of the payload in the URL. I think the qualifier doesn't reduce the suggestion's practical scope at all, so if it gets us to consensus, let's add it.
I'm less concerned about this ending up in logs than you are, it seems :) For me, the risk that a server log might have sensitive information is already at 100%, which means that log processing needs to include considerable care as far as privacy and security risks go.
Both variants work for me, and IMHO are better than what we have now. Mike, pick one :-)
Query media types could evolve whose syntax allows for specification of elements that the user/user-agent considers "sensitive", and also the server could know from the schema of the underlying data. But really I think a big hammer is needed here: the default should be that servers encode none of the query contents into the resulting user-agents should be able to request that behavior with a request header (e.g., ) But user-agents should also be able to request that the resulting encode as much as possible of the request body so that the user can end up having a URI that can form part of the UI. This should be completely as far as the server is concerned, and will not always be possible due to URI length constraints and/or the difficulty of encoding complex queries in URI local-parts and q-params.
I believe that should be completely up to the server.
I'm inclined to agree with Julian here. From the client's perspective, the server is a monolith -- in the course of handling the request, the server necessarily sees the contents and the data (multi-party compute schemes notwithstanding) and the client trusts it to do so according to whatever privacy policy exists. It's the server operator's issue whether they wish to keep certain information out of their logs in order to reduce how tightly access to their logs must be managed. Plus, it's implementation guidance at this point, not protocol conformance. We point out the concern and let people in the real world figure out how they navigate it.
An optional header by which the client can request a URI that encodes the query (which may not be feasible, but often will be) vs. not, seems like a good idea to me -- the server doesn't have to grant the client's wish, but having this request header specified will result in better usability. (To go with this an optional response header by which to indicate which option the server went with would be nice.)
This is all so conditional that I wonder whether it even needs a SHOULD (NOT). Would it be enough to say instead. The other options are fine.

Revised text:
cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-  <ins> Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.