I guess many people already know my feeling about RFC compliance by now. I'll restate it in context; if we are going to support interoperability with broken and non-compliant systems this must be made available as a configuration option and preferably OFF as default.
To add support for non-compliant systems as default behaviour is to condone non-compliance. Condoning non-compliance devalues the standard and leads to the existence of an undocumented de-facto standard which is very much harder to research, implement, and test. It raises the bar to effective new implementations of the system. I favour pragmatically providing the option to support broken systems, but only in such a way that it is apparent to admins that they are moving outside the published standard behaviour, and requires an assertive action on their part. Published standards are possibly the single most important precursor to open source network software, as can be witnessed by Microsoft's policy of extending and obfuscating standards as described in the halloween documents, and I can quote: "Generally, Microsoft wins by attacking the core weaknesses of OSS projects. De-commoditize protocols & applications OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market. David Stutz makes a very good point: in competing with Microsoft's level of desktop integration, "commodity protocols actually become the means of integration" for OSS projects. There is a large amount of IQ being expended in various IETF working groups which are quickly creating the architectural model for integration for these OSS projects. "[1] This is a political rant on behalf of open source software everywhere, thank you for listening :-) d. [1] http://www.opensource.org/halloween/halloween1.php > -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > Sent: 21 July 2003 12:37 > To: James Users List > Subject: Re: Why does James reject email addresses with "_" in the > hostname? > > > Sheldon Hearn wrote: > > It's all very well boasting strict RFC conformance in an academic > > environment, but there aren't many business managers willing to accept > > "Well, your correspondants must fix their mail server" for a significant > > number of their correspondants. > > > > And anyway, the spirit of interpretation for RFCs should always be "Be > > conservative with what you send and liberal with what you accept". > > +1 > > -- > Serge Knystautas > President > Lokitech >> software . strategy . design >> http://www.lokitech.com/ > p. 1.301.656.5501 > e. [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
