Re: Streams after receiving GOAWAY

>I apologise, I wasn’t clear enough. You could have had this flow:
>
>Client: PREAMBLE + SETTINGS
>Server: SETTINGS + SETTINGS(ACK)
>Client: SETTINGS(ACK)
>Server: GOAWAY(last_stream_id=101)
>
>Any client that complies with RFC 7540 will see this GOAWAY and
immediately
>refuse to open further streams.

Which is a correct outcome, since the server wants to gracefully close the
connection, otherwise it wouldn't've sent the GOAWAY(no_error).

>In the above example, the server is acting incorrectly (last_stream_id
does
>not correspond to a stream it has even seen, let alone begun to process).

I get the feeling that you're not familiar with the graceful shutdown
language, or perhaps I haven't been clear.

"A server that is attempting to gracefully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream
identifier set to 2^31-1 and a NO_ERROR code.  This signals to the
client that a shutdown is imminent and 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."

> MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
definition
is an absolute prohibition of the specification.

I'm well aware of what a normative MUST NOT means, I'm arguing that it's
use
in this case is to strong (or to general) - in no small part because
violating
it is undetectable by the peer.