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.

Sign up for GitHub

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

Jump to bottom

First tranche of EKR's editorial pass, through 7.3.2 #2087

Closed
wants to merge 5 commits into from
Closed

First tranche of EKR's editorial pass, through 7.3.2 #2087

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2fcfe3b
Punctuation
ekr Dec 1, 2018
c828c2d
You transition to Ready when the remote creates a bidirectional stream,
ekr Dec 1, 2018
29aef24
More clarifications
ekr Dec 1, 2018
a6d479e
Some more editorial cleanup and clarification
ekr Dec 1, 2018
fcf2016
Fix build error
ekr Dec 1, 2018
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
47 changes: 28 additions & 19 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,9 +124,9 @@ provides:

* Authenticated and encrypted header and payload

QUIC uses UDP as a substrate to avoid requiring changes in legacy client
QUIC uses UDP as a substrate to avoid requiring changes to legacy client
operating systems and middleboxes. QUIC authenticates all of its headers and
encrypts most of the data it exchanges, including its signaling, to avoid
encrypts most of the data it exchanges -- including its signaling -- to avoid
Copy link
Member

Choose a reason for hiding this comment

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

I hate em--dashes done this way.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do you mean you don't want to use em-dashes here or that you would like me to use some other typographical convention than --

Copy link
Contributor

Choose a reason for hiding this comment

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

We're using hyphens instead of em-dashes... I used to write em-dashes, but @martinthomson normalized it all to hyphens, so he'll have to explain :-)

That said, I think commas seem more appropriate here. Ultimately, I suspect the RFC-Editor will want to say something here.

Copy link
Member

Choose a reason for hiding this comment

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

This is just what I learned from Professor Schulzrinne. If we had real em-dashes, I'd use them, but the budget version is just bad.

incurring a dependency on middleboxes.


Expand Down Expand Up @@ -383,7 +383,7 @@ data to a peer.
~~~
o
| Create Stream (Sending)
| Create Bidirectional Stream (Receiving)
| Remote Creates Bidirectional Stream
Copy link
Member

Choose a reason for hiding this comment

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

s/Remote/peer

Copy link
Contributor

Choose a reason for hiding this comment

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

Change the text below as well, for transition from Ready to Send

v
+-------+
| Ready | Send RESET_STREAM
Expand Down Expand Up @@ -651,13 +651,14 @@ upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM
frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM
frame for that stream. An endpoint SHOULD copy the error code from the
STOP_SENDING frame, but MAY use any other application error code. The endpoint
STOP_SENDING frame, but MAY use any application error code. The endpoint
that sends a STOP_SENDING frame can ignore the error code carried in any
RESET_STREAM frame it receives.

If the STOP_SENDING frame is received on a send stream that is already in the
"Data Sent" state, a RESET_STREAM frame MAY still be sent in order to cancel
retransmissions of previously-sent STREAM frames.
"Data Sent" state, an endpoint which wishes to cease retransmission of
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
"Data Sent" state, an endpoint which wishes to cease retransmission of
"Data Sent" state, an endpoint that wishes to cease retransmission of

previously-sent STREAM frames on that stream MUST first send a RESET_STREAM
frame.

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"
Expand Down Expand Up @@ -834,7 +835,7 @@ commitment.
## Controlling Concurrency {#controlling-concurrency}

An endpoint limits the cumulative number of incoming streams a peer can open.
Only steams with a stream id less than
Only streams with a stream id less than
Copy link
Contributor

Choose a reason for hiding this comment

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

Capitalize ID while there?

(max_stream * 4 + initial_stream_id_for_type) can be opened. Initial limits
are set in the transport parameters (see {{transport-parameter-definitions}})
and subsequently limits are advertised using MAX_STREAMS frames
Expand Down Expand Up @@ -882,13 +883,13 @@ selected by endpoints; each endpoint selects the connection IDs that its peer
uses.

The primary function of a connection ID is to ensure that changes in addressing
at lower protocol layers (UDP, IP, and below) don't cause packets for a QUIC
at lower protocol layers (UDP, IP) don't cause packets for a QUIC
connection to be delivered to the wrong endpoint. Each endpoint selects
connection IDs using an implementation-specific (and perhaps
deployment-specific) method which will allow packets with that connection ID to
be routed back to the endpoint and identified by the endpoint upon receipt.

Connection IDs MUST NOT contain any information that can be used to correlate
Connection IDs MUST NOT contain any information that can be used by to correlate
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Connection IDs MUST NOT contain any information that can be used by to correlate
Connection IDs MUST NOT contain any information that can be used by an external observer to correlate

them with other connection IDs for the same connection. As a trivial example,
this means the same connection ID MUST NOT be issued more than once on the same
connection.
Expand Down Expand Up @@ -1190,8 +1191,9 @@ described in {{QUIC-TLS}}; a different QUIC version number could indicate that a
different cryptographic handshake protocol is in use.

QUIC provides reliable, ordered delivery of the cryptographic handshake
data. QUIC packet protection ensures confidentiality and integrity protection
that meets the requirements of the cryptographic handshake protocol:
data. QUIC packet protection is used to encrypt as much of the handshake
protocol as possible. The cryptographic handshake MUST provide the following
properties:

* authenticated key exchange, where

Expand Down Expand Up @@ -1337,7 +1339,8 @@ Source Connection IDs during the handshake.
On first receiving an Initial or Retry packet from the server, the client uses
the Source Connection ID supplied by the server as the Destination Connection ID
for subsequent packets. That means that a client might change the Destination
Connection ID twice during connection establishment. Once a client has received
Connection ID twice during connection establishment, once in response to a
Retry and once in response to the server's Initial. Once a client has received
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Retry and once in response to the server's Initial. Once a client has received
Retry and once in response to the server's Initial packet. Once a client has received

an Initial packet from the server, it MUST discard any packet it receives with a
different Source Connection ID.

Expand Down Expand Up @@ -1377,7 +1380,8 @@ of duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR.

A server MUST include the original_connection_id transport parameter
({{transport-parameter-definitions}}) if it sent a Retry packet.
({{transport-parameter-definitions}}) if it sent a Retry packet, in
order to enable validation of the Retry, as described in {{packet-retry}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

remove "in order"



### Values of Transport Parameters for 0-RTT {#zerortt-parameters}
Expand All @@ -1398,12 +1402,17 @@ A server MAY accept 0-RTT and subsequently provide different values for
transport parameters for use in the new connection. If 0-RTT data is accepted
by the server, the server MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data. In particular, a server
that accepts 0-RTT data MUST NOT set values for initial_max_data,
initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote,
initial_max_stream_data_uni, initial_max_streams_bidi, or
initial_max_streams_uni ({{transport-parameter-definitions}}) that are smaller
that accepts 0-RTT data MUST NOT set values for the following parameters
({{transport-parameter-definitions}}) that are smaller
than the remembered value of those parameters.

* initial_max_data
* initial_max_stream_data_bidi_local
* initial_max_stream_data_bidi_remote
* initial_max_stream_data_uni
* initial_max_streams_bidi
* initial_max_streams_uni

Omitting or setting a zero value for certain transport parameters can result in
0-RTT data being enabled, but not usable. The applicable subset of transport
parameters that permit sending of application data SHOULD be set to non-zero
Expand All @@ -1415,8 +1424,8 @@ The value of the server's previous preferred_address MUST NOT be used when
establishing a new connection; rather, the client should wait to observe the
server's new preferred_address value in the handshake.

A server MUST reject 0-RTT data or even abort a handshake if the implied values
for transport parameters cannot be supported.
A server MUST either reject 0-RTT data or abort a handshake if the implied
values for transport parameters cannot be supported.


### New Transport Parameters
Expand Down