Rewrap

draft-ietf-quic-transport.md

@@ -1533,15 +1533,14 @@ Once a client has received an acknowledgment for a Handshake packet it MAY send
 smaller datagrams.  Sending padded datagrams ensures that the server is not
 overly constrained by the amplification restriction.
 
-Packet loss, e.g., of the server's Handshake packet, can cause a
-situation in which the server cannot send because of the
-anti-amplification limit and the client has no data to send. In order
-to prevent a handshake deadlock as a result of this situation, clients
-SHOULD send a packet upon a handshake timeout, as described in
-{{QUIC-RECOVERY}}. If the client has no data to retransmit and does
-not have Handshake keys, it SHOULD send an Initial packet in a UDP
-datagram of at least 1200 bytes.  If the client has Handshake keys, it
-SHOULD send a Handshake packet.
+Packet loss, e.g., of the server's Handshake packet, can cause a situation in
+which the server cannot send because of the anti-amplification limit and the
+client has no data to send. In order to prevent a handshake deadlock as a result
+of this situation, clients SHOULD send a packet upon a handshake timeout, as
+described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does
+not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of
+at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a
+Handshake packet.
 
 A server might wish to validate the client address before starting the
 cryptographic handshake. QUIC uses a token in the Initial packet to provide
@@ -1602,15 +1601,15 @@ for future connections. Servers MAY discard any Initial packet that does not
 carry the expected token.
 
 Unlike the token that is created for a Retry packet, there might be some time
-between when the token is created and when the token is subsequently used.
-Thus, a token SHOULD include an expiration time.  The server MAY
-include either an explicit expiration time or an issued timestamp and
-dynamically calculate the expiration time.  It is also unlikely that the client
-port number is the same on two different connections; validating the port is
-therefore unlikely to be successful.
+between when the token is created and when the token is subsequently used. Thus,
+a token SHOULD include an expiration time.  The server MAY include either an
+explicit expiration time or an issued timestamp and dynamically calculate the
+expiration time.  It is also unlikely that the client port number is the same on
+two different connections; validating the port is therefore unlikely to be
+successful.
 
-A token SHOULD be constructed to be easily distinguishable from tokens
-that are sent in Retry packets as they are carried in the same field.
+A token SHOULD be constructed to be easily distinguishable from tokens that are
+sent in Retry packets as they are carried in the same field.
 
 If the client has a token received in a NEW_TOKEN frame on a previous connection
 to what it believes to be the same server, it can include that value in the
@@ -1619,8 +1618,8 @@ Token field of its Initial packet.
 A token allows a server to correlate activity between the connection where the
 token was issued and any connection where it is used.  Clients that want to
 break continuity of identity with a server MAY discard tokens provided using the
-NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded
-during connection establishment (they will not be used with new connections).
+NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded during
+connection establishment (they will not be used with new connections).
 
 A client SHOULD NOT reuse a token in different connections. Reusing a token
 allows connections to be linked by entities on the network path
@@ -1683,10 +1682,10 @@ peer from a new local address.  In path validation, endpoints test reachability
 between a specific local address and a specific peer address, where an address
 is the two-tuple of IP address and port.
 
-Path validation tests that packets (PATH_CHALLENGE) can be both sent
-to and received (PATH_RESPONSE) from a peer on the path.  Importantly,
-it validates that the packets received from the migrating endpoint do
-not carry a spoofed source address.
+Path validation tests that packets (PATH_CHALLENGE) can be both sent to and
+received (PATH_RESPONSE) from a peer on the path.  Importantly, it validates
+that the packets received from the migrating endpoint do not carry a spoofed
+source address.
 
 Path validation can be used at any time by either endpoint.  For instance, an
 endpoint might check that a peer is still in possession of its address after a
@@ -1721,9 +1720,8 @@ loss.  An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it
 would an Initial packet, ensuring that connection migration is no more load on a
 new path than establishing a new connection.
 
-The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame
-so that it can associate the peer's response with the corresponding
-PATH_CHALLENGE.
+The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame so that
+it can associate the peer's response with the corresponding PATH_CHALLENGE.
 
 
 ## Path Validation Responses
@@ -1743,26 +1741,26 @@ to the same remote address from which the PATH_CHALLENGE was received.
 
 ## Successful Path Validation
 
-A new address is considered valid when A PATH_RESPONSE frame is received
-that meets the following criteria:
+A new address is considered valid when A PATH_RESPONSE frame is received that
+meets the following criteria:
 
 - It contains that was sent in a previous PATH_CHALLENGE. Receipt of an
   acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate
   validation, since the acknowledgment can be spoofed by a malicious peer.
 
-- It is from the same remote address as that to which the
-  corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is
-  received from a different remote address than the one to which the
-  PATH_CHALLENGE was sent, path validation is considered to have failed,
-  even if the data matches that sent in the PATH_CHALLENGE.
+- It is from the same remote address as that to which the corresponding
+  PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a different
+  remote address than the one to which the PATH_CHALLENGE was sent, path
+  validation is considered to have failed, even if the data matches that sent in
+  the PATH_CHALLENGE.
 
-- It is received on the same local address from which the
-  corresponding PATH_CHALLENGE was sent.
+- It is received on the same local address from which the corresponding
+  PATH_CHALLENGE was sent.
 
-Note that receipt on a different local address doesn't result in path
-validation failure, as it might be a result of a forwarded packet (see
-{{off-path-forward}}) or misrouting. It is possible that a valid
-PATH_RESPONSE might be received in the future.
+Note that receipt on a different local address doesn't result in path validation
+failure, as it might be a result of a forwarded packet (see
+{{off-path-forward}}) or misrouting. It is possible that a valid PATH_RESPONSE
+might be received in the future.
 
 
 ## Failed Path Validation
@@ -2210,13 +2208,12 @@ An endpoint is not expected to handle key updates when it is closing or
 draining.  A key update might prevent the endpoint from moving from the closing
 state to draining, but it otherwise has no impact.
 
-While in the closing period, an endpoint could receive packets from a
-new source address, indicating a client connection migration
-({{migration}}). An endpoint in the closing state MUST strictly limit
-the number of packets it sends to this new address until the address
-is validated (see {{migrate-validate}}). A server in the closing state
-MAY instead choose to discard packets received from a new source
-address.
+While in the closing period, an endpoint could receive packets from a new source
+address, indicating a client connection migration ({{migration}}). An endpoint
+in the closing state MUST strictly limit the number of packets it sends to this
+new address until the address is validated (see {{migrate-validate}}). A server
+in the closing state MAY instead choose to discard packets received from a new
+source address.
 
 
 ## Idle Timeout
@@ -2262,12 +2259,11 @@ increase the time between packets.
 
 Note:
 
-: Allowing retransmission of a closing packet contradicts other advice
-  in this document that recommends the creation of new packet numbers
-  for every packet.  Sending new packet numbers is primarily of
-  advantage to loss recovery and congestion control, which are not
-  expected to be relevant for a closed connection.  Retransmitting the
-  final packet requires less state.
+: Allowing retransmission of a closing packet contradicts other advice in this
+  document that recommends the creation of new packet numbers for every packet.
+  Sending new packet numbers is primarily of advantage to loss recovery and
+  congestion control, which are not expected to be relevant for a closed
+  connection.  Retransmitting the final packet requires less state.
 
 New packets from unverified addresses could be used to create an amplification
 attack (see {{address-validation}}).  To avoid this, endpoints MUST either limit
@@ -2301,13 +2297,12 @@ coalesced (see {{packet-coalesce}}) to facilitate retransmission.
 
 ## Stateless Reset {#stateless-reset}
 
-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 crash or outage might
-result in peers continuing to send data to an endpoint that is unable to
-properly continue the connection.  A stateless reset is not appropriate for
-signaling error conditions.  An endpoint that wishes to communicate a fatal
-connection error MUST use a CONNECTION_CLOSE frame if it has sufficient state
-to do so.
+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 crash or outage might result in
+peers continuing to send data to an endpoint that is unable to properly continue
+the connection.  A stateless reset is not appropriate for signaling error
+conditions.  An endpoint that wishes to communicate a fatal connection error
+MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so.
 
 To support this process, a token is sent by endpoints.  The token is carried in
 the NEW_CONNECTION_ID frame sent by either peer, and servers can specify the
@@ -2341,18 +2336,17 @@ This design ensures that a stateless reset packet is - to the extent possible -
 indistinguishable from a regular packet with a short header.
 
 A stateless reset uses an entire UDP datagram, starting with the first two bits
-of the packet header.  The remainder of the first byte and an arbitrary
-number of random bytes following it are set to unpredictable values.  The last
-16 bytes of the datagram contain a Stateless Reset Token.
-
-A stateless reset will be interpreted by a recipient as a packet with
-a short header.  For the packet to appear as valid, the Random Bits
-field needs to include at least 182 bits of data (or 24 bytes, less
-the two fixed bits). This is intended to allow for a destination
-connection ID of the maximum length permitted, with a minimal packet
-number, and payload.  The Stateless Reset Token corresponds to the
-minimum expansion of the packet protection AEAD.  More random bytes
-might be necessary if the endpoint could have negotiated a packet
+of the packet header.  The remainder of the first byte and an arbitrary number
+of random bytes following it are set to unpredictable values.  The last 16 bytes
+of the datagram contain a Stateless Reset Token.
+
+A stateless reset will be interpreted by a recipient as a packet with a short
+header.  For the packet to appear as valid, the Random Bits field needs to
+include at least 182 bits of data (or 24 bytes, less the two fixed bits). This
+is intended to allow for a destination connection ID of the maximum length
+permitted, with a minimal packet number, and payload.  The Stateless Reset Token
+corresponds to the minimum expansion of the packet protection AEAD.  More random
+bytes might be necessary if the endpoint could have negotiated a packet
 protection scheme with a larger minimum AEAD expansion.
 
 An endpoint SHOULD NOT send a stateless reset that is significantly larger than
@@ -2455,11 +2449,10 @@ Note that Stateless Reset packets do not have any cryptographic protection.
 
 ### Looping {#reset-looping}
 
-The design of a Stateless Reset is such that without knowing the
-stateless reset token it is indistinguishable from a valid packet.
-This means that if a server sends a Stateless Reset to another server,
-that might trigger the sending of a Stateless Reset in response, which
-could lead to infinite exchanges.
+The design of a Stateless Reset is such that without knowing the stateless reset
+token it is indistinguishable from a valid packet. This means that if a server
+sends a Stateless Reset to another server, that might trigger the sending of a
+Stateless Reset in response, which could lead to infinite exchanges.
 
 An endpoint MUST ensure that every Stateless Reset that it sends is smaller than
 the packet which triggered it, unless it maintains state sufficient to prevent
@@ -2587,10 +2580,10 @@ handshake ensures that only the communicating endpoints receive the
 corresponding keys.
 
 The packet number field contains a packet number, which has additional
-confidentiality protection that is applied after packet protection is
-applied (see {{QUIC-TLS}} for details).  The underlying packet number
-increases with each packet sent in a given packet number space, see
-{{packet-numbers}} for details.
+confidentiality protection that is applied after packet protection is applied
+(see {{QUIC-TLS}} for details).  The underlying packet number increases with
+each packet sent in a given packet number space, see {{packet-numbers}} for
+details.
 
 
 ## Coalescing Packets {#packet-coalesce}
@@ -3685,10 +3678,9 @@ subsequent to the first do not need to fit within a single UDP datagram.
 
 <!-- TODO: delete this section after confirming that it is redundant -->
 
-The first Initial packet sent by either endpoint MUST contain a packet
-number of 0. The packet number MUST increase monotonically thereafter.
-Initial packets are in a different packet number space to other
-packets (see {{packet-numbers}}).
+The first Initial packet sent by either endpoint MUST contain a packet number of
+0. The packet number MUST increase monotonically thereafter. Initial packets are
+in a different packet number space to other packets (see {{packet-numbers}}).
 
 ### 0-RTT Packet Numbers {#retry-0rtt-pn}
 
@@ -3743,9 +3735,8 @@ ID that is chosen by the recipient of the packet; the Source Connection ID
 includes the connection ID that the sender of the packet wishes to use (see
 {{negotiating-connection-ids}}).
 
-
-Handshake packets are their own packet number space, and thus
-the first Handshake packet sent by a server contains a packet number of 0.
+Handshake packets are their own packet number space, and thus the first
+Handshake packet sent by a server contains a packet number of 0.
 
 The payload of this packet contains CRYPTO frames and could contain PADDING, or
 ACK frames. Handshake packets MAY contain CONNECTION_CLOSE frames.  Endpoints
@@ -3858,11 +3849,10 @@ MUST include the value of the Original Destination Connection ID field of the
 Retry packet (that is, the Destination Connection ID field from the client's
 first Initial packet) in the transport parameter.
 
-If the client received and processed a Retry packet, it MUST validate
-that the original_connection_id transport parameter is present and
-correct; otherwise, it validates that the transport parameter is
-absent.  A client MUST treat a failed validation as a connection error
-of type TRANSPORT_PARAMETER_ERROR.
+If the client received and processed a Retry packet, it MUST validate that the
+original_connection_id transport parameter is present and correct; otherwise, it
+validates that the transport parameter is absent.  A client MUST treat a failed
+validation as a connection error of type TRANSPORT_PARAMETER_ERROR.
 
 A Retry packet does not include a packet number and cannot be explicitly
 acknowledged by a client.
@@ -4275,11 +4265,10 @@ Additional ACK Block (repeated):
 
 ### ECN section
 
-The ACK frame uses the least significant bit (that is, type 0x03) to
-indicate that ECN feedback follows the ACK blocks. This feedback
-reports receipt of QUIC packets with associated ECN codepoints of
-ECT(0), ECT(1), or CE in the packet's IP header. The ECN section
-consists of 3 ECN counters as shown below.
+The ACK frame uses the least significant bit (that is, type 0x03) to indicate
+that ECN feedback follows the ACK blocks. This feedback reports receipt of QUIC
+packets with associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's
+IP header. The ECN section consists of 3 ECN counters as shown below.
 
 ~~~
  0                   1                   2                   3
@@ -4442,8 +4431,8 @@ FIN bit.
 
 ## NEW_TOKEN Frame {#frame-new-token}
 
-A server sends a NEW_TOKEN frame (type=0x07) to provide the client with
-a token to send in the header of an Initial packet for a future connection.
+A server sends a NEW_TOKEN frame (type=0x07) to provide the client with a token
+to send in the header of an Initial packet for a future connection.
 
 The NEW_TOKEN frame is as follows:
 
@@ -4537,15 +4526,14 @@ Stream Data:
 When a Stream Data field has a length of 0, the offset in the STREAM frame is
 the offset of the next byte that would be sent.
 
-The first byte in the stream has an offset of 0.  The largest offset
-delivered on a stream - the sum of the offset and data length - MUST
-be less than 2^62.
+The first byte in the stream has an offset of 0.  The largest offset delivered
+on a stream - the sum of the offset and data length - MUST be less than 2^62.
 
 
 ## MAX_DATA Frame {#frame-max-data}
 
-The MAX_DATA frame (type=0x10) is used in flow control to inform the peer of
-the maximum amount of data that can be sent on the connection as a whole.
+The MAX_DATA frame (type=0x10) is used in flow control to inform the peer of the
+maximum amount of data that can be sent on the connection as a whole.
 
 The MAX_DATA frame is as follows:
 
@@ -4943,10 +4931,9 @@ Frame Type:
 
 Reason Phrase Length:
 
-: A variable-length integer specifying the length of the reason phrase
-  in bytes.  Because a CONNECTION_CLOSE frame cannot be split between
-  packets, any limits on packet size will also limit the space
-  available for a reason phrase.
+: A variable-length integer specifying the length of the reason phrase in bytes.
+  Because a CONNECTION_CLOSE frame cannot be split between packets, any limits
+  on packet size will also limit the space available for a reason phrase.
 
 Reason Phrase:
 
@@ -5338,9 +5325,9 @@ An accompanying transport parameter registration (see
 specification needs to describe the format and assigned semantics of any fields
 in the frame.
 
-Expert(s) SHOULD be biased towards approving registrations unless
-they are abusive, frivolous, or actively harmful (not merely aesthetically
-displeasing, or architecturally dubious).
+Expert(s) SHOULD be biased towards approving registrations unless they are
+abusive, frivolous, or actively harmful (not merely aesthetically displeasing,
+or architecturally dubious).
 
 The initial contents of this registry are tabulated in {{frame-types}}.