Robert Sparks <> Wed, 25 June 2008 21:51 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id CF7B33A68D4; Wed, 25 Jun 2008 14:51:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B97763A6829 for <>; Wed, 25 Jun 2008 14:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.056
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9qpFT2e4dOrG for <>; Wed, 25 Jun 2008 14:51:07 -0700 (PDT)
Received: from (unknown [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id E6ACE3A67CC for <>; Wed, 25 Jun 2008 14:51:02 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id m5PLowNb023551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Wed, 25 Jun 2008 16:50:58 -0500 (CDT) (envelope-from
Message-Id: <>
From: Robert Sparks <>
To: IETF Discussion <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: SHOULD vs MUST
Date: Wed, 25 Jun 2008 16:50:58 -0500
References: <> <> <> <> <> <g3ror8$2b9$> <> <> <2D990430F5F5D3C7984BDFDF@p3.JCK.COM> <>
X-Mailer: Apple Mail (2.924)
Received-SPF: pass ( is authenticated by a trusted mechanism)
X-Virus-Scanned: ClamAV 0.93.1/7564/Wed Jun 25 14:36:46 2008 on
X-Virus-Status: Clean
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"

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.


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