Aaron. Well made point, which I totally disagree with :-)
> IMHO, this view is incorrect. It is not the business of the JAMES > development community to attempt to be the RFC police of the SMTP world. I believe it is up to every developer implementing a published standard to be their own policeman. I have no responsibility to support un-documented non-standard behaviour propogated by others. If everyone opens up the standard a little, to make things easier, what value does the standard have anymore? None. In that situation to obtain interoperability you can no longer simply implement a standard, you will have to carry out research to determine the de-fact standard in use and implement a million crazy non-standard behaviours to cope with each and every different application you wish to offer interoperability with. As far as I am concerned (I'm not talking for anyone else here) I don't want to be party to that. Open source and the freedom of the internet relies for much of its existence on standards, and I'm not going to undermine it. If a particular web-browser has a buggy implementation of http should we encourage server developers to change their good product, or, by not doing so reflect the problem back where it belongs, the browser manufacturer? Perhaps we can fall back to an older, or less fully featured standard protocol if we encouter it, but not break the rules to protect someone elses hack. > If people want to write cheap hacks to meet a goal, who are we to say > (without any knowledge of the circumstances) that their particular > situation does not warrant the tradeoff? Not. But the chaep hack can only be expected to interoperate reliably if it correctly implements the standard. > The goal of any development team should be to make their app as useful > and robust as possible. Robustness is about dealing with errors in such > a way that service is still provided in the most adverse conditions > possible. This includes resource shortages/outages and also spec > violations. I agree with this in as far as it covers inadvertent and genuine error conditions, but not simply to support non-compliant interoperation. > There are a large number of widely used mail clients and servers out > there that are in violation of spec (though maybe not this particular > issue). If that is the case then they obviously don't violate it in way that causes much harm, or they would never have got off the starting blocks. I don't see why you expect James developers to encourage this. > If we carry this attitude when dealing with them, then JAMES > will have problems talking to them. This will make JAMES less useful. No it will make them less useful. James implements protocols per the published standard, which is, by definition available to anyone to read and implement. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
