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

Minor mods to stream state machine text #988

Merged
merged 2 commits into from
Dec 6, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -3087,16 +3087,16 @@ state as a result of delayed delivery of packets.
### Bidirectional Stream States {#stream-bidi-states}

A bidirectional stream is composed of a send stream and a receive stream.
Implementations might present the state of the pair of streams as a composite of
the states of the pair of streams. The simplest model presents the stream as
Implementations may represent states of the bidirectional stream as composites
of send and receive stream states. The simplest model presents the stream as
"open" when either send or receive stream is in a non-terminal state and
"closed" when both send and receive streams are in a terminal state.

{{stream-bidi-mapping}} shows a more complex mapping of bidirectional stream
states that loosely correspond to the stream states in HTTP/2
{{?HTTP2=RFC7540}}. This shows that multiple states on send or receive streams
are mapped to the same composite state. Note that this is just one possibility
for such a mapping; thi mapping requires that data is acknowledged before the
for such a mapping; this mapping requires that data is acknowledged before the
transition to a "closed" or "half-closed" state.

| Send Stream | Receive Stream | Composite State |
Expand Down Expand Up @@ -3140,15 +3140,15 @@ STOP_SENDING frame is received on a send stream that is already in the "Data
Sent" state, a RST_STREAM frame MAY still be sent in order to cancel
retransmission of previously-sent STREAM frames.

STOP_SENDING can only be sent for a receive stream that has not been
STOP_SENDING SHOULD only be sent for a receive stream that has not been
reset. STOP_SENDING is most useful for streams in the "Recv" or "Size Known"
states.

An endpoint is expected to send another STOP_SENDING frame if a packet
containing the frame is lost. However, once either all stream data or a
RST_STREAM frame has been received for the stream - that is, the stream is in
any state other than "Recv" or "Size Known" - sending a STOP_SENDING frame is
unnecessary.
containing a previous STOP_SENDING is lost. However, once either all stream
data or a RST_STREAM frame has been received for the stream - that is, the
stream is in any state other than "Recv" or "Size Known" - sending a
STOP_SENDING frame is unnecessary.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Above you changed it so it's SHOULD. Should it be changed here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think of this as justification for why it's a SHOULD above, so I'd prefer to leave this text as is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHOULD doesn't make sense here.



## Stream Concurrency {#stream-concurrency}
Expand Down