Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grammar fixes to transport draft #1691

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions draft-ietf-quic-transport.md
Expand Up @@ -4214,7 +4214,7 @@ stream data to the application to be interrupted.
It is possible that all stream data is received when a RST_STREAM is received
(that is, from the "Data Recvd" state). Similarly, it is possible for remaining
stream data to arrive after receiving a RST_STREAM frame (the "Reset Recvd"
state). An implementation is able to manage this situation as they choose.
state). An implementation is able to manage this situation as it chooses.
Sending RST_STREAM means that an endpoint cannot guarantee delivery of stream
data; however there is no requirement that stream data not be delivered if a
RST_STREAM is received. An implementation MAY interrupt delivery of stream
Expand Down Expand Up @@ -4246,7 +4246,7 @@ STOP_SENDING frames ({{frame-stop-sending}}).

The receiver only sends MAX_STREAM_DATA in the "Recv" state. A receiver can
send STOP_SENDING in any state where it has not received a RST_STREAM frame;
that is states other than "Reset Recvd" or "Reset Read". However there is
that is states other than "Reset Recvd" or "Reset Read". However, there is
little value in sending a STOP_SENDING frame after all stream data has been
received in the "Data Recvd" state. A sender could receive these frames in any
state as a result of delayed delivery of packets.
Expand Down