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

Clarify server CONNECTION_CLOSE with Handshake #2688

Merged
merged 14 commits into from Jun 18, 2019
7 changes: 7 additions & 0 deletions draft-ietf-quic-transport.md
Expand Up @@ -2304,6 +2304,13 @@ the application requests that the connection be closed. The application
protocol can use an CONNECTION_CLOSE frame with an appropriate error code to
signal closure.

When sending CONNECTION_CLOSE, the goal is to ensure that a peer will process
ianswett marked this conversation as resolved.
Show resolved Hide resolved
the frame. Generally, this means sending the frame in a packet with the highest
level of packet protection to avoid the packet being discarded. However, during
the handshake, it is possible that more advanced packet protection keys are not
available to a peer, so the frame MAY be replicated in a packet that uses a
ianswett marked this conversation as resolved.
Show resolved Hide resolved
lower packet protection level.
Copy link
Contributor

Choose a reason for hiding this comment

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

This paragraph doesn't really say anything that the next paragraph doesn't cover. Also, a peer sounds like an endpoint can have multiple peers.

Copy link
Contributor

Choose a reason for hiding this comment

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

I missed this earlier, but I agree. I'm fine with dropping this paragraph entirely. It seems like it's simply repeating what's in the next para, but in more general terms.

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 don't have a strong opinion, but I see your point, this was @martinthomson addition, so I'll let him comment.

Copy link
Member

Choose a reason for hiding this comment

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

The point was to articulate the principles behind the design. It might be that the mechanics are sufficiently precise that that is not necessary, but we did have #2151. @ianswett's changes didn't really directly address that.

Copy link
Member

Choose a reason for hiding this comment

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

If people want to fix this, please open a followup issue.


If the connection has been successfully established, endpoints MUST send any
ianswett marked this conversation as resolved.
Show resolved Hide resolved
CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a
peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames
Expand Down