Re: NEW ISSUE: Define "ought to"

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:
> On 2013-07-30 22:08, cowwoc wrote:
>> On 30/07/2013 2:59 PM, Julian Reschke wrote:
>>> On 2013-07-30 18:12, cowwoc wrote:
>>>>      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
>>>
>>> No, SHOULD is not "optional". MAY is optional.
>>>
>>>> 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"?
>>>
>>> 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,
>
> 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.
>
>> 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).
>
> Again, from RFC 2119:
>
>    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.
>
>
>>      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.
>
> I believe we are using SHOULD exactly the way as described in Sections 
> 3 and 6 of RFC 2119.
>
> Best regards, Julian
>

Received on Tuesday, 30 July 2013 22:03:28 UTC