Avoid ambiguity with "may not" and a "MAY" requirement #66
Conversation
RFC 2119 defines "MAY" as a keyword, which may cause confusion with "may not", even though the latter is not uppercased. This hopefully better clarifies that the server in question may or may not be an origin server, as opposed to implying that origin servers are prevented from returning a 451 response status.
|
I re-wrapped the content to 80 characters after making this change, although I'm happy to undo that if the diff noise is unwelcome. I also would be glad to go with a different choice of wording if there's something more preferable. |
|
Sounds good to me. |
|
Out of curiosity, why this was closed? |
|
because the RFC has been published. |
|
Actually, it has been approved but not published, and this is a change that could be done during AUTH48 (a minimal change would be "may" -> "might"). |
|
@timbray, thoughts? I think this is editors' discretion (although historically we do try to avoid using RFC2119 keywords in this manner). |
|
Happy to resubmit a PR with the change, unless @timbray or someone else would just make that small modification. |
|
I think this can be considered to be resolved due to the changes in f36fb4a. |
RFC 2119 defines "MAY" as a keyword, which may cause confusion with "may not", even though the latter is not uppercased.
This hopefully better clarifies that the server in question may or may not be an origin server, as opposed to implying that origin servers are prevented from returning a 451 response status.