Aaron, > *Interoperability Rule Number One:* Be strict in what you send and > lenient in what you accept.
Ok. I don't agree. :) It's partially this sort of thinking that had led to huge chunks of modern browsers being devoted to parsing invalid HTML. My proposed counter rule is this: Be strict in what you send and knowledgeable about what you accept. That is, it's ok to deviate from specification when you know why you're deviating. If you're just deviating to accept random input, then all you do is weaken the specification. Clients (or servers) that don't follow the specification have no real reason to improve, and bugs in those clients and servers are harder to catch when they're deployed. Moreover, design and architectural decisions for the server become far more wishy-washy, because now you've got to accept random deviations that may or may not be important. There's no documentation of exactly which problems are real, and which were dreamed up by developers making up test cases. The software becomes brittle. Badly so, as there are constraints on the software that are ill-defined and probably poorly understood by the group. > Peter M. Goldstein wrote: > > > It makes it possible to write applets that are in > > violation of spec. Which is a good reason to not > > support the "functionality". > > > 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. > 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? Because that's what standards are. They are specifically designed to draw this line. That's also why most RFCs explicitly discuss the leniency vs. strictness issues. They detail the areas where commonly used clients are in violation. And they discuss some of the tradeoffs involved in supporting those clients. As far as being the RFC police, that's just hyperbole. If someone has a client that has some incompatibility with James, they can bring up the specific client/server that is having the issue. Again, there's no problem making a specific deviation for a specific client. What I object to is arbitrary deviations without cause. > 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. Sorry, I disagree with this definition. The goal of a robust app is to provide the service that has been contracted. I certainly agree that dealing with errors is extremely important - I simply don't agree that dealing with errors means that you try and figure out under arbitrary circumstances what the client wants and go do it. Taken to its logical extreme, it implies chaos. For example, let's say a client sends out of order MAIL, RCPT, and DATA commands. Shouldn't we be handling that by sending the message? I mean all the necessary information has been provided. So why not? Doesn't my unhappy client have a right to complain? > 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 we carry this attitude when dealing with them, then JAMES > will have problems talking to them. This will make JAMES less useful. Ok. Find me one widely-used application that has this problem. Adding the ability to deal with specific violations of the RFC on a case by case basis is valuable. You can make rational judgments and tradeoffs, potentially communicate with the development group behind the spec violating client, > I think that Serge's issue should be fixed, assuming that it can be done > without putting us in violation of the spec ourselves. (Post 2.1 > release, of course.) See my other emails about my opinion as to the correct way to resolve this issue. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
