Opened 9 years ago
Closed 9 years ago
#472 closed editorial (incorporated)
Misused SHOULDs
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 24 |
Component: | non-specific | Severity: | In WG Last Call |
Keywords: | Cc: |
Description
Reviewing the current specs, I think the following uses of SHOULD are invalid, and should be rewritten.
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")
Change History (4)
comment:1 Changed 9 years ago by mnot@…
comment:2 Changed 9 years ago by fielding@…
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
Removed, then rephrased previous requirement to be more explicit.
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)
SHOULD => ought to
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")
should not be published => are unsafe to publish
8.5 "minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information," (lowercase should; change to "ought")
should => ought to be
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")
SHOULD => ought to
5.3.2 "The example... SHOULD be interpreted as..." (requirement in an example; change to "can")
SHOULD be => is
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")
SHOULD => needs to
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")
SHOULD be => are presumed to be
comment:3 Changed 9 years ago by fielding@…
comment:4 Changed 9 years ago by fielding@…
- Milestone changed from unassigned to 24
- Resolution set to incorporated
- Status changed from new to closed
p6 done in [2250]