Re: NEW ISSUE: Define "ought to"

[Yoav Nir <[e-mail]>]

On Jul 31, 2013, at 9:55 AM, Dave Crocker <[e-mail]> wrote:

> On 7/31/2013 9:50 AM, Julian Reschke wrote:
>> On 2013-07-31 06:41, Dave Crocker wrote:
>>> On 7/30/2013 5:29 PM, Julian Reschke wrote:
>>>> The point being that "ought to" being just prose, while "SHOULD" being
>>>> defined by RFC 2119. Both of them having roughly the same meaning in
>>>> English sounds absolutely right to me.
>>> 
>>> Well, the choice of non-normative vocabulary would do better to be for
>>> words and phrasing that are not too easily confused with the normative
>>> terms.  Cognitive separation will help the reader.
>> 
>> That's why we use "ought to", not "should".
> 
> My point about that is that reading the use, here, is causing me to suspect that it is "too close" to the normative term.  That is, it's too easy for the reader to misunderstand whether the text is or is not being normative.
> 
> To repeat: the issue isn't formal clarity; the language is entirely precise that it is /not/ normative.  The issue is potential readability concerns in a potentially wide audience.  It's a psych issue…

I don't think you can get around the psych issue. This is (or rather, will be) a standards document. The target audience will read this to get information on how to write an HTTP/2.0 implementation that works and interoperates with other implementations. It's a common trope in police drama on TV that the police officer makes small talk with the suspect, which only makes the suspect more nervous, because he's expecting interrogation. It's the same with standards. We expect them to tell us what to do. So for the reader, all of the following are equivalent:

 - the endpoint SHOULD make a best-effort attempt at processing frames for higher priority streams before processing those for lower priority streams.
 - the endpoint ought to make a best-effort attempt at processing frames for higher priority streams before processing those for lower priority streams.
 - the endpoint had better make a best-effort attempt at processing frames for higher priority streams before processing those for lower priority streams.
 - it would be a shame if the endpoint didn't make a best-effort attempt at processing frames for higher priority streams before processing those for lower priority streams.

I kind of like the last one best, as I can imagine it being said with a heavy accent by some organized crime boss, but for an implementer, they convey the same information, unless they're really pro RFC readers, in which case the SHOULD one has some slight extra meaning.

Yoav