Re: Comments on Malformed Message BCP draft

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