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

Fix grammar in 3.2. Receiving Stream States #2830

Conversation

monkey-mas
Copy link
Contributor

The phrase, Before creating a stream, all streams of the same type with lower-numbered stream IDs MUST be created., is semantically equal to Before all streams (of the same type with lower-numbered stream IDs) create a stream, all streams of the same type with lower-numbered stream IDs MUST be created.

This is not correct since all streams don't create a (new) stream. Moreover, by definition, a stream is created by sending data[1] or STREAM frames implicitly create a stream[2]. This indicates a stream itself doesn't create another stream.

[1] https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-2
[2] https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-19.8

@@ -526,7 +526,7 @@ an unopened stream indicates that the remote peer no longer wishes to receive
data on this stream. Either frame might arrive before a STREAM or
STREAM_DATA_BLOCKED frame if packets are lost or reordered.

Before creating a stream, all streams of the same type with lower-numbered
Before a new stream is created, all streams of the same type with lower-numbered
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we don't have to clearly say "new".

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I don't think we need "new" in the sentence.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! Fixed it.

Copy link
Member

@nibanks nibanks left a comment

Choose a reason for hiding this comment

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

Looks good. Just a minor comment.

@@ -526,7 +526,7 @@ an unopened stream indicates that the remote peer no longer wishes to receive
data on this stream. Either frame might arrive before a STREAM or
STREAM_DATA_BLOCKED frame if packets are lost or reordered.

Before creating a stream, all streams of the same type with lower-numbered
Before a new stream is created, all streams of the same type with lower-numbered
Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I don't think we need "new" in the sentence.

@monkey-mas monkey-mas force-pushed the fix-grammar-in-3-2-ReceivingStreamStates branch from 0ca7bee to ff1698f Compare June 23, 2019 21:07
The phrase, `Before creating a stream, all streams of the same type with lower-numbered stream IDs MUST be created.`, is semantically equal to `Before all streams (of the same type with lower-numbered stream IDs) create a stream, all streams of the same type with lower-numbered stream IDs MUST be created.`

This is not correct since all streams don't create a (new) stream. Moreover, by definition, a stream is created by sending data[1] or STREAM frames implicitly create a stream[2]. This indicates a stream itself doesn't create another stream.

[1] https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-2
[2] https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-19.8
@martinthomson martinthomson merged commit 4d38e6f into quicwg:master Jun 24, 2019
@martinthomson martinthomson added -transport editorial An issue that does not affect the design of the protocol; does not require consensus. labels Jun 24, 2019
@monkey-mas monkey-mas deleted the fix-grammar-in-3-2-ReceivingStreamStates branch June 24, 2019 04:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants