Subject: NEW ISSUE: Define "ought to"

From: cowwoc <[email-masked]>
Date: Tue, 30 Jul 2013 11:18:41 -0400

Hi,

     According to 
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0183.html:

The WG practice has been to replace overly restrictive
SHOULD with a phrase that lacks the normative strictness while still
conveying some importance for the instruction - "ought to".

     I'd like to propose explicitly defining "ought to" alongside 
"SHOULD" because it is not clear what the practical difference is 
between the two. "ought to" is actually a synonym of "should", see 
http://thesaurus.com/browse/ought+to and http://thesaurus.com/browse/should

     It seems that you meant for "ought to" to lie somewhere between 
"MAY" and "SHOULD" but I don't think you're gaining anything by not 
defining exactly what it means, especially for people whose English is 
not their first language.

     Please consider:

 1. Replacing "ought to" with a word that is not a synonym of SHOULD,
    unless you mean SHOULD in which case you should use SHOULD :)
 2. Defining "ought to" explicitly at the top of the document.

Thank you :)
Gili

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Jul 2013 17:29:57 +0200

>  2. Defining "ought to" explicitly at the top of the document.

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.

Best regards, Julian

---

From: cowwoc <[email-masked]>
Date: Tue, 30 Jul 2013 12:03:42 -0400

> English sounds absolutely right to me.

Julian,

     I understand the "legal" difference between the two but your reply 
didn't actually explain the benefit of using "ought to" instead of 
"SHOULD" (especially in light of the fact that the former causes confusion).

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 30 Jul 2013 12:12:44 -0400

On 30/07/2013 12:08 PM, Julian Reschke wrote:
> On 2013-07-30 18:03, cowwoc wrote:
>> Julian,
>>
> The reason we don't use SHOULD is that BCP14 keywords SHOULD be used 
> sparingly:
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions) For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
>
> Best regards, Julian

     I understand this line of reasoning for MUST, but I fail to see the 
logic for SHOULD which by definition (being optional) does not "impose a 
particular method on implementers where the method is not required for 
interoperability".

     Are you looking for a way to say "this can be implemented one many 
ways, one approach is to X"?

Gili

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Jul 2013 20:47:42 +0200

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Jul 2013 20:59:25 +0200

> logic for SHOULD which by definition (being optional) does not "impose a

No, SHOULD is not "optional". MAY is optional.

> ways, one approach is to X"?

No, "ought to" means "should", we just want to avoid the confusion with 
a BCP14-SHOULD.

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Tue, 30 Jul 2013 19:43:51 +0000

If I'm following you correctly, this could be restated:

*         "MAY" - Strictly at your discretion based on what matters to you

*         "ought to" - Or your implementation will be less effective/efficient than it could be, without hurting anyone else

*         "SHOULD" - Or your implementation will cause peers / the network to suffer for your stupidity

*         "MUST" - Or you won't be able to interoperate with anyone

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 11:48 AM
To: cowwoc
Cc: [email-masked]
Subject: Re: NEW ISSUE: Define "ought to"

>      I understand the "legal" difference between the two but your

> reply didn't actually explain the benefit of using "ought to" instead

> of "SHOULD" (especially in light of the fact that the former causes

> confusion).

sparingly:

    interoperability.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Jul 2013 21:57:11 +0200

On 2013-07-30 21:43, Mike Bishop wrote:
> ·“MAY” – Strictly at your discretion based on what matters to you
>
> ·“ought to” – Or your implementation will be less effective/efficient
> than it could be, without hurting anyone else
>
> ·“SHOULD” – Or your implementation will cause peers / the network to
> suffer for your stupidity
>
> ·“MUST” – Or you won’t be able to interoperate with anyone

Almost. Violating an "ought to" may hurt others, jusr not in the way 
BCP14 says.

Best regards, Julian

---

From: cowwoc <[email-masked]>
Date: Tue, 30 Jul 2013 16:08:20 -0400

On 30/07/2013 2:59 PM, Julian Reschke wrote:
> No, "ought to" means "should", we just want to avoid the confusion 
> with a BCP14-SHOULD.
>
> Best regards, Julian

     My interpretation of "SHOULD" as defined by 
http://tools.ietf.org/html/bcp14 is that it is a combination of "MAY" 
and "RECOMMENDATION". Meaning, the reader is encouraged to do something, 
but may choose to do otherwise if understand the consequences of doing 
so. The definition says nothing about the reasons for the recommendation 
(whether they are related to interoperability or not).

     I argue that your (new) definition for "SHOULD" is not based on 
bcp14. If you wish to use it in this manner, I recommend providing your 
own definition which explicitly states that "SHOULD" relates to 
interoperability concerns and "should"/"ought to" mean the same thing 
but without reference to interoperability concerns. As it stands, the 
current document is unnecessarily confusing.

Gili

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Jul 2013 22:19:53 +0200

> and "RECOMMENDATION". Meaning, the reader is encouraged to do something,

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

...so should is a recommendation. MAY allows something.

> (whether they are related to interoperability or not).

Again, from RFC 2119:

> current document is unnecessarily confusing.

I believe we are using SHOULD exactly the way as described in Sections 3 
and 6 of RFC 2119.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 30 Jul 2013 23:45:57 +0200

Hi Julian,

On Tue, Jul 30, 2013 at 09:57:11PM +0200, Julian Reschke wrote:
> >·?MAY? ? Strictly at your discretion based on what matters to you
> >
> >·?ought to? ? Or your implementation will be less effective/efficient
> >·?SHOULD? ? Or your implementation will cause peers / the network to
> >·?MUST? ? Or you won?t be able to interoperate with anyone
> 

I'd say that "ought to" here in the HTTP spect is generally a good friend's
advice from some other implementors that got trapped and know how to avoid
this. There's nothing normative in what follows "ought to" so those who
won't follow it will not cause harm and might only suffer themselves.
SHOULD is a MUST with an exception if you know you can safely ignore it. 

Anyway the difference is quite clear to me, and really useful.

Willy

---

From: cowwoc <[email-masked]>
Date: Tue, 30 Jul 2013 18:02:56 -0400

Julian,

     Fair enough.

     Would you consider adding a brief paragraph to section 1.1 that 
explains this difference between "ought to" and SHOULD? Mike and Willy 
have provided some examples.

Kind Regards,
Gili

On 30/07/2013 4:19 PM, Julian Reschke wrote:
> I believe we are using SHOULD exactly the way as described in Sections 
> 3 and 6 of RFC 2119.
>
> Best regards, Julian
>

---

From: cowwoc <[email-masked]>
Date: Tue, 30 Jul 2013 18:08:41 -0400

> SHOULD is a MUST with an exception if you know you can safely ignore it.

     That is an excellent explanation. Please consider adding it to 
section 1.1.

Thanks,
Gili

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 31 Jul 2013 00:13:18 +0200

>     That is an excellent explanation. Please consider adding it to 

It is not needed in my opinion. All the spec is written in english (and
hopefully understandable english for non-native speakers). There are
provisions for a few keywords that are part of the norm which are defined
as possibly having a specific meaning. All the rest is purely english text,
so I don't see why we should clarify this point. Otherwise we'll have to
precise every word in the spec. It would not make sense either to say that
if we write "a server might receive a request with a body", the "might"
here would have to be clarified as being different from the normative one.
It's the same with "ought to" in my opinion, otherwise you're making a new
normative word of it, which will prevent us from naturally using it where
only the english sense is desired.

Hoping this helps,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 31 Jul 2013 06:09:40 +0200

> only the english sense is desired.

+1

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jul 2013 06:41:22 +0200

> 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.

Since this is a continuing issue in the IETF, Tony Hansen recruited me 
to work on a document to help folk:

    Non-Normative Synonyms in RFCs

    http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-02

In looking at this thread, I'm thinking we should take out the word 
'ought'...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 07:00:40 +0200

On 31 July 2013 06:41, Dave Crocker <[email-masked]> wrote:
> 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.

I believe that RFC 6919 covers a lot of this ground already.

---

From: cowwoc <[email-masked]>
Date: Wed, 31 Jul 2013 01:11:24 -0400

On 31/07/2013 12:41 AM, Dave Crocker wrote:
> 'ought'..

     +1 :)

Gili

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jul 2013 07:19:26 +0200

> I believe that RFC 6919 covers a lot of this ground already.

Alas, if only they'd meant the document seriously...

d/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 31 Jul 2013 09:50:44 +0200

> terms.  Cognitive separation will help the reader.

That's why we use "ought to", not "should".

> In looking at this thread, I'm thinking we should take out the word

Consider me confused :-). Why take it out?

Best regards, Julian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jul 2013 09:55:56 +0200

> 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...

> Consider me confused :-). Why take it out?

See above.

I think that the recommended(...) non-normative vocabulary should have 
substantial cognitive separation from the reserved, normative vocabulary.

This is a kind of information coding redundancy, to make it more likely 
that a reader will not think they've read something normative.

d/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 31 Jul 2013 10:02:56 +0200

> that a reader will not think they've read something normative.

Anyway it's not a big problem if they think they read something normative,
especially for confusion between should/SHOULD etc, since in the end, they
should do something for the better. So if they end up producing better
implementations, that's good for everyone. What is important is that poeple
who try to evaluate standard compliance are not confused. And when you're
doing this, you're pretty much aware of the difference in wording.

So in my opinion, this wording encourages everyone to follow the spec as
accurately as possible, and is non-ambiguous for those who want to be picky
about it.

Regards,
Willy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 31 Jul 2013 08:43:25 +0000

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

> 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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Jul 2013 10:50:18 +0200

> accurately as possible, and is non-ambiguous for those who want to be picky

There's a flipside here: use 2119 normative language when that's what
you really mean, and don't contort the text to avoid those words.  But
let's go to the video tape.  What does the actual text say?

>    The purpose of this value is to allow the initiating endpoint to
>    request that frames for the stream be processed with a specified
>    priority relative to other concurrently active streams.  That is, if
>    an endpoint receives interleaved frames for multiple streams, the
>    endpoint ought to make a best-effort attempt at processing frames for
>    higher priority streams before processing those for lower priority
>    streams.
>

>    carefully weighed before choosing a different course.

Let's add one more aspect: in other contexts of QoS "best effort" is
actually taken to mean the precise opposite.  And so I would
(re?)tighten the wording as follows:

>    The purpose of this value is to allow the initiating endpoint to
>    request that frames for the stream be processed with a specified
>    priority relative to other concurrently active streams.  That is, if
>    an endpoint receives interleaved frames for multiple streams, the
>    endpoint SHOULD process frames for
>    higher priority streams before processing those for lower priority
>    streams.

After all, that is why you have the feature in the protocol in the first
place.  There may be circumstances where an implementation can't process
a particular higher priority message first, but presumably there would
be a good reason for that.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Jul 2013 10:58:25 +0200

This is a *fascinating* thread, but until there's some general IETF consensus on such matters, I'm inclined to leave the decision about specific language in the hands of the editors; they've done well so far.

Regards,

---

From: Michael Sweet <[email-masked]>
Date: Wed, 31 Jul 2013 07:31:19 -0400

I have only one question for this: once it is published, do we list is as a normative reference or an informative one?

<ducking>

On 2013-07-31, at 12:41 AM, Dave Crocker <[email-masked]> wrote:

> 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.
> 
> Since this is a continuing issue in the IETF, Tony Hansen recruited me to work on a document to help folk:
> 
> In looking at this thread, I'm thinking we should take out the word 'ought'...
> 
> d/
> 
> 
> -- 
> Dave Crocker

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Jul 2013 15:44:04 +0200

> This is a *fascinating* thread, but until there's some general IETF consensus on such matters, I'm inclined to leave the decision about specific language in the hands of the editors; they've done w…

There is an IETF consensus on such matters.  It is RFC 2119.

Eliot

---

From: cowwoc <[email-masked]>
Date: Wed, 31 Jul 2013 10:47:18 -0400

If I understand you correctly, you agree with Yoav that:

> 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:

     If so, I agree with both of you.

Gili