Jana's comments

draft-ietf-quic-transport.md

@@ -721,7 +721,7 @@ increase by at least one after sending any packet, unless otherwise specified
 A QUIC endpoint MUST NOT reuse a packet number within the same connection (that
 is, under the same cryptographic keys).  If the packet number for sending
 reaches 2^64 - 1, the sender MUST close the connection without sending a
-TRANSPORT_CLOSE frame or any further packets; the sender MAY send a Stateless
+CONNECTION_CLOSE frame or any further packets; the sender MAY send a Stateless
 Reset packet in response to further packets that it receives.
 
 To reduce the number of bits required to represent the packet number over the
@@ -844,7 +844,7 @@ explained in more detail as they are referenced later in the document.
 |:------------|:------------------|:----------------------------|
 | 0x00        | PADDING           | {{frame-padding}}           |
 | 0x01        | RST_STREAM        | {{frame-rst-stream}}        |
-| 0x02        | TRANSPORT_CLOSE   | {{frame-transport-close}}   |
+| 0x02        | CONNECTION_CLOSE  | {{frame-connection-close}}  |
 | 0x03        | APPLICATION_CLOSE | {{frame-application-close}} |
 | 0x04        | MAX_DATA          | {{frame-max-data}}          |
 | 0x05        | MAX_STREAM_DATA   | {{frame-max-stream-data}}   |
@@ -1452,22 +1452,22 @@ The time at which an idle timeout takes effect won't be perfectly synchronized
 on peers.  Endpoints might allow for the possibility that the remote side might
 attempt to send packets before the timeout.  In this case, an endpoint might
 choose to retain enough information to generate a packet containing
-TRANSPORT_CLOSE (see {{immediate-close}}).  Endpoints MAY instead rely on
+CONNECTION_CLOSE (see {{immediate-close}}).  Endpoints MAY instead rely on
 sending Stateless Reset in response to packets that arrive after an idle
 timeout.
 
 
 ### Immediate Close
 
-An endpoint sends a TRANSPORT_CLOSE or APPLICATION_CLOSE frame to terminate the
+An endpoint sends a CONNECTION_CLOSE or APPLICATION_CLOSE frame to terminate the
 connection immediately.  These frames causes all open streams to immediately
 become closed; open streams can be assumed to be implicitly reset.  After
-receiving a either a TRANSPORT_CLOSE or APPLICATION_CLOSE frame, endpoints MUST
+receiving a either a CONNECTION_CLOSE or APPLICATION_CLOSE frame, endpoints MUST
 NOT send additional packets on that connection.
 
 An peer that receives either close frame might have sent packets that will
 arrive after the endpoint sent the packet.  An endpoint SHOULD respond to these
-packets with another TRANSPORT_CLOSE or APPLICATION_CLOSE frame.  To minimize
+packets with another CONNECTION_CLOSE or APPLICATION_CLOSE frame.  To minimize
 the state that an endpoint maintains in this case, they MAY send the exact same
 packet.
 
@@ -1480,7 +1480,7 @@ Note:
   the final packet requires less state at the server.
 
 Implementations SHOULD limit the number of packets they generate after sending
-either TRANSPORT_CLOSE or APPLICATION_CLOSE.  For instance, an implementation
+either CONNECTION_CLOSE or APPLICATION_CLOSE.  For instance, an implementation
 could exponentially increase the number of packets that it receives before
 sending another packet.  Once enough time has passed to allow a peer to receive
 the final packet, an endpoint SHOULD discard per-connection state and MAY
@@ -1494,8 +1494,8 @@ A stateless reset is provided as an option of last resort for a server that does
 not have access to the state of a connection.  A server crash or outage might
 result in clients continuing to send data to a server that is unable to properly
 continue the connection.  A server that wishes to communicate a fatal connection
-error MUST use a TRANSPORT_CLOSE or APPLICATION_CLOSE frame if it has sufficient
-state to do so.
+error MUST use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has
+sufficient state to do so.
 
 To support this process, the server sends a stateless_reset_token value during
 the handshake in the transport parameters.  This value is protected by
@@ -1549,7 +1549,7 @@ indistinguishable from a regular packet.
 
 A stateless reset is not appropriate for signaling error conditions.  An
 endpoint that wishes to communicate a fatal connection error MUST use a
-TRANSPORT_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so.
+CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so.
 
 
 #### Detecting a Stateless Reset
@@ -1660,16 +1660,16 @@ Final Offset:
   data written on this stream by the RST_STREAM sender.
 
 
-## TRANSPORT_CLOSE frame {#frame-transport-close}
+## CONNECTION_CLOSE frame {#frame-connection-close}
 
-An endpoint sends a TRANSPORT_CLOSE frame (type=0x02) to notify its peer that
-the connection is being closed.  TRANSPORT_CLOSE is used to signal errors at the
-QUIC layer, or the absence of errors (with the NO_ERROR code).
+An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its peer that
+the connection is being closed.  CONNECTION_CLOSE is used to signal errors at
+the QUIC layer, or the absence of errors (with the NO_ERROR code).
 
 If there are open streams that haven't been explicitly closed, they are
 implicitly closed when the connection is closed.
 
-The TRANSPORT_CLOSE frame is as follows:
+The CONNECTION_CLOSE frame is as follows:
 
 ~~~
  0                   1                   2                   3
@@ -1681,19 +1681,19 @@ The TRANSPORT_CLOSE frame is as follows:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
-The fields of a TRANSPORT_CLOSE frame are as follows:
+The fields of a CONNECTION_CLOSE frame are as follows:
 
 Error Code:
 
 : A 32-bit error code which indicates the reason for closing this connection.
-  TRANSPORT_CLOSE uses codes from the space defined in {{error-codes}};
-  APPLICATION_CLOSE uses codes from the application protocol error code space
-  ({{app-error-codes}}).
+  CONNECTION_CLOSE uses codes from the space defined in {{error-codes}}
+  (APPLICATION_CLOSE uses codes from the application protocol error code space,
+  see {{app-error-codes}}).
 
 Reason Phrase Length:
 
 : A 16-bit unsigned number specifying the length of the reason phrase in bytes.
-  Note that a TRANSPORT_CLOSE frame cannot be split between packets, so in
+  Note that a CONNECTION_CLOSE frame cannot be split between packets, so in
   practice any limits on packet size will also limit the space available for a
   reason phrase.
 
@@ -1707,12 +1707,12 @@ Reason Phrase:
 ## APPLICATION_CLOSE frame {#frame-application-close}
 
 An APPLICATION_CLOSE frame (type=0x03) uses the same format as the
-TRANSPORT_CLOSE frame ({{frame-transport-close}}), except that it uses error
+CONNECTION_CLOSE frame ({{frame-connection-close}}), except that it uses error
 codes from the application protocol error code space ({{app-error-codes}})
 instead of the transport error code space.
 
 Other than the error code space, the format and semantics of the
-APPLICATION_CLOSE frame are identical to the TRANSPORT_CLOSE frame.
+APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame.
 
 
 ## MAX_DATA Frame {#frame-max-data}
@@ -1944,16 +1944,18 @@ The STOP_SENDING frame is as follows:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Stream ID (32)                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                      App  Error Code (32)                     |
+|                   Application Error Code (32)                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
 The fields are:
 
 Stream ID:
+
 : The 32-bit Stream ID of the stream being ignored.
 
-App Error Code:
+Application Error Code:
+
 : A 32-bit, application-specified reason the sender is ignoring the stream (see
   {{app-error-codes}}).
 
@@ -2674,11 +2676,11 @@ connection and stream flow-control windows, even though these frames will be
 discarded upon receipt.  This avoids potential ambiguity about which STREAM
 frames count toward flow control.
 
-Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed
-(remote)" states, an endpoint MUST send a RST_STREAM frame.  If the STOP_SENDING
-frame is received on a stream that is already in the "half-closed (local)" or
-"closed" states, a RST_STREAM frame MAY still be sent in order to cancel
-retransmission of previously-sent STREAM frames.
+A STOP_SENDING frame on a stream in the "open" or "half-closed (remote)" states,
+requests that the the receiving application send a RST_STREAM frame.  If the
+STOP_SENDING frame is received on a stream that is already in the "half-closed
+(local)" or "closed" states, a RST_STREAM frame MAY still be sent in order to
+cancel retransmission of previously-sent STREAM frames.
 
 While STOP_SENDING frames are retransmittable, an implementation MAY choose not
 to retransmit a lost STOP_SENDING frame if the stream has already been closed
@@ -2950,7 +2952,7 @@ frame that signals the error.  Where this specification identifies error
 conditions, it also identifies the error code that is used.
 
 A stateless reset ({{stateless-reset}}) is not suitable for any error that can
-be signaled with a TRANSPORT_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame.  A
+be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame.  A
 stateless reset MUST NOT be used by an endpoint that has the state necessary to
 send a frame on the connection.
 
@@ -2959,25 +2961,25 @@ send a frame on the connection.
 
 Errors that result in the connection being unusable, such as an obvious
 violation of protocol semantics or corruption of state that affects an entire
-connection, MUST be signaled using a TRANSPORT_CLOSE or APPLICATION_CLOSE frame
-({{frame-transport-close}}, {{frame-application-close}}). An endpoint MAY close
+connection, MUST be signaled using a CONNECTION_CLOSE or APPLICATION_CLOSE frame
+({{frame-connection-close}}, {{frame-application-close}}). An endpoint MAY close
 the connection in this manner, even if the error only affects a single stream.
 
 Application protocols can signal application-specific protocol errors using the
 APPLICATION_CLOSE frame.  Errors that are specific to the transport, including
-all those described in this document, are carried in a TRANSPORT_CLOSE frame.
+all those described in this document, are carried in a CONNECTION_CLOSE frame.
 Other than the type of error code they carry, these frames are identical in
 format and semantics.
 
-A TRANSPORT_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is
+A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is
 lost.  An endpoint SHOULD be prepared to retransmit a packet containing either
 frame type if it receives more packets on a terminated connection.  Limiting the
 number of retransmissions and the time over which this final packet is sent
 limits the effort expended on terminated connections.  An endpoint that does not
 retransmit this packet could be forced to use the stateless reset process
 ({{stateless-reset}}).
 
-An endpoint that receives an invalid TRANSPORT_CLOSE or APPLICATION_CLOSE frame
+An endpoint that receives an invalid CONNECTION_CLOSE or APPLICATION_CLOSE frame
 MUST NOT signal the existence of the error to its peer.
 
 
@@ -3004,11 +3006,11 @@ consistent state between endpoints.
 Transport error codes are 32 bits long.
 
 This section lists the defined QUIC transport error codes that may be used in a
-TRANSPORT_CLOSE frame.  These errors apply to the entire connection.
+CONNECTION_CLOSE frame.  These errors apply to the entire connection.
 
 NO_ERROR (0x0):
 
-: An endpoint uses this with TRANSPORT_CLOSE to signal that the connection is
+: An endpoint uses this with CONNECTION_CLOSE to signal that the connection is
   being closed abruptly in the absence of any error.
 
 INTERNAL_ERROR (0x1):