On Thu, 6 Oct 2005, Tim Mooney wrote:
In conclusion, the problem is with the the entity that generated that From
address, not with c-client.
I'm not disagreeing, but what about being "... generous in what you
accept"?
My position is:
This argument is based upon a terrible misunderstanding of Jon Postel's
robustness principle: "be liberal in what you accept, be conservative in
what you generate."
I knew Jon personally. Although I can't speak for Jon, and sadly Jon is
no longer with us, I am confident that he never intended it to be used in
cases like this.
Jon's point was that ARPAnet (later Internet) protocols had many
facilities, but only a subset of these facilities were commonly used.
This had caused interoperability problems when one implementation depended
upon a facility that another implementation did not implement. TELNET,
FTP, and the early email protocols suffered greatly from such problems.
Thus, "be conservative" by eschewing the facilities that aren't commonly
used; but "be liberal" by implementing all the facilities described in the
base specification even if they seem silly/useless/meaningless.
As an example of the Postel Principle, it was perfectly reasonable in RFCs
733 and 822 to have a From header looking like:
From: Joe Mooch <(personal) joe (mooch) @ (company) example.com >
The c-client library (and hence Pine) is liberal and will interpret it
correctly as being equivalent to:
From: Joe Mooch <[EMAIL PROTECTED]>
but many other MUAs will not!
Incidentally, RFC 2822 threw in the towel and outlawed sending the former.
So, there is no longer a stated need for MUAs to "be liberal" and accept
that form. But some MUAs still do so out of respect for the past.
The abuse of the Postel Principle is its extension to "be liberal" by
accepting out-of-specification protocol, even in those cases when the
situation has always been explicitly prohibited by the specification.
This abuse encourages the practice of browbeating standards-compliant
implementations to be non-compliant because some other implementation is
non-compliant: "blurdybloop works with it, so your software is broken."
It also creates long-term interoperability problems; nobody really knows
what the standard is. A new implementor can not implement from the
specification because much of the standard is in folklore that is not in
any written specification.
It also causes harm. Over the past 30 years, we've had numerous sad
examples in which correct protocol was "repaired" into bogusity by
well-intentioned software that incorrectly thought "it didn't really mean
that, it meant this other thing, I'll fix it." Email protocols in
particular have suffered greatly because of this problem, which was
largely brought on by the lack of rigor in the early specifications.
The IMAP protocol's strict syntax rules were a reaction to this problem.
IMAP tries very hard to have just One Right Way That Everybody Must Obey.
It occasionally has faltered in enforcement; and goodness knows people
have complained about IMAP being so strict. Nevertheless IMAP has had
much better interoperability than had previously existed in email
protocols.
There is a lot of software that generates QP incorrectly in some cases;
it would be really nice if c-client (and pine, by extension) would work
around the deficiences of that other software -- assuming it's not
terribly onerous to do so.
In my opinion, it is onerous for the following reasons:
1) (Multiple) slippery slope argument(s):
a) standard undocumented in any specification
b) repetitive fixing of bad effects of previous fixes
c) "you did that, so you should do this too"... :-(
d) etc.
2) It introduces a bug: valid, standard-compliant data *will* be
misinterpreted, and when that happens, the aggrieved party will
rightfully say that it's c-client's fault.
3) It's additional work; doing this means that the code can no longer use
the rule, explicitly stated in RFC 2047, that an encoded-word is an
RFC 2822 atom.
Your mileage may vary... :-)
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
