W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

WGLC: misused SHOULDs

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 30 Apr 2013 11:39:45 +1000
Message-Id: <C77D12C2-A8C4-4648-9486-AC692F138490@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
Reviewing the current specs, I think the following uses of SHOULD are invalid, and should be rewritten.

Please have a look through; barring objections, we'll treat this as editorial.

P1
--

* 3.5 "In other words, if a server is reading the protocol stream at the beginning of a message and receives a CRLF first, the server SHOULD ignore the CRLF."  <--- duplicate of previous requirement

* 8.3 "Recipients SHOULD carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability." (this is a requirement in Security Considerations, which we avoid elsewhere)

* 8.5 "As such, access traces that are keyed to a specific client should not be published even if the key is pseudonymous."  (lowercase should; change to "ought not")

* 8.5 "minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information,"  (lowercase should; change to "ought")


P2
--

* 4.3.4 "For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server SHOULD do one of:"  (requirement in an example; change to "can")

* 5.3.2 "The example... SHOULD be interpreted as..."  (requirement in an example; change to "can")


P4
--

* 2.1 "However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server SHOULD incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior."  (change to "needs to")


P6
--

* 4.1.3 "These SHOULD be combined as..."  

* 4.1.4 "A cache shouldn't attempt to validate a response simply because that response became stale in transit." (lowercase shouldn't; change to "ought not")

* 4.2 "However, if any of the stored responses contains only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored response." (lowercase shouldn't; change to "ought not")


P7
--

* 4.1 "If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks)."  (is a statement of fact; change to "are valid")


--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 30 April 2013 01:40:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC