Draft: draft-ietf-quic-http

Commentary: Rather than putting these at the top of the section , they work fine being at the end . Updating references was not so onerous either . 
  notes that there is some duplication in the subsections here . This is a simple move for the moment ; we can remove redundancies as a separate step . 
 opened for that . 
 The section on Immediate Close contains some text that is redundant with the section on the Closing and Draining periods . Factor some of this out . 
 I understand why you might want to cover closing and draining states before covering the types of close , but I think it would actually be clearer pedagogically to cover the types of close and point to closing and draining states , putting that later . 
 I agree with this , but it will require some updates to other drafts . 
 Given that closing / draining states only occur after immediate close , it might make more sense to move 10.1 to be 10.[3 - 2].2 
 Actually , poking at it a bit , that works -- but a lot of the content in current-10.1 duplicates content in current-10.3 . Rather than merely moving the text to be a sub - section , we should probably try to condense it a bit ; either move all the close / drain requirements into the new subsection , or fold the two sections together . 
 I 'm okay with deferring that step , but would prefer not to lose the feedback .
Paragraph (version A):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
or server pushes, as described in Section 10.2.2 of QUIC-TRANSPORT.
If the client is not expecting a response from the server, allowing
an idle connection to time out is preferred over expending effort
maintaining a connection that might not be needed.  A gateway MAY
maintain connections in anticipation of need rather than incur the
latency cost of connection establishment to servers.  Servers SHOULD
NOT actively keep connections open.
Paragraph (version B):
HTTP clients are expected to request that the transport keep
connections open while there are responses outstanding for requests
or server pushes, as described in Section 10.1.2 of QUIC-TRANSPORT.
If the client is not expecting a response from the server, allowing
an idle connection to time out is preferred over expending effort
maintaining a connection that might not be needed.  A gateway MAY
maintain connections in anticipation of need rather than incur the
latency cost of connection establishment to servers.  Servers SHOULD
NOT actively keep connections open.
Paragraph (version A):
When using ALPN, endpoints MUST immediately close a connection (see
Section 10.3 of QUIC-TRANSPORT) with a no_application_protocol TLS
alert (QUIC error code 0x178; see tls-errors) if an application
protocol is not negotiated.  While ALPN only specifies that servers
use this alert, QUIC clients MUST use error 0x178 to terminate a
connection when ALPN negotiation fails.
Paragraph (version B):
When using ALPN, endpoints MUST immediately close a connection (see
Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS
alert (QUIC error code 0x178; see tls-errors) if an application
protocol is not negotiated.  While ALPN only specifies that servers
use this alert, QUIC clients MUST use error 0x178 to terminate a
connection when ALPN negotiation fails.