Dave Crocker <> Thu, 26 June 2008 09:46 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5E4D43A692B; Thu, 26 Jun 2008 02:46:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12F553A67B7 for <>; Thu, 26 Jun 2008 02:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9lJVNOeuWIvg for <>; Thu, 26 Jun 2008 02:46:36 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:76:0:ffff:4834:7146]) by (Postfix) with ESMTP id BD2583A692B for <>; Thu, 26 Jun 2008 02:46:35 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m5PBgkBT003151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Wed, 25 Jun 2008 04:42:52 -0700
Message-ID: <>
Date: Wed, 25 Jun 2008 11:44:29 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: IETF Discussion <>
Subject: Re: SHOULD vs MUST
References: <> <> <> <> <> <g3ror8$2b9$> <> <> <2D990430F5F5D3C7984BDFDF@p3.JCK.COM> <>
In-Reply-To: <>
X-Virus-Scanned: ClamAV 0.92/7561/Wed Jun 25 09:20:43 2008 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 25 Jun 2008 04:42:52 -0700 (PDT)
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"

Scott Brim wrote:
> My rule of thumb is: when you're writing the draft if something is not a 
> MUST, ask yourself "why not?" and write down your answer.  You can be 
> brief but make it clear that the SHOULD is a MUST with exceptions.

This gets to an essential issue with IETF specification writing, as well as 
suggesting some of the distinction between MUST and SHOULD.

(By the way, I hope folks are clear that IETF use of these words as normative 
does not depend upon the case that is used?)

1. MUST is required if interoperability will otherwise be broken.  The spec does 
not offer any leeway to implementors.  Including rationale might be nice, but is 
not required.

2. SHOULD is used when there is a strong consensus that the specification's 
utility is greatly enhanced by having the SHOULD get implemented, but the 
specification is acknowledging that careful judgment by an implementor can 
produce cases in which it is acceptable not to implement it.

   The fact that a SHOULD explicitly calls for judgment by an implementor 
invites two things that we probably are not very consistent about delivering in 

    a) Why is it best to implement the SHOULD?  What is the nature of the 
benefit provided by the feature?  Often this is obvious, such as an additional 
and more powerful algorithm for a set of component security mechanisms.  Still, 
it makes sense to state this explicitly.

    b) What examples are there that would justify *not* implementing it?  For 
example, resource constraints, implementation simplicity, very tightly 
controlled execution environment?  Of course, the danger with listing examples 
is that folks might come to believe they are exhaustive...



   Dave Crocker
   Brandenburg InternetWorking
IETF mailing list