Re: SHOULD vs MUST
Robert Sparks <rjsparks@nostrum.com> Wed, 25 June 2008 21:51 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 CF7B33A68D4; Wed, 25 Jun 2008 14:51:09 -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 B97763A6829 for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 14:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.056
X-Spam-Level:
X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, SPF_PASS=-0.001]
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 9qpFT2e4dOrG for <ietf@core3.amsl.com>; Wed, 25 Jun 2008 14:51:07 -0700 (PDT)
Received: from nostrum.com (unknown [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E6ACE3A67CC for <ietf@ietf.org>; Wed, 25 Jun 2008 14:51:02 -0700 (PDT)
Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m5PLowNb023551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ietf@ietf.org>; Wed, 25 Jun 2008 16:50:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-Id: <D18F4F45-E339-4E30-AF8E-BB562CF2661E@nostrum.com>
From: Robert Sparks <rjsparks@nostrum.com>
To: IETF Discussion <ietf@ietf.org>
In-Reply-To: <48627A42.6030907@employees.org>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: SHOULD vs MUST
Date: Wed, 25 Jun 2008 16:50:58 -0500
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> <48627A42.6030907@employees.org>
X-Mailer: Apple Mail (2.924)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
X-Virus-Scanned: ClamAV 0.93.1/7564/Wed Jun 25 14:36:46 2008 on shaman.nostrum.com
X-Virus-Status: Clean
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"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
fwiw - I have, for many SIPits (a rather large interop event for SIP implementations) worked to get the people writing code from these documents to understand that MUST means MUST and SHOULD means MUST ... (very long pause)... unless you _really_ know that not following the SHOULD won't result in very bad things. They typically respond with MUST means MUST unless they're sure they can get away without it most of the time, and that SHOULD means its in some future release that will get funding maybe someday. Some of that response is tongue-in-cheek - some of it isn't. I see a strong trend for unadorned SHOULDs to remain unimplemented. SHOULDs that have a very clear, and explicitly called out even when they seem incredibly obvious, explanation of the bad things that can happen if you don't follow them get implemented. So, at least for the documents I edit, I work really hard to explain the SHOULDs to help motivate the implementors to actually build things that conform to it. RjS On Jun 25, 2008, at 12:02 PM, Scott Brim wrote: > 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 _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Review of draft-ietf-geopriv-http-location-delive… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… Hannes Tschofenig
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… Hannes Tschofenig
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: [secdir] Review of draft-ietf-geopriv-http-lo… Richard Barnes
- RE: [Geopriv] [secdir] Review ofdraft-ietf-geopri… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Geopriv] Review of draft-ietf-geopriv-http-l… Eric Rescorla
- RE: [Geopriv] Review of draft-ietf-geopriv-http-l… Tschofenig, Hannes (NSN - FI/Espoo)
- RE: Review of draft-ietf-geopriv-http-location-de… Mary Barnes
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… TSG
- SHOULD vs MUST (was Re: Review of draft-ietf-geop… Lawrence Conroy
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Eric Rescorla
- RE: [Geopriv] Review of draft-ietf-geopriv-http-l… Dawson, Martin
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Dave Cridland
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Joe Abley
- Re: SHOULD vs MUST Frank Ellermann
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Iljitsch van Beijnum
- Re: SHOULD vs MUST Fred Baker
- Re: SHOULD vs MUST Scott Brim
- Re: SHOULD vs MUST John C Klensin
- Re: SHOULD vs MUST Fred Baker
- Re: SHOULD vs MUST Scott Brim
- Re: SHOULD vs MUST John C Klensin
- Re: SHOULD vs MUST Scott Brim
- Re: SHOULD vs MUST Dean Willis
- Re: SHOULD vs MUST Robert Sparks
- Re: SHOULD vs MUST Dave Crocker
- Re: SHOULD vs MUST Dave Cridland
- Re: SHOULD vs MUST Iljitsch van Beijnum
- SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST case sensitivity Eric Gray
- Re: SHOULD vs MUST case sensitivity Julian Reschke
- Re: SHOULD vs MUST case sensitivity Keith Moore
- SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST Eric Gray
- SHOULD vs MUST case sensitivity Dave Crocker
- Re: SHOULD vs MUST case sensitivity C. M. Heard
- Re: SHOULD vs MUST case sensitivity Iljitsch van Beijnum
- Re: SHOULD vs MUST case sensitivity Randy Presuhn
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- Re: SHOULD vs MUST case sensitivity Randy Presuhn
- Re: SHOULD vs MUST case sensitivity Keith Moore
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST case sensitivity Eric Gray
- Re: SHOULD vs MUST case sensitivity Spencer Dawkins
- Re: SHOULD vs MUST case sensitivity Ralph Droms
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST case sensitivity Hallam-Baker, Phillip
- Re: SHOULD vs MUST case sensitivity John Levine
- RE: SHOULD vs MUST case sensitivity Hallam-Baker, Phillip
- Re: SHOULD vs MUST case sensitivity John Leslie
- RE: Review of draft-ietf-geopriv-http-location-de… Mary Barnes