Fred Baker <> Wed, 25 June 2008 12:54 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 4D43428C161; Wed, 25 Jun 2008 05:54:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD8D328C15B for <>; Wed, 25 Jun 2008 05:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x9Btuw9LdIzy for <>; Wed, 25 Jun 2008 05:54:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E45973A69EC for <>; 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 ([]) by with ESMTP; 25 Jun 2008 18:23:59 +0530
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m5PCrxMR026696; Wed, 25 Jun 2008 20:53:59 +0800
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m5PCrx00016181; Wed, 25 Jun 2008 12:53:59 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 20:46:19 +0800
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 20:46:18 +0800
Message-Id: <>
From: Fred Baker <>
To: John C Klensin <>
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: <> <> <> <> <> <g3ror8$2b9$> <> <> <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;;; z=From:=20Fred=20Baker=20<> |Subject:=20Re=3A=20SHOULD=20vs=20MUST |Sender:=20; bh=FQz3gjA0w9BKFTfH0gcGigTuj0B17hrwGB5j85ZzKag=; b=q0OigSLH3hVLOuunQK2/9022j0P72TehGLiiQ3UQqClKMt4Dv2tSlcuSt1 Ur94HYIhf27b1GeypvGbHZyTyXiAEO34RtUfKmuOdXi6KrXLJ1H36i+lQ4Vk FEKZywJHmApEpdqMQaoCY77d75BLwfeLnYk1V/1l8POOdPxiLtJiQ=;
Authentication-Results: hkg-dkim-2;; dkim=pass ( sig from verified; );
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

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
> <> 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
> ???
> 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 mailing list