Re: NEW ISSUE: Define "ought to"

[Eliot Lear <[e-mail]>]

On 7/31/13 10:02 AM, Willy Tarreau wrote:
> 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.
>

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

And now let's look at what RFC-2119 says about SHOULD:

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

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