Re: SHOULD vs MUST
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SHOULD vs MUST
On 6/25/08 8:24 AM, John C Klensin allegedly wrote:
--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
<swb at 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 authorFrom ietf-bounces at ietf.org Wed Jun 25 10:03:03 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at 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 at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5498E3A6A34
for <ietf at 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 at 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 at 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 at employees.org>
Date: Wed, 25 Jun 2008 13:02:58 -0400
From: Scott Brim <swb at employees.org>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: John C Klensin <john-ietf at jck.com>
Subject: Re: SHOULD vs MUST
References: <20080525020040.4DE5A5081A at romeo.rtfm.com>
<F66D7286825402429571678A16C2F5EE03ADF950 at zrc2hxm1.corp.nortel.com>
<20080620195947.29D0B5081A at romeo.rtfm.com>
<9D9CF008-7350-4831-8F21-E08A0A7B255E at insensate.co.uk>
<7706.1214216391.855029 at peirce.dave.cridland.net>
<g3ror8$2b9$1 at ger.gmane.org>
<900B2F8D-5960-4277-9DBC-E59A05F1CFBA at cisco.com>
<48623304.1050008 at employees.org>
<2D990430F5F5D3C7984BDFDF at p3.JCK.COM>
In-Reply-To: <2D990430F5F5D3C7984BDFDF at p3.JCK.COM>
X-OriginalArrivalTime: 25 Jun 2008 17:02:59.0461 (UTC)
FILETIME=[522D3B50:01C8D6E5]
Authentication-Results: rtp-dkim-1; header.From=swb at employees.org; dkim=neutral
Cc: IETF Discussion <ietf at ietf.org>
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at 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 at 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 judgm'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 at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ent,
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 at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
