From 8e34d7d088bbfa9a47cfaad20c226d0183ee9cfb Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 24 Aug 2017 13:59:38 +1000 Subject: [PATCH] RST_STREAM doesn't demand another RST_STREAM in response The rest of the text seems OK, but this is a bit we missed in #171. --- draft-ietf-quic-transport.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ed6f0666bc..1bee212f4d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1597,10 +1597,9 @@ octet that identifies the frame as a PADDING frame. An endpoint may use a RST_STREAM frame (type=0x01) to abruptly terminate a stream. -After sending a RST_STREAM, an endpoint ceases transmission of STREAM frames on -the identified stream. A receiver of RST_STREAM can discard any data that it -already received on that stream. An endpoint sends a RST_STREAM in response to -a RST_STREAM unless the stream is already closed. +After sending a RST_STREAM, an endpoint ceases transmission and retransmission +of STREAM frames on the identified stream. A receiver of RST_STREAM can discard +any data that it already received on that stream. The RST_STREAM frame is as follows: