Re: [quicwg/base-drafts] First pass at REQUEST_RST (#171)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> -Since streams are bidirectional, a sender of a RST_STREAM needs to know how many
-bytes the peer has sent on the stream.  If an endpoint receives a RST_STREAM
-frame and has sent neither a FIN nor a RST_STREAM, it MUST send a RST_STREAM in
-response, bearing the offset of the last byte sent on this stream as the final
-offset.
+RST_STREAM terminates a stream abruptly.  Whether any action or response can
+or should be taken on the data already received is an application-specific
+issue.  If the sender of a RST_STREAM wishes to explicitly state that no future
+data will be processed, that endpoint MAY send a REQUEST_RST frame at the same
+time.
+
+Regardless, it will often be the case that upon receipt of a RST_STREAM, an
+endpoint will choose to stop sending data in its own direction. An endpoint that
+receives a RST_STREAM frame MUST still close the stream for sending in the other
+direction, either with a STREAM frame containing the FIN bit or a RST_STREAM
+frame of its own, but MAY choose not to do so immediately.

I meant it in the sense of it eventually will have to close, because all streams do in the end.  (For all streams are as grass, and all their transferred data as the flower of grass....)  But sure, we can incorporate the first sentence into the previous paragraph and drop the rest.

-- 
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/pull/171