Code change:
-1 and a code.  This signals to the client that a shutdown is imminent and <del> that no further requests can be initiated.  After waiting at least one round trip time, the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without losing requests. </del> <ins> that initiating further requests is prohibited.  After allowing time for any in flight stream creation - at least one round trip time - the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without causing clients to lose requests. </ins> After sending a GOAWAY frame, the sender can discard frames for <del> streams with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely ignored.  For instance, </del> <ins> streams initiated by the receiver with identifiers higher than the identified last stream.  However, any frames that alter connection state cannot be completely ignored.  For instance, </ins> ,

Related discussion:
text: After some sleep, I've read through the section and noticed a few other minor inconsistencies. This alters the structure slightly, as well as replacing the first sentence with a more accurate one. Supercedes . .
+1, thanks
LGTM
Merged by RFC editor.
We are working on a HTTP/2 library and we are a bit confused and we would like to get it right. Is it correct that after a sender sent a frame with some to a receiver, the sender may still open new streams, even with stream identifiers higher than the sent in the frame? That is the frame and the only limit the ability of the receiver? If this is correct, and I believe it is, then I find the following sentence in the first paragraph at confusing. In my opinion it should say something of the like Thanks.
I am also intersted in getting clarity on this topic. It seems what the "spirit" of the is something like: Each endpoint maintains the goaway last stream id from its peer. When a goaway is received then no local streams can be created (i.e. streams can only transition to ), and all local streams with > from the goaway frame are closed (or as the spec says ). Remote streams can still be opened, and to ensure a graceful connection shutdown a goaway frame should be sent in response.
Not quite: Upon receipt of GOAWAY, new streams can be created, but with the following restrictions: those with stream identifiers higher than the will be ignored. Those with stream identifiers lower or equal are subject to the usual risk of loss, but they might be processed. Success is determined by what happens on the stream, of course.
NAME - Can you clarify the following from : This is what lead me to believe that streams can not be "created" after receiving a ?
Hmm. I'd forgotten that. That is in conflict with the graceful shutdown we've specified. I think that we need to take this to the list. This seems like a genuine bug.
Thanks for the quick response NAME Would you prefer to bring the issue to the list?
I'm just trying to formulate something.
hmm I see NAME As a follow up, does the in the GOAWAY have to be the identifier of a stream that actually exists or could it also just be a "random number"?