Re: [apps-discuss] Comments on Malformed Message BCP draft

Peter Koch <pk@DENIC.DE> Sat, 16 April 2011 17:54 UTC

Return-Path: <peter@denic.de>
X-Original-To: apps-discuss@ietfc.amsl.com
Delivered-To: apps-discuss@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26754E0689 for <apps-discuss@ietfc.amsl.com>; Sat, 16 Apr 2011 10:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.803
X-Spam-Level:
X-Spam-Status: No, score=-6.803 tagged_above=-999 required=5 tests=[AWL=1.446, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxuLywNumYm4 for <apps-discuss@ietfc.amsl.com>; Sat, 16 Apr 2011 10:54:51 -0700 (PDT)
Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by ietfc.amsl.com (Postfix) with ESMTP id 4101FE0681 for <apps-discuss@ietf.org>; Sat, 16 Apr 2011 10:54:50 -0700 (PDT)
Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QB9hp-0004RN-CZ; Sat, 16 Apr 2011 19:54:49 +0200
Received: from localhost by x27.adm.denic.de with local id 1QB9hp-00084b-6I; Sat, 16 Apr 2011 19:54:49 +0200
Date: Sat, 16 Apr 2011 19:54:49 +0200
From: Peter Koch <pk@DENIC.DE>
To: apps-discuss@ietf.org
Message-ID: <20110416175449.GR1366@x27.adm.denic.de>
Mail-Followup-To: apps-discuss@ietf.org, ietf-822@imc.org
References: <F5833273385BB34F99288B3648C4F06F1343319E22@EXCH-C2.corp.cloudmark.com> <CEDB17EC-80CE-49B5-91C1-FBCB0449BBA5@network-heretics.com> <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <62554BEB-8154-48D7-BEAF-40217AEEDB61@guppylake.com>
User-Agent: Mutt/1.4.2.3i
Sender: Peter Koch <peter@denic.de>
Cc: ietf-822@imc.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 17:54:52 -0000

On Sat, Apr 16, 2011 at 09:27:35AM +0100, Nathaniel Borenstein wrote:

> The generalization is clear:  the financial and business incentive is to deliver every message that you can possibly figure out how to deliver, so that your service doesn't appear "inferior" to customers who don't give a rat's rump about the details of standards compliance.

Sure, the same way taxis will speed to outperform their competitors striving
to improve their own customers' experience.  Something is wrong in this picture.
Standards are only partly about that customer experience, they are about
interoperability, security, scalability, and, at least back in the day, overall
architecture.  This theme fits painfully nicely into that IETF80 technical
plenary about the post standardization world and dominance of applications.

> I'm not sure why this came as such a surprise to me, as it is actually just another instance of Postel's Law.  Being liberal in what we accept means, in this case, accepting and delivering any message where we believe, with a high level of confidence, that the sender's intentions are clear despite its standards violations.

I believe the Robustness Principle has been abused and perverted for too
long now.  You can only be so liberal that you are still able to be conservative
on the emitting side. The problems in Murray's draft are with those cases where
the intent was not clear or not clear enough to allow or support that balance.

> However, if the IETF offered guidance on the least harmful way to do this, the odds are good that we would follow it.  And I think it would be better if vendors who felt the need to "fix" messages would at least be mutually consistent in how they fix them.

First, it is about interoperability issues, not an abstract "compliance", i.e.,
we're already in "following the rules by spirit rather than letter" space. 
Who can I as an operator file a bug report with when there is a standard that
says "A" rather than "B" and a BCP that says "well, you should really treat B,
which should not have happened, this way"?  If there's an ambiguity in the standard
that harms interoperability and/or poses security risks, shouldn't it be corrected
in the standard for that to be self consistent?

> That way we might not be exacerbating existing problems quite as much as Keith and other (myself included) fear.  And the senders of misformatted messages might eventually fix their code, if only to shut up the annoying warning messages.  -- Nathaniel

Or they'd add additional code to suppress these warnings and market that
as a feature?

-Peter