Codify how handshake failures are written down

[martinthomson]

There's a bunch of places where we want to recommend that the handshake fails. We need an editorial convention for how to write that down, which should include any error codes and messages that are sent at the same time.

[martinthomson]

@MikeBishop has already adopted the convention from HTTP/2 in #131.

"MUST be treated as a (connection|stream) error of type ."

We just need a section describing what a connection or stream error is. That belongs in the transport draft. We should wait for #131 before doing that though. We can close this issue when that is in place (not when every place we need an error code is fixed, that might take some time to work out properly).

[martinduke]

Lastly, I'm not sure if this is a separate issue, but I would like to see some language here, or in the loss recovery document, about client actions when the first handshake message is lost. We have overloaded this loss signal with multiple meanings/responses:

(1) Retransmit (due to garden-variety network loss)
(2) Change MTU and retransmit (due to MTU problems, though we might see ICMP here?)
(3) Failover to TCP (middleboxes eating QUIC)
(4) Give up (path failure)

If I were implementing a client using these documents, I am not sure how I would handle a CHLO loss given these conflicting imperatives. I could accept having SHOULDs instead of MUSTs, but there ought to be something.

[ianswett]

Agreed, that should be in there. I think that belongs in the loss recovery doc. Want to a file a specific issue to fix that, since it seems somewhat orthogonal to the type of handshake failure this issue was intended to discuss.

[martinduke]

Will do.

[martinthomson]

Closed by #374.