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

Editorial suggestions from Benjamin Kaduk's IESG review (-messaging) #872

Merged
merged 1 commit into from Jul 11, 2021

Conversation

kaduk
Copy link
Contributor

@kaduk kaduk commented Jun 17, 2021

No description provided.

@@ -644,6 +645,7 @@ GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
<sourcecode type="http-message">
CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com

</sourcecode>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The full request message, of course, includes the blank line to end the headers section.
Whether it is worth trying to be pedantically correct about this across all the <sourcecode> elements is not entirely clear, though, given that the presentation form of it is unlikely to show the blank line in a meaninful way.

&SHOULD; be treated as an error.
The compression codings do not define any parameters. The presence
of parameters with any of these compression codings &SHOULD; be treated
as an error.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

A similar statement appears for the chunked transfer coding, where "their presence" is disambiguated since only the parameters appear as a plural noun, with only the single coding being discussed.

@@ -2086,7 +2092,7 @@ Connection: close
<section title="Security Considerations" anchor="security.considerations">
<t>
This section is meant to inform developers, information providers, and
users of known security considerations relevant to HTTP message syntax
users about known security considerations relevant to HTTP message syntax
Copy link
Contributor Author

Choose a reason for hiding this comment

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

"inform ... users of X" can be ambiguous about whether it is "users of X" that are being informed, or that users are being informed of the information X, which in this case leads to a "garden path sentence".

@@ -2180,7 +2186,8 @@ Connection: close
<t>
Extensions to the protocol might be used to mitigate the risk of unwanted
modification of messages by intermediaries, even when the "https" scheme is
used. Integrity might be assured by using hash functions or digital
used. Integrity might be assured by using message authentication codes
or digital
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hash functions do not provide integrity protection in the face of modification of messages by intermediaries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants