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

Use SHOULD .. can rather than MAY #4602

Merged
merged 1 commit into from Jan 7, 2021
Merged

Use SHOULD .. can rather than MAY #4602

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
View file
Open in desktop
Expand Up @@ -800,7 +800,7 @@ any outstanding data is declared lost, the endpoint SHOULD send a RESET_STREAM
frame instead of retransmitting the data.

An endpoint SHOULD copy the error code from the STOP_SENDING frame to the
RESET_STREAM frame it sends, but MAY use any application error code. An
RESET_STREAM frame it sends, but can use any application error code. An
Comment on lines 802 to +803
Copy link
Contributor

Choose a reason for hiding this comment

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

Drop the "but can..." -- it's not necessary

Copy link
Contributor

Choose a reason for hiding this comment

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

My point here is that removing the MAY is ok, but the semantics are different. "can" is a statement of fact, and it's not necessary to say that an an endpoint can send any error code in addition to what it SHOULD do. Though I don't feel strongly.

If the can is to be retained, I'd suggest flipping the primary and secondary clauses -- "can use any error code, but SHOULD copy"

endpoint that sends a STOP_SENDING frame MAY ignore the error code in
any RESET_STREAM frames subsequently received for that stream.

Expand Down Expand Up @@ -2705,7 +2705,7 @@ Once the server has completed its path validation and has received a non-probing
packet with a new largest packet number on its preferred address, the server
begins sending non-probing packets to the client exclusively from its preferred
IP address. It SHOULD drop packets for this connection received on the old IP
address, but MAY continue to process delayed packets.
address, but can continue to process delayed packets.
Comment on lines 2707 to +2708
Copy link
Contributor

Choose a reason for hiding this comment

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

This is badly written -- the SHOULD and the MAY apply to different packets. How about:
"The server SHOULD drop newer packets for this connection that are received on the old IP address. The server MAY continue to process older delayed packets that are received on the old IP address."

Copy link
Member Author

Choose a reason for hiding this comment

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

Please make a separate issue and pull request for this. I agree that this is a better formulation.


The addresses that a server provides in the preferred_address transport
parameter are only valid for the connection in which they are provided. A
Expand Down