Change:
3.1. <del> A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it. Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption- v-keepalive. </del> <ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view of the application using it.  Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. </ins> Applications must be slightly rethought in order to make best use of <del> 0-RTT resumption.  Most importantly, application operations must be divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes idempotence either explicitly or implicitly. </del> <ins> 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </ins> 3.2. Retransmission or (malicious) replay of data contained in 0-RTT <del> resumption packets could cause the server side to receive two copies of the same data.  This is further described in HTTP-RETRY.  Data sent during 0-RTT resumption also cannot benefit from perfect forward secrecy (PFS). Data in the first flight sent by the client in a connection established with 0-RTT MUST be idempotent (as specified in Section 5.6 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: indicate if 0-RTT support is in general desired, which implies that lack of PFS is acceptable for some data; an indication when 0RTT data for both egress and ingress, so that both sender and receiver understand the properties of the communication channel when the data is sent; and/or whether rejected 0-RTT data should be retransmitted or withdrawn. Some TLS implementations may offer replay protection, which may mitigate some of these issues. </del> <ins> packets could cause the server side to receive two copies of the same data. Application data sent by the client in 0-RTT packets could be processed more than once if it is replayed.  Applications need to be aware of what is safe to send in 0-RTT.  Application protocols that seek to enable the use of 0-RTT need a careful analysis and a description of what can be sent in 0-RTT; see Section 5.6 of QUIC- TLS. In some cases, it might be sufficient to limit application data sent in 0-RTT to that which only causes actions at a server that are known to be free of lasting effect.  Initiating data retrieval or establishing configuration are examples of actions that could be safe.  Idempotent operations - those for which repetition has the same net effect as a single operation - might be safe.  However, it is also possible to combine individually idempotent operations into a non-idempotent sequence of operations. Once a server accepts 0-RTT data there is no means of selectively discarding data that is received.  However, protocols can define ways to reject individual actions that might be unsafe if replayed. Some TLS implementations and deployments might be able to provide partial or even complete replay protection, which could be used to manage replay risk. </ins> 3.3.

Discussion:
These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.