Dave Cridland <> Thu, 26 June 2008 18:17 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BE7D83A6AED; Thu, 26 Jun 2008 11:17:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66FC93A6933 for <>; Thu, 26 Jun 2008 11:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6qAFrqHMoqU4 for <>; Thu, 26 Jun 2008 11:17:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 027933A68EA for <>; Thu, 26 Jun 2008 11:17:10 -0700 (PDT)
Received: from ([]) by (submission) via TCP with ESMTPA id <> for <>; Wed, 25 Jun 2008 08:58:39 +0100
Subject: Re: SHOULD vs MUST
References: <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <>
Date: Wed, 25 Jun 2008 08:58:35 +0100
From: Dave Cridland <>
To: IETF Discussion <>
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"

On Wed Jun 25 08:30:14 2008, Iljitsch van Beijnum wrote:
> Also note the difference between the two sides in a client-server   
> protocol. I recently used SHOULD where I would have liked to use  
> MUST  but existing clients don't conform to the MUST so I used  
> SHOULD to  indicate that servers must support clients that don't  
> have the feature.

Yes, the problem being that older client implementations otherwise  
become cast into non-conformancy.

I think we should be biting the bullet and doing so, however -  
otherwise we risk having the old behaviour used in new  
implementations more than it would be otherwise. The primary reason  
for doing the behaviour you describe is a kind of political  
correctness, and introduces a political-SHOULD I'm not sure I care  

A phrasing like:

Clients MUST send bar; however implementations based on an earlier  
revision of this specification are known to send foo, and therefore  
servers MUST accept foo without error.

both casts these old clients into the oblivion of non-conformancy,  
but also firmly establishes who to blame - ie, the specification and  
not the implementation.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
IETF mailing list