Re: [quicwg/base-drafts] Split error code space (#722)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I haven't seen a review for #721 yet.  I apologize for stacking like this, but #721 is pretty self-contained, so the amount of leakage from that is small.  That said, I tried removing it from this changeset and found that a lot of the text is intertwined.  I've started stacking PRs differently now, so the reviewing should be easier.

> @@ -1596,7 +1622,7 @@ The RST_STREAM frame is as follows:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Stream ID (32)                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                        Error Code (32)                        |
+| App Protocol Error Code (16)  |

Yes, I must have split this from the other PR poorly.

>  
 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}}).

I considered not doing that, but it seemed more helpful to highlight the distinction here given that I wasn't repeating the format stuff in the description of APPLICATION_CLOSE.

> @@ -2608,11 +2654,10 @@ 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 with an error code of
-QUIC_RECEIVED_RST.  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.
+(remote)" states, an endpoint MUST send a RST_STREAM frame.  If the STOP_SENDING

Actually, the point here is that the *application* sends the RST_STREAM.  The transport can't send RST_STREAM.  The transport can't do that without risking putting the application into a bad state.  I will change this to make it clearer.

Actually, I'm going to raise this on the list.  It seems like STOP_SENDING could be made an application-layer construct and we could avoid that complexity at the transport layer entirely.  I'm trying to see how visibility at the transport layer would be of value, but I'm drawing a blank.

>  
-The portion of the QUIC error code space allocated for the crypto handshake is
-0xC0000000-0xFFFFFFFF. The following error codes are defined when TLS is used
-for the crypto handshake:
+This document defines error codes from the error code space used in
+{{QUIC-TRANSPORT}}.

The crypto handshake bit is on the very next line.  The point of separation is that the codes are consumed even if TLS isn't used.

>  
-An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the
-existence of the error to its peer.
+An endpoint that chooses not to retransmit packets containing TRANSPORT_CLOSE or
+APPLICATION_CLOSE risks a peer missing the first such packet.  The only

I'll remove this sentence, reword the remaining sentence, and merge.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/722#pullrequestreview-56237490