Ticket #426 (closed editorial: incorporated)
p2 editorial feedback
|Reported by:||firstname.lastname@example.org||Owned by:|
|Component:||p2-semantics||Severity:||Active WG Document|
3.1. Representation Metadata
| Expires | Section 7.3 of [Part6] |
If "Expires" is considered "representation metadata", then it seems like "ETag" and "Last-Modified" should be as well. But I think it would make more sense to just remove "Expires" from the list; it's clearly the odd man out here.
184.108.40.206. Character Encodings (charset)
Implementers need to be aware of IETF character set requirements [RFC3629] [RFC2277].
It's not clear what requirements this is referring to; RFC 2277 places requirements on protocol authors, not on implementors, and RFC 3629 is just the definition of UTF-8. If the requirement is "implementations MUST support UTF-8" then we should say that.
220.127.116.11. Multipart Types
In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does not use the multipart boundary as an indicator of message body length. In all other respects, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type.
That last part seems completely wrong; a web browser is not expected to handle multipart/alternative or multipart/related in the way a mail reader would. (This requirement came from RFC 2616, but... it was wrong then too.)
The MIME header fields within each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics.
This is not true of multipart/byteranges; in RFC 2616 that was explained separately, but that explanation got lost in httpbis rewrites at some point.
Suggested rewrite for the second and third paragraphs:
In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (Appendix A of [Part5]) when it appears in a 206 (Partial Content) response. In all other cases, the MIME header fields within each body-part of a multipart message body do not have any significance at the HTTP level; they are just part of the representation data.
(This drops the newly-added "HTTP does not use the multipart boundary as an indicator of message body length", but that is already implied by the removal of 2616's prohibition on epilogue data; if the multipart is allowed to have an epilogue, then the final boundary doesn't indicate the end of the body anyway. It also drops the "unrecognized multipart subtype" text, which was already irrelevant given the "strictly as payload" rule anyway.)
18.104.22.168. Language Tags
In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series of subtags:
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
Kinda weird... the text sets you up to expect an actual grammar for language-tag, but then you just get a cross-reference. I'd rearrange stuff to:
... HTTP uses language tags within the Accept-Language and Content-Language fields.
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
A language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series of subtags. White space is not allowed within the tag and all tags are case-insensitive. Example tags include:
en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information.
(also dropping the language-subtag-registry ref, since that's covered by the "See [RFC5646]")
3.4. Content Negotiation
(such as when many different formats are supported by a user-agent),
3.4.1. Proactive Negotiation
If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive negotiation.
That text doesn't motivate the new name. How about:
If the selection of the best representation for a response is made by the server based on preferences indicated by the user agent in its initial request for the resource, it is called proactive negotiation.
- It might limit a public cache's ability to use the same response
for multiple user's requests.
users' not user's
For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
Not clear what "them" is. "...that doesn't conform to the user agent's preferences..."
3.4.2. Reactive Negotiation
This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using proactive negotiation.
406 doesn't really "enable reactive negotiation". It just fails to do proactive negotiation.
Also, should we mention how reactive negotiation is *actually* done?
This specification defines the 300 (Multiple Choices) status code for enabling reactive negotiation. However, in practice, Web sites wanting to do reactive negotiation will just return a successful response containing a "default" (or proactively negotiated) representation of the resource, which includes within it links that the user can follow to reach other representations.
- Product Tokens
By convention, the products are listed in order of their significance for identifying the application.
"...in *decreasing* order of...", or something like that. (likewise in the description of User-Agent in 6.5.3 and Server in 8.4.2)
5.2.2. Idempotent Methods
Section 22.214.171.124 of Part1 implies that the concept of "idempotent sequences of request methods" (as opposed to merely "idempotent methods") will be discussed here, but it's not. I'm not sure if it should be added here or there.
The semantics of the GET method change to a "partial GET" if the request message includes a Range header field ([Part5]).
"a Range or If-Range header field"
Though obvious, it seems like for consistency's sake, this should end with:
Responses to the CONNECT method are not cacheable.
If no payload body is included, the response MUST include a Content-Length field with a field-value of "0".
Does this actually mean to prohibit servers from using chunked encoding (or "Connection: close" with no Content-Length) in that case? Or is it just supposed to be a reminder that "empty message body" is different from "no message body"?
(Section 9.1.2 has basically the same text.)
If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.
"If no Max-Forwards field is present in the upstream request, then the downstream request MUST NOT include a Max-Forwards field."
The HTTP/1.1 conditional request mechanisms are defined in [Part4].
"and [Part5]" (If-Range)
6.3. Content Negotiation
6.1 and 6.2 had some introductory text before the table, and it seems weird to not have that here.
(6.4 and 6.5 have the same problem)
6.3.1. Quality Values
Should this section be called "Weight" now?
would mean: "I prefer Danish, but will accept British English and other types of English". (see also Section 2.3 of [RFC4647])
- Response Status Codes
The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request.
"...a 3-digit integer code giving the result of the attempt..."
o 2xx (Successful): The action was successfully received,
understood, and accepted
"The *request* was successfully..."
7.1. Overview of Status Codes
The reason phrases listed here are only recommendations -- they can be replaced by local equivalents without affecting the protocol.
That suggests you can/should translate them into other languages, which isn't really what they're for and kind of contradicts p1 3.1.2's "A client SHOULD ignore the reason-phrase content."
| 415 | Unsupported Media Type | Section 7.5.13 | | 416 | Requested range not | Section 3.2 of | | | satisfiable | [Part5] | | 417 | Expectation Failed | Section 7.5.14 |
The capitalization of "Requested range not satisfiable" is inconsistent with the rest of the table.
7.2. Informational 1xx
A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message.
No reason to call out 100 Continue specifically here... "A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect one."
7.3.2. 201 Created
If the newly created resource's URI is the same as the Effective Request URI, this information can be omitted
"effective request URI" is not capitalized like that anywhere else. (Well, except for once more later on in this section which should also be fixed.)
If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.
"with *a* 202 (Accepted) response"
- If the response status code is 100 (Continue) or 101 (Switching
Protocols), the response MAY include a Date header field, at the server's option.
Is that really supposed to be limited to 100 and 101, and not other 1xx codes?
This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait
No hyphen in "user agent"
Allow = #method
Should that be 1#method? If not, it should explain what an empty "Allow" header means.
HTTP method registrations MUST include the following fields:
Should "cacheability" be an explicit field (rather than just a required part of the specification text)?
9.3. Header Field Registry
It seems weird to have this in p2 since p1 defines headers too...
9.3.1. Considerations for New Header Fields
o Whether it is appropriate to list the field-name in the Connection
header field (i.e., if the header field is to be hop-by-hop, see Section 6.1 of [Part1]).
should have a semicolon rather than comma after "hop-by-hop". (So that it doesn't read like it's telling you to only follow the xref if the header field is hop-by-hop.)
10.1. Transfer of Sensitive Information
Four header fields are worth special mention in this context: Server, Via, Referer and From.
"Via" is in p1 though, so the Via bits should be moved to p1's Security Considerations? (Or maybe if we end up with a p0, all of the security considerations should be consolidated there.)
The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it SHOULD NOT be transmitted without the user being able to disable, enable, and modify the contents of the field. The user MUST be able to set the contents of this field within a user preference or application defaults configuration.
Do any browsers actually ever send the "From" header? If not, should we just say "From is for robots, not browsers"?
Appendix C. Changes from RFC 2616
Remove base URI setting semantics for "Content-Location" due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (Section 126.96.36.199)
That would parse better if the "which was..." clause was parenthesized rather than just set off by commas.
Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the user agent is able to make that determination based on the request method semantics.
This is written in the opposite style from the rest of the list (it describes the problem with 2616 rather than the solution in httpbis). Should be something like:
Allow automatic redirection of all "safe" methods, not just GET and HEAD, and give the user agent more latitude in redirecting unsafe methods. (Section 7.4)
comment:12 Changed 2 years ago by email@example.com
- Status changed from new to closed
- Resolution set to incorporated