> I can't see how this hurts the product, and the RFC has already been 
> destroyed many times over by real-world implementations.  So
relatively, 
> I see any damage we're doing to the RFC at this point as
inconsequential. :)

This hurts the RFC because it helps the proliferation of
non-RFC-compliant clients. As it was explained before in the thread a
lot of programmers out there don't read RFCs and just "try it". When it
works they declare their work valid, even if the client they wrote is in
violation of the RFC.

The RFC being destroyed many times should actually make us more carefull
to any further damage and not the opposite like you're suggesting.
Otherwise it would mean that we consider the RFC as irrelevant!!

> At this point I'd weigh the behavior of sendmail, qmail, exchange, and
a 
> few others more highly than what the RFC states.

This is valid in that we have to ask ourself the question: 
 * Do we want a strictly RFC-compliant James (would help the RFC but
would break with poorly compliant clients) 
 * Do we want a loosely RFC-Compliant James (would work with more
clients but could generate under the hood problems and help
proliferation of non RFC compliant clients)

Of course the answer to that question is: both. And the real question is
what kind of tradeoff we want for this or that feature.

I think bad clients should be fixed, and it's definitely not the server
task to be lenient.

Lots of RFCs were broken like that. To take a simple example, let's see
what happened to the HTML RFC. IE would recognize tags that are not RFC
compliant and so web pages would proliferate with these invalid tag,
breaking more and more pages for other browsers. I don't think that the
good solution would be for all browsers to support all the HTML
extensions that IE does, as every web browser would become bloated with
under-the-hood hidden undocumented features that nobody cares about.
They're bloated enough like that ;-)

My .02
--pierre

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to