Re: SHOULD vs MUST

Scott Brim <swb@employees.org> Wed, 25 June 2008 17:03 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 EEEDF3A69C2; Wed, 25 Jun 2008 10:03:02 -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 5498E3A6A34 for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 10:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 5lv4pyTbU+YY for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 10:03:00 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3B26D3A68B7 for <ietf@ietf.org>; Wed, 25 Jun 2008 10:03:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,703,1204520400"; d="scan'208";a="12219345"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Jun 2008 13:03:00 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5PH2xaF032166; Wed, 25 Jun 2008 13:02:59 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5PH2x57013365; Wed, 25 Jun 2008 17:02:59 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 13:02:59 -0400
Received: from sbrim-mbp.local ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 13:02:59 -0400
Message-ID: <48627A42.6030907@employees.org>
Date: Wed, 25 Jun 2008 13:02:58 -0400
From: Scott Brim <swb@employees.org>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
Subject: Re: SHOULD vs MUST
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>
In-Reply-To: <2D990430F5F5D3C7984BDFDF@p3.JCK.COM>
X-OriginalArrivalTime: 25 Jun 2008 17:02:59.0461 (UTC) FILETIME=[522D3B50:01C8D6E5]
Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral
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"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 6/25/08 8:24 AM, John C Klensin allegedly wrote:
> 
> --On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
> <swb@employees.org>; wrote:
>> ... 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.


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

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.

There's no way we should have strict process rules about this.  The IETF 
has enough rules as it is.  However, explanations of SHOULDs do make 
better standards.  The point is to give guidance to implementors.  I did 
an informal survey last year and found that some implementors treat 
every SHOULD as a MUST, but more of them just treat a SHOULD as a MAY, 
essentially to be ignored.  An explanation of the circumstances 
surrounding a SHOULD will lead to a lot more consistency in 
implementation.  Many SHOULDs in RFCs are because there are old 
implementations that need to be taken into account, or because some 
capability isn't widely possible yet but will be within the lifetime of 
the standard.  If a MUST becomes a SHOULD to take that into account, and 
you explain it, your chances of getting rid of non-MUST-capable 
implementations eventually goes up tremendously.  So, to reiterate, when 
you're writing the draft if something is not a MUST, ask yourself "why 
not?" and write down your answer.


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