On Fri, 13 Jun 1997, Keith Moore wrote:
I don't think the UTF-8 requirement is reasonable.
It seems like this would impose a huge implementation burden for most UAs.
With this requirement in place, most people can't use it or benefit
from it. Without this requirement, many users could just add a header
field to outgoing mail specifying the languages and charsets that the
user can deal with, without needing UTF-8 support.
I disagree with this point. UTF-8 is not particularly hard to support --
It would require a huge effort to take every tool that I use to
process mail, and extend them all to use UTF-8. This remains true
even if I only care about supporting the 8859/1 subset.
(in my case, we're talking MH, exmh, metamail, xterm, procmail,
/bin/mail, and numerous scripts)
We need to start "hooking" UTF-8 to proposals like this so that we can
transition away from the current mess of character sets we have.
I strongly disagree. I want to encouage a transition to UTF-8, but
not by "hooking" it to what would otherwise be a very simple and
useful extension, and not in such a way that it would have a severe
adverse impact on the installed base.
We haven't yet recovered from the 822-to-MIME transition. The vast
majority of mailers out there can't yet deal with it adequately.
(They may have some support for it, but in general it seems to be
lousy.) To raise the bar further at this point would not encourage
adoption of UTF-8, it would just degrade interoperability. Some tools
would ignore the UTF-8 requirement and generate accept-language
anyway; other tools would use this as an excuse to send UTF-8 to those
in the first set and thus annoy the user. Many tools would implement
UTF-8 poorly (just as they have implemented MIME poorly) and this
would be an additional source of user complaints.
Neither is it reasonable for every UA that sends messages, to assume
that the reply will be read (or processed) by a UA with the same
capabilities. It might be reasonable to assume that it will be read
by the same *user*, but it's quite unreasonable to assume that the
message will be read by the same *tool*, or even on the same host.