Original text:
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. <del> Relative tradeoffs between the cost of closing and reopening a </del>  connection and trying to keep it open are different; see resumption- v-keepalive. 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 <del> idempotence either ecplicitly or implicitly. </del>  3.2. streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these <del> streams are not exposed to the apllication. </del>  Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be <del> opened for each chunk/message.  However, a QUIC receiver has a maximum number of concurrently open streams.  If the stream limit is exhausted a sender is able to indicate that more streams are needed, however, this does not automatically lead to an increase of the maximum number of streams by the receiver.  Therefore it can be valuable to expose this maximum number to the application, or the number of currently still available, unused streams, and make the mapping of data to streams dependent on this information. </del>  Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months, <del> or years), should rather utilize the 0-RTT seesion resumption ability </del>  provided by QUIC, than trying to maintain one connection open. 4.1. maximally pack packets to minimize bandwidth consumption and computational costs with one or multiple same data frames.  If not enough data available to send QUIC may even wait for a short time, <del> trading of latency and bandwidth effeciency.  This time might either </del>  be pre-configured or can the dynamically adjusted based on the <del> observed sending pattern of the application.  If the apllication </del>  requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Or if a certain sending pattern is know by the <del> application, it might also provide valuabe to QUIC how long it should wait to bundle frame into a packet. </del>  4.3. receiver.  Prioritization can be realized by the sender and the QUIC transport should provide an interface for applications to prioritize streams QUIC.  Further applications can implement their own <del> prioritization scheme on top of QUIC: an an (application) protocol that run on top of QUIC can define explict messages for signaling </del>  priority, such as those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the in the transport layer.  QUIC recommends to retransmit lost data before new data, unless indicated differently by the application. Currently QUIC only provides fully reliable stream transmission, and <del> as such prioritization of retransmissionis likely beneficial in most </del>  cases, as gaps that get filled up and thereby free up flow control. For not fully reliable streams priority scheduling of retransmissions over data of higher-priority streams might not be desired.  In this associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. <del> Specificially, an application that has additional information that the client is not behind a NAT and the server is not behind a load </del>  balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a connection ID. 7. <del> Versioning in QUIC may change the the protocol's behavior completely, </del>  except for the meaning of a few header fields that have been declared to be fixed.  As such version of QUIC with a higher version number does not necessarily provide a better service, but might simply

Reviewer comments:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)

Revised text:
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.  <ins> Relative trade-offs between the cost of closing and reopening a </ins> connection and trying to keep it open are different; see resumption- v-keepalive. 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  <ins> idempotence either explicitly or implicitly. </ins> 3.2. streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these  <ins> streams are not exposed to the application. </ins> Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be  <ins> opened for each chunk/message.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver. Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </ins> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months,  <ins> or years), should rather utilize the 0-RTT session resumption ability </ins> provided by QUIC, than trying to maintain one connection open. 4.1. maximally pack packets to minimize bandwidth consumption and computational costs with one or multiple same data frames.  If not enough data available to send QUIC may even wait for a short time,  <ins> trading of latency and bandwidth efficiency.  This time might either </ins> be pre-configured or can the dynamically adjusted based on the  <ins> observed sending pattern of the application.  If the application </ins> requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Or if a certain sending pattern is know by the  <ins> application, it might also provide valuable guidance to QUIC how long it should wait to bundle frame into a packet. </ins> 4.3. receiver.  Prioritization can be realized by the sender and the QUIC transport should provide an interface for applications to prioritize streams QUIC.  Further applications can implement their own  <ins> prioritization scheme on top of QUIC: (an application) protocol that run on top of QUIC can define explicit messages for signaling </ins> priority, such as those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the in the transport layer.  QUIC recommends to retransmit lost data before new data, unless indicated differently by the application. Currently QUIC only provides fully reliable stream transmission, and  <ins> as such prioritization of retransmissions likely beneficial in most </ins> cases, as gaps that get filled up and thereby free up flow control. For not fully reliable streams priority scheduling of retransmissions over data of higher-priority streams might not be desired.  In this associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake.  <ins> Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load </ins> balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a connection ID. 7.  <ins> Versioning in QUIC may change the protocol's behavior completely, </ins> except for the meaning of a few header fields that have been declared to be fixed.  As such version of QUIC with a higher version number does not necessarily provide a better service, but might simply