Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> writes:
I have always had the opinion that a good standard should
never contain the word "undefined". The word "undefined"
indicates that something is incomplete in the standard. And
when something is incomplete, different implementors will
do different things, and then interoperability will suffer.
I tend to agree in general, but I'm not sure this situation can be
counted as an "undefined" situation. The situation with bogus charset
is clearly in violation with the specification. What is undefined is
the error handling of this protocol violation. However, I believe
error handling of protocol violations is not within the scope of a
protocol to define. If a protocol isn't followed, it doesn't make
sense that the protocol has any say on what should or should not be
done. I believe it is best for a specification to describe how
conforming implementation should behave, and leave it at that.
However, perhaps your ideas could be formulated as a Best Current
Practice or similar, instead of adding them to the specification.
Btw, the error handling approach that Cyrus IMAPD implement for bogus
charset's, and which I like, is to simply (within charset=us-ascii
messages) replace all non-ASCII characters with 'X'. This is better
than bouncing the mail (which Cyrus IMAPD used to do), but still make
it clear to the user that some application is misbehaving. Modifying
the charset into charset=iso-8859-1 would be correct for 95 % of my
non-spam mail, but it would also hide the problem.
Thanks,
Simon