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

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

A few comments. This needs to be rebased and the resolution on the list will cause this to change further, I expect.

> @@ -844,7 +844,8 @@ explained in more detail as they are referenced later in the document.
 |:------------|:------------------|:----------------------------|
 | 0x00        | PADDING           | {{frame-padding}}           |
 | 0x01        | RST_STREAM        | {{frame-rst-stream}}        |
-| 0x02        | CONNECTION_CLOSE  | {{frame-connection-close}}  |
+| 0x02        | TRANSPORT_CLOSE   | {{frame-transport-close}}   |

I prefer connection close -- a connection is  a transport notion anyways. CONNECTION_CLOSE and APPLICATION_CLOSE ought to be clear enough, IMO.

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

nit: spell out "Application"

> @@ -1623,43 +1649,51 @@ Stream ID:
 
 : The 32-bit Stream ID of the stream being terminated.
 
-Error code:
+App Protocol Error Code:

ditto

>  
 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 would at least parenthesize it then.

> @@ -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

I understand, but there's an issue here. If the transport receives a STOP_SENDING and MUST send a RST_STREAM, there's nothing in here that requires the application to do something in between the receiving of the STOP_SENDING and sending of the RST_STREAM. If it's not a transport requirement to send a RST_STREAM, then the "MUST" doesn't belong here. So I would remove any mention of RST_STREAM being sent here; that's an application's prerogative. The transport does not need to ensure this.

That said, I think I'm with you on STOP_SENDING. It's an HTTP-ism, so it probably belongs in the application. I'll chime in on the list.

-- 
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-60777325