Code change:
the request will have the same intended effect, even if the original request succeeded, though the response might differ. <ins> A client SHOULD NOT automatically retry a request with a non- idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied. For example, a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that request automatically.  Likewise, a user agent designed specifically to operate on a version control repository might be able to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting or fixing any changes that were partially applied, and then automatically retrying the requests that failed. Some clients use weaker signals to initiate automatic retries.  For example, when a POST request is sent, but the underlying transport connection is closed before any part of the response is received. Although this is commonly implemented, it is not recommended. Proxies MUST NOT automatically retry non-idempotent requests. Clients SHOULD NOT automatically retry a failed automatic retry. </ins> 7.2.3. Request methods can be defined as "

Related discussion:
text: See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then.