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 (-semantics) #870
Conversation
| field line value is "Baz". The field value for "Example-Field" is a list | ||
| with three members: "Foo", "Bar", and "Baz". | ||
| field line value is "Baz". The field value for "Example-Field" is the list | ||
| "Foo, Bar, Baz". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Giving an example of the actual list structure as it appears on the wire seems more useful to me than enumerating the list members individually.
| @@ -4740,7 +4744,8 @@ Content-Encoding: gzip | |||
| <t> | |||
| An origin server &SHOULD; verify that the PUT representation is | |||
| consistent with any constraints the server has for the target | |||
| resource that cannot or will not be changed by the PUT. This is | |||
| resource, in that the constraints cannot or will not be changed | |||
| by the PUT. This is | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels weird to me for there to be "constraints" that sometimes constrain the acceptable input and sometimes can be modified by the input -- the latter doesn't feel like much of a "constraint".
| for within <x:ref>Vary</x:ref> where it means the variance is unlimited. | ||
| not explicitly mentioned in the field are considered unacceptable. | ||
| Within <x:ref>Vary</x:ref>, the wildcard value means that the variance | ||
| is unlimited. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check this one; I was inferring that the "except" matches up to the "most" in the previous sentence.
| @@ -8373,7 +8379,7 @@ Content-Range: exampleunit 11.2-14.3/25 | |||
| though an origin server &MAY; generate content of zero length. | |||
| If no content is desired, an origin server ought to send | |||
| <x:dfn>204 (No Content)</x:dfn> instead. | |||
| For CONNECT, no content is allowed because the successful result is a | |||
| For CONNECT, there is no content because the successful result is a | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"no content is allowed" can parse as "the situation where there is no content is a permitted situation" or as "it is forbidden/impossible to have content". I propose this rewording because this is not an arbitrary restriction but rather an inherent property of how connect works.
| @@ -8548,7 +8554,8 @@ Content-Range: exampleunit 11.2-14.3/25 | |||
| selected representation's complete length. | |||
| </t> | |||
| <t> | |||
| A sender that generates a 206 response with an <x:ref>If-Range</x:ref> | |||
| A sender that generates a 206 response for a request with | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not see anything to suggest that If-Range is usable as a response header, so made some inference here.
| @@ -9830,9 +9837,9 @@ Content-Type: text/plain | |||
| </t> | |||
| <t> | |||
| The definition of a new status code ought to specify whether or not it is | |||
| cacheable. Note that all status codes can be cached if the response they | |||
| heuristically cacheable. Note that all status codes can be cached if the response they | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"heuristically cacheable" is the phrasing used in Section 15.1, so this was just an attempt to increase consistency.
|
closing so that this can be done in #899 |
There's a range of stuff in here, from simple typo fixes to attempts to reword places that I found confusing; the latter may need additional work in order to be correct and acceptable.