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 (-semantics) #870

Closed
wants to merge 1 commit into from

Conversation

kaduk
Copy link
Contributor

@kaduk kaduk commented Jun 16, 2021

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.

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".
Copy link
Contributor Author

@kaduk kaduk Jun 16, 2021

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
Copy link
Contributor Author

@kaduk kaduk Jun 16, 2021

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.
Copy link
Contributor Author

@kaduk kaduk Jun 16, 2021

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
Copy link
Contributor Author

@kaduk kaduk Jun 16, 2021

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
Copy link
Contributor Author

@kaduk kaduk Jun 16, 2021

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
Copy link
Contributor Author

@kaduk kaduk Jun 16, 2021

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.

@kaduk kaduk changed the title Editorial suggestions from Benjamin Kaduk's IESG review Editorial suggestions from Benjamin Kaduk's IESG review (-semantics) Jun 16, 2021
@royfielding
Copy link
Member

@royfielding royfielding commented Jul 11, 2021

closing so that this can be done in #899

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