Transport API: Reset after FIN?

[MikeBishop]

#2857, requires transport stacks to support abrupt closure of a stream even after the stream has been cleanly closed. This reflects the possibility to transition from "Data Sent" (stream has ended) to "Reset Sent" by sending a RESET_STREAM. Based on the state diagram in the transport doc, if an implementation was already in the "Data Recvd" state, they wouldn't actually send a RESET_STREAM, as they're already in a terminal state; a reset call would be a no-op or an error of some kind.

However, @mikkelfj points out that in a handle-based API, this essentially means that handles for closed streams have to be recognizable as such for the lifetime of the connection. This might be burdensome for some implementations.

Should we reword the requirement here to say that it's permitted if the stream hasn't yet reached the "Data Recvd" state.

[martinthomson]

This was clearly just a miss on the wording. I don't think that the intent was ever to require that streams be kept around indefinitely. Sure, some stacks might be able to send RESET_STREAM at a whim, but it's not necessary