Re: [quicwg/base-drafts] STOP_SENDING in Ready state (#1797)

[Mike Bishop <[e-mail]>]

Looking at the existing transitions....

> The sending part of a bidirectional stream initiated by a peer (type 0 for a server, type 1 for a client) enters the “Ready” state then immediately transitions to the “Send” state if the receiving part enters the “Recv” state (Section 3.2).

And in "Send," STOP_SENDING is valid.  So what causes the receiving part to enter "Recv"?

> The receiving part of a stream initiated by a peer (types 1 and 3 for a client, or 0 and 2 for a server) is created when the first STREAM, STREAM_DATA_BLOCKED, RESET_STREAM, or MAX_STREAM_DATA (bidirectional only, see below) is received for that stream. The initial state for a receive stream is “Recv”.

It's odd to say that STOP_SENDING causes a state change on the receive stream, but that's one way to formulate this.  It's evidence that the peer is starting to use this bidirectional stream, and is no more weird than a MAX_STREAM_DATA (which is similarly talking about the other stream direction).

Maybe STOP_SENDING needs to join the bidirectional-only category of frames that can open a stream in both directions.

-- 
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/issues/1797#issuecomment-439174620