Code change:
If a DELETE method is successfully applied, the origin server SHOULD send <del> A client SHOULD NOT generate content in a DELETE request.  Content received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request. </del> <ins> Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling).  A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.  An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. </ins> Responses to the DELETE method are not cacheable.  If a successful DELETE request passes through a cache that has one or more stored

Related discussion:
text: … might be allowed by consenting adults
My previous comment:
NAME you pushed back on MUST. My position is that our task is to define what's interoperable in HTTP, and bodies on GET clearly aren't. Using SHOULD here is a concession to a vocal minority who want to use the protocol in this way because they have pairwise agreements; I understand that if we use MUST here it'll be violated, but that puts the responsibility squarely and unambiguously on their shoulders. NAME point is valid -- if we use SHOULD, that ought (ha!) to be contextualised. To do so here, we'd need to write something like: The problem is that the message can still be handled by software that isn't party to or aware of that negotiation -- especially, intermediaries. So this isn't really something we should be encouraging. Hence, MUST.
I continue to disagree for the reasons you cited me above. Explaining the "SHOULD NOT" would work for me. If you want a change here, we might want to get those involved who actually use it in practice.
NAME please disambiguate 'above'.
The 'people who use it in practice' are not using HTTP -- they're building private protocols based upon it that don't interoperate with normal HTTP implementations. What they're doing breaks HTTP and HTTP implementations.
RFC 7231: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." I disagree that makes an implementation sending content "not HTTP". You are pushing for a change here, and I really believe you need better arguments to support that. If the intent is to discourage things like that, I'm all in, but using "MUST NOT" is not likely to achieve that goal.
We got here because the 7231 language was ambiguous enough that people misinterpreted it, so we added a RFC2119 requirement. Our AD is rightly pointing out that if we use SHOULD, we need to contextualise it with when it's acceptable to violate the requirement. What text do you propose to perform that function?
"A client SHOULD NOT generate content in a GET request, unless support for content is negotiated (in or out of band)." sounds good to me
As I explained above, that won't work. Out-of-Band negotiation isn't available to intermediaries.