FIN + RST behavior

[Subodh Iyengar <[e-mail]>]

There might be some strange cases around RSTs and FINs which I would love more clarity on.

Let's say that the following actions happen:
1) Client initiates a stream to the server and sends some data
2) Server sends a FIN to the client which the client receives. The client and server are both half closed (remote and local respectively).
3) After some time the client sends a FIN to the server. So it's waiting for the FIN and the ack of all the data before closing the stream.
4) Server sends a RST which races with the client sending the FIN.
5) Client gets a RST

>From the draft I think it's ambiguous on what the client is supposed to do

"An endpoint that receives a RST_STREAM frame (and which has not sent a FIN or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUST NOT send any more data on the stream"

So clearly a client should not send a RST stream in response

However:
"When an endpoint sends a RST_STREAM frame, data outstanding on that stream SHOULD NOT be retransmitted, since subsequent data on this stream is expected to not be delivered by the receiver."

If the client decides to honor both of these requirements I believe it will not retransmit the FIN. So if the FIN gets lost the client will have no idea whether the server has seen the FIN and reduced its
number of streams counting towards the concurrency limit so that the client can open up a new stream. It would need to track the ACK of the ACK of the RST stream that the server sends back.

Am I missing another requirement that prevents this from being an issue or could "not sent a FIN" mean that "not sent a FIN that has been ACKed".

Subodh