Again, extremes and grey lines. See my previous post.
Cheers
ADK
Danny Angus wrote:
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
