Opened 7 years ago

Closed 6 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 7 years ago by mnot@…

p6 done in [2250]

comment:2 Changed 6 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 6 years ago by fielding@…

From [2398]:

rephrase misused SHOULDs; addresses #472

comment:4 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 24
  • Resolution set to incorporated
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.