Re: SHOULD vs MUST

John C Klensin <john-ietf@jck.com> Wed, 25 June 2008 12:24 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 ED15A3A6890; Wed, 25 Jun 2008 05:24:28 -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 82A583A6848 for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 05:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.051
X-Spam-Level: ***
X-Spam-Status: No, score=3.051 tagged_above=-999 required=5 tests=[AWL=5.650, BAYES_00=-2.599]
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 em-0n5xNP56W for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 05:24:26 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 46D323A67E3 for <ietf@ietf.org>; Wed, 25 Jun 2008 05:24:26 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KBU2w-000JUH-SB; Wed, 25 Jun 2008 08:24:23 -0400
Date: Wed, 25 Jun 2008 08:24:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Scott Brim <swb@employees.org>, IETF Discussion <ietf@ietf.org>
Subject: Re: SHOULD vs MUST
Message-ID: <2D990430F5F5D3C7984BDFDF@p3.JCK.COM>
In-Reply-To: <48623304.1050008@employees.org>
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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


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