Draft: draft-ietf-quic-transport

Commentary: This should address all of them at once ; one per commit for those that I think need action . This is probably OK : This is not expressly forbidden . We do say : Which does n't really contradict the other . FWIW , I 'm not a fan of allowing frames to be copied , implementations really should do that , but it 's a consequence of having frame idempotency . This is one I 'm not sure about : What is the prevailing advice regarding MTU and tunnels ? Clearly when you tunnel you get a smaller MTU , but I have n't seen what happens when IPv6 is tunneled over a network that has a minimum MTU . Most paths do n't have that small an MTU , so it might be that things just fail . 
 I realized that there are some answers here in the description , but probably best to move them to the relevant issues anyways . 
 said : 
 said : with TLS . 
 said : 
 said : this true for PATH_CHALLENGE ? I thought this quite explicitly should n't be copied . 
 My recommendation is to answer the question , but not change anything . See for an answer . 
 Very well , please close this issue . Sorry for the confusion . 
 said : RESET_RECVD . 
 said : 
 said : 
 This looks good to me , with 's nit .
Paragraph (version A):
In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames.  The endpoint respects the
flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames.  An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream or connection flow control limits data-flow-control.
Paragraph (version B):
In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames.  The endpoint respects the
flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames.  An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream flow control limits data-flow-control.
Paragraph (version A):
If a server receives a client Initial that can be unprotected but
contains an invalid Retry token, it knows the client will not accept
another Retry token.  The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client.  Instead, the
server SHOULD immediately close (immediate-close) the connection with
an INVALID_TOKEN error.  Note that a server has not established any
state for the connection at this point and so does not enter the
closing period.
Paragraph (version B):
If a server receives a client Initial that contains an invalid Retry
token but is otherwise valid, it knows the client will not accept
another Retry token.  The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client.  Instead, the
server SHOULD immediately close (immediate-close) the connection with
an INVALID_TOKEN error.  Note that a server has not established any
state for the connection at this point and so does not enter the
closing period.
Paragraph (version A):
The current maximum stream data offset is sent in MAX_STREAM_DATA
frames.  Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the
frame from being sent too often.  An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receiving part of the stream
enters a "Size Known" state.
Paragraph (version B):
The current maximum stream data offset is sent in MAX_STREAM_DATA
frames.  Like MAX_DATA, an updated value is sent when the packet
containing the most recent MAX_STREAM_DATA frame for a stream is
lost or when the limit is updated, with care taken to prevent the
frame from being sent too often.  An endpoint SHOULD stop sending
MAX_STREAM_DATA frames when the receiving part of the stream
enters a "Size Known" or "Reset Recvd" state.
Paragraph (version A):
Versions (versions) and packet numbers sent in the header (packet-
encoding) are described using integers, but do not use this encoding.
Paragraph (version B):
Versions (versions), packet numbers sent in the header (packet-
encoding), and the length of connection IDs in long header packets
(long-header) are described using integers, but do not use this
encoding.
Paragraph (version A):
Note that if the server sends a HelloRetryRequest, the client will
send another series of Initial packets.  These Initial packets will
continue the cryptographic handshake and will contain CRYPTO frames
starting at an offset matching the size of the CRYPTO frames sent in
the first flight of Initial packets.
Paragraph (version B):
Note that if the server sends a TLS HelloRetryRequest (see
Section 4.7 of QUIC-TLS), the client will send another series of
Initial packets.  These Initial packets will continue the
cryptographic handshake and will contain CRYPTO frames starting at an
offset matching the size of the CRYPTO frames sent in the first
flight of Initial packets.
Paragraph (version A):
Other than updating the Destination Connection ID and Token fields,
the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet.  A client MUST use the same
cryptographic handshake message it included in this packet.  A server
MAY treat a packet that contains a different cryptographic handshake
message as a connection error or discard it.
Paragraph (version A):
A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server.  A client
MUST NOT change the cryptographic handshake message it sends in
response to receiving a Retry.
Paragraph (version B):
Other than updating the Destination Connection ID and Token fields,
the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet.  A client MUST use the same
cryptographic handshake message it included in this packet.  A server
MAY treat a packet that contains a different cryptographic handshake
message as a connection error or discard it.  Note that including a
Token field reduces the available space for the cryptographic
handshake message, which might result in the client needing to send
multiple Initial packets.
Paragraph (version B):
A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server.