Re: [quicwg/base-drafts] Inconsistency in STOP_SENDING requirements relative to resetting streams in general (#2884)

[mjoras <[e-mail]>]

> The application can implement this incorrectly.

The application can also incorrectly implement having its stream reset without notification, as is currently allowed by the spec. The spec as written IMO encourages confusing semantics with respect to STOP_SENDING, as it forces the transport to send the reset and leaves it up to the implementation to decide how and when it notifies the application.

> The application may be slow to process the STOP_SENDING, and in the meantime a lot of unnecessary data may be sent. Doing this at the transport layer allows immediate processing.

We don't need to be prescriptive in saying the application MUST handle it, i.e. we don't need to disallow transport implementations from responding to the STOP_SENDING without application input. I am suggesting that we not require that the transport be the one to do it. I don't see an advantage to allowing the application to take control of sending the reset if it wants to. 

> The application may also have delivered everything including FIN.

I don't see how this is a concern. For such cases either the application can still issue a reset for the stream, or the transport implementation can optionally take control of it and issue the reset itself.

-- 
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/2884#issuecomment-510149568