Re: NEW ISSUE: Define "ought to"

Julian Reschke <julian.reschke@gmx.de> Tue, 30 July 2013 18:50 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6716B21E8093 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2013 11:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPo8O-9W-1ih for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2013 11:50:20 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7821E8089 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 30 Jul 2013 11:50:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1V4Ey8-0001h3-8Y for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Jul 2013 18:48:24 +0000
Resent-Date: Tue, 30 Jul 2013 18:48:24 +0000
Resent-Message-Id: <E1V4Ey8-0001h3-8Y@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1V4Exw-0001dx-NP for ietf-http-wg@listhub.w3.org; Tue, 30 Jul 2013 18:48:12 +0000
Received: from mout.gmx.net ([212.227.17.20]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1V4Exv-0001N1-DD for ietf-http-wg@w3.org; Tue, 30 Jul 2013 18:48:12 +0000
Received: from [192.168.2.117] ([93.217.107.159]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lz4KW-1U0VE10Wxc-014E2I for <ietf-http-wg@w3.org>; Tue, 30 Jul 2013 20:47:45 +0200
Message-ID: <51F80A4E.9040407@gmx.de>
Date: Tue, 30 Jul 2013 20:47:42 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: cowwoc <cowwoc@bbs.darktech.org>
CC: ietf-http-wg@w3.org
References: <51F7D951.3050204@bbs.darktech.org> <51F7DBF5.3030403@gmx.de> <51F7E3DE.4020804@bbs.darktech.org>
In-Reply-To: <51F7E3DE.4020804@bbs.darktech.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:w8J2CnoomWMp2Mqn1GZ702v3UgcidKOsz9IKL/hg6rfxlCSKAU4 eQNliEwwtJ5Xr7e6MKMW9eiIpHVq5oRTg93hxMnY93b37HUjLO/ai+EZQmZWxFtQIoX6l6J A+53p7IneCQWP6ECBsh/Sv96fzS8YSgHwWQWl7oygZofsJbrw/Jc5cM5CcStAc4SDldqJ9B LSguTzmv8HYfFWJWfFMbw==
Received-SPF: pass client-ip=212.227.17.20; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.437, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1V4Exv-0001N1-DD 7667b485c88c775f22b3186fecd221c5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: NEW ISSUE: Define "ought to"
Archived-At: <http://www.w3.org/mid/51F80A4E.9040407@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18983
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2013-07-30 18:03, cowwoc wrote:
> 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

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