Re: SHOULD vs MUST

Fred Baker <fred@cisco.com> Wed, 25 June 2008 12:54 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D43428C161; Wed, 25 Jun 2008 05:54:03 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8D328C15B for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 05:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9Btuw9LdIzy for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 05:54:00 -0700 (PDT)
Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id E45973A69EC for <ietf@ietf.org>; Wed, 25 Jun 2008 05:53:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,702,1204482600"; d="scan'208";a="9451563"
Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-2.cisco.com with ESMTP; 25 Jun 2008 18:23:59 +0530
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5PCrxMR026696; Wed, 25 Jun 2008 20:53:59 +0800
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PCrx00016181; Wed, 25 Jun 2008 12:53:59 GMT
Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 20:46:19 +0800
Received: from [58.32.232.132] ([10.70.231.144]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 20:46:18 +0800
Message-Id: <5F870CB0-73C5-4E5D-BFB3-A09BB98B3991@cisco.com>
From: Fred Baker <fred@cisco.com>
To: John C Klensin <john-ietf@jck.com>
In-Reply-To: <2D990430F5F5D3C7984BDFDF@p3.JCK.COM>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: SHOULD vs MUST
Date: Wed, 25 Jun 2008 20:46:13 +0800
References: <20080525020040.4DE5A5081A@romeo.rtfm.com> <F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com> <20080620195947.29D0B5081A@romeo.rtfm.com> <9D9CF008-7350-4831-8F21-E08A0A7B255E@insensate.co.uk> <7706.1214216391.855029@peirce.dave.cridland.net> <g3ror8$2b9$1@ger.gmane.org> <900B2F8D-5960-4277-9DBC-E59A05F1CFBA@cisco.com> <48623304.1050008@employees.org> <2D990430F5F5D3C7984BDFDF@p3.JCK.COM>
X-Mailer: Apple Mail (2.924)
X-OriginalArrivalTime: 25 Jun 2008 12:46:18.0495 (UTC) FILETIME=[767C50F0:01C8D6C1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4684; t=1214398439; x=1215262439; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20Re=3A=20SHOULD=20vs=20MUST |Sender:=20; bh=FQz3gjA0w9BKFTfH0gcGigTuj0B17hrwGB5j85ZzKag=; b=q0OigSLH3hVLOuunQK2/9022j0P72TehGLiiQ3UQqClKMt4Dv2tSlcuSt1 Ur94HYIhf27b1GeypvGbHZyTyXiAEO34RtUfKmuOdXi6KrXLJ1H36i+lQ4Vk FEKZywJHmApEpdqMQaoCY77d75BLwfeLnYk1V/1l8POOdPxiLtJiQ=;
Authentication-Results: hkg-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; );
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I was about to write something like that to Scott; thanks for making  
it unnecessary.

My additional comment is that if there is some case I can think of  
that leads me to say "should", there might also be another that I  
didn't think of. Asking me to detail them all up front is IMHO asking  
too much. On the other hand, I wouldn't be at all bothered by being  
told that I had to justify a "must" - since in my mind it is something  
to be used when not doing the action has a predictable negative  
outcome, asking the author to say what that predictable negative  
outcome would be is reasonable.

My bottom line on a "should" is that if an implementer doesn't do what  
the specification says he "should", he should have a good reason and  
be prepared to explain it if questioned (for example by a customer or  
during an interoperability test). "I disagreed with the spec" is *not*  
a good reason, although it might be a good reason to implement it and  
provide a configuration knob that turned that functionality off,  
whatever it was.

On Jun 25, 2008, at 8:24 PM, John C Klensin wrote:

>
>
> --On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
> <swb@employees.org>; wrote:
>
>> On 6/25/08 5:37 AM, Fred Baker allegedly wrote:
>>>
>>> On Jun 25, 2008, at 5:28 AM, Frank Ellermann wrote:
>>>
>>>>> A SHOULD X unless Y essentially means "SHOULD (X or Y)"
>>>>
>>>> I'd read it as "do X, but if you have a very good excuse
>>>> not doing X might do.  One known very good excuse is Y."
>>>
>>> That is more or less my definition of "should". I say
>>> something "must"  be so when I can tell you an operational
>>> failure that would or could  happen if it isn't. If I would
>>> like to say "must" but can think of a  case in which it would
>>> not be appropriate I say "should", and am saying  that if it
>>> is not so in someone's implementation they should be prepared
>>> to say what their reason was.
>>
>> ... and draft authors should include explanations in their
>> drafts of the reasons an implementor might legitimately have
>> for not implementing the "should".  For example, an older
>> operating system that does not support a new capability.
>
> Scott,
>
> In principle, sure.  But I note that you use a lower-case
> "should" in the first sentence above and that, like the
> incremental promotion of "these are available" to "MUST unless
> you receive a dispensation", this could easily be turned into a
> firm requirement by someone who was being zealous about
> rule-making.
>
> Do you really mean, e.g.,
>
> 	... where feasible and, in the author's judgment,
> 	appropriate, it is desirable to include explanations or
> 	illustrations of the exception cases in drafts that use
> 	SHOULD.
>
> ???
>
> I've run into a number of situations over the years in which
> there are known edge cases that prevent a MUST but where those
> edge cases are rare and obscure enough that describing them
> would require extensive text... text that might indirectly end
> up providing guidance for bad behavior.   For those situations,
> I'd prefer to see something like:
>
> 	In all of the common cases, the system SHOULD...
>
> Rather than
>
>   The system SHOULD do A
>     unless Y, in which case B SHOULD be done
>     unless Z, in which case C SHOULD be done
>
> where each of X, Z, B, and C, might require a half-page
> explanation.
>
> That btw is part of the difficult with some of the discussion in
> this thread.  The discussion has, as I've read it, concentrated
> on
>
>   SHOULD do A unless Y
> and
>   SHOULD do A but may do B
>
> where it would often be useful to say
>
>   SHOULD do A unless Y and then SHOULD do B
>
> Note that the latter can often be rewritten as a MUST, e.g.,
>
> 	MUST do A unless condition Y occurs, in which case MUST
> 	do B
>
> I believe that good sense and discretion are important here.  I
> also believe that attempts to map case-by-case good sense into
> rules generally gets us into trouble and that such efforts
> should be examined carefully by the community.
>
> In addition, as Frank has noted, negative statements and words
> are often used quite differently than they are in English by
> languages that are otherwise reasonably similar to English.
> That calls for use of extreme care in use of negative statements
> in conformance clauses, a subject on which I would hope the RFC
> Editor (as well as authors and the IESG) would be very sensitive.
>
>    john
>
>
> _______________________________________________
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf