Draft: draft-ietf-quic-recovery

Commentary: Having non - overlapping conditions makes sense ; adjusted wording . 
 The recovery draft : This is consistent with the pseudocode , in particular . When the server receives the client 's final handshake flight , it discards handshake keys and hence can not acknowledge it . When the client receives the resulting , the handshake is confirmed , but no Handshake or 1 - RTT acknowledgements have necessarily been received . This results in a PTO being set even though the client 's address has certainly been verified and there are no ack - eliciting packets in flight . As written , the pseudocode would in fact set a PTO for the Initial space at a garbage time . I think this could be corrected by appending " and has not discarded handshake keys " or " and has not confirmed the handshake " to the language , and adding the analogous clause to the conditions checked in the final statement of . 
 I thought that was implied , but implications are bad , so I agree it 's best to explicitly state it . I 'm happy to review a PR if you have time to write one , or I 'll fix this fairly soon ideally . 
 When a reverse proxy forwards a HTTP response to the client , sometimes it sees the upstream server terminate the response early . For example , a HTTP/1.1 connection being closed prior to transmitting number of bytes specified by the field . Or a chunked response being closed abruptly . The only way of delegating such a condition to the client in HTTP/2 was to send a RSTSTREAM frame with . However , use of the error code is awkward in this case , considering the fact that the error did not happen within the communication between the endpoints using the particular HTTP/2 connection . I think it makes sense to have an error code that better designates the case . One way to address the issue in H3 would be to change to , and let the server use the error code ( as an argument of the RESET_STREAM frame ) to indicate that the response has been " cancelled " . Originally proposed in 
 What if you do not want to admit to being a proxy ? ( who does ? ) 
 HTTPMESSAGECANCELLED would simply mean that the transfer of the response is cancelled , regardless of the server being an origin or a reverse proxy . 
 I can get behind this . As long as we 're not looking for a byte - by - byte reproduction of the bytes the intermediary received ( as was once requested and rejected , I think at the Seattle interim ) , then it makes sense to signal that the message was killed . 
 This is basically an expansion of the CANCELLED / REJECTED codes to allow a server to do either . WFM . 
 Yes . And thank you for the PR .
Paragraph (version A):
Since the server could be blocked until more packets are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgement for one of its Handshake or 1-RTT packets.
Paragraph (version B):
Since the server could be blocked until more packets are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgement for one of its Handshake or 1-RTT packets, and has
not received a HANDSHAKE_DONE frame.