Subject: [quicwg/base-drafts] Clarify send state behavior for peer-created bidi stream (#2636)

From: Andy Grover <[email-masked]>
Date: Fri, 19 Apr 2019 13:14:37 -0700

>From -transport section 3.1:

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

The event causing transition Ready->Send is the host initially having data to send on the stream, which is not the case when the receiving part has just been created in its initial Recv state. I think the send stream should stay in Ready until it does. This also aligns better with similar text in 3.2.

I suggest:

> The sending part of a bidirectional stream initiated by a peer (type 0 for a server, type 1 for a client) starts in the “Ready” state.

p.s. see also #2357, but which is more about being explicit about frames that cause stream creation... rather than this issue, which is about the state the new sending part starts in.

-- 
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/2636