On Wed, 11 Jul 2001, Otto Stolz wrote:
> We'd like to offer a WWW interface for those users that cannot exploit
> our POP and (forthcoming) IMAP services, e. g., travelling users (you'll
> find a WWW browser virtually everywhere). We have tested three products,
> and all of them
> - talk to the client in ISO 8859-1,
> - expect input, including e-mail messages, in ISO 8859-1,
> - embed the incoming e-mail bytes in ISO 8859-1 encoded HTML forms,
> mercilessly ignoring the Charset argument of the MIME Content-Type
> header.
> Two of them even withdraw the mail when you manually change the browser's
> encoding, and fall back to the inbox view, effectively barring the user
> from viewing the incoming mail properly.
>
> So none of these WWW interfaces is able to handle mail from, or to,
> non-Western partners; not even Sorbian, a minority language in our
> own country, nor the languages of our neighbours, Polish and Czech,
> can be handeled. For a university, this lack of functionality is
> plainly intolerable.
I wish those in charge of web mail service at my school had
the same mindset for I18N and international student support as you do.
> Is there any software out there that does it right?
Maybe not right as you suggested (to which I certainly agree). However,
some web mail products appears to be better than what you described above.
For instance, the web mail service at my school (which I rarely use) doesn't
have this problem you mentioned:
> - embed the incoming e-mail bytes in ISO 8859-1 encoded HTML forms,
> mercilessly ignoring the Charset argument of the MIME Content-Type
> header
At least, if I manually change the encoding (in browser's View menu)
to the encoding of the message (e.g. EUC-KR for Korean), it displays
messages correctly (that is, it doesn't blindly convert all the octets
with MSB=1 to HTML/SGML entity names)
> There is a simple solution for this problem:
> - encode all forms and other texts of the interface software in Unicode,
> once and for all;
> - convert incoming mail to unicode;
> - talk to the browser in UTF-8;
> - accept input from the HTML forms in UTF-8;
> - send mail as is (in UTF-8), or convert outgoing mail to suitable 8-bit
> (or even 7-bit) encodings, the user should have an option to suggest
> the encoding for a particular message or addressee.
> But none of the WWW interface packages I have tried works this way.
I totally agree with you that this is simple enough. To the extent
that I agree with you, I'm also puzzled that I've never seen
any WebMail products (and/or services) that do this correctly.
Going all the way to Unicode has some drawbacks, though. You have
to take into account that some browsers don't support UTF-8 very well
and that Unicode terminal emulators are not as widely available as
non-Unicode terminal emulators (for legacy encodings). The latter point
is important because some people may want/need to access their web mail
services using text-mode browsers like Lynx. Therefore, there should
be an option to let users work in the encoding of their choice. That
is, instead of converting incoming messages to Unicode and display in
UTF-8, users should be able to display them in their encoding of choice
or encoding specified in MIME charset parameter of Content-Type header
of messages. There is only one encoding in which most of users receive
emails. Those who receive emails in many different encodings are likely
to be pretty good at this kind of stuff and can do whatever necessary
to switch encodings (of terminal emulators or web browsers if switching
encoding is not automatic)
> Is there any e-mail provider who does it right?
> Or am I the only person to complain about this prevailing parochism
> in e-mail to WWW interfaces?
No, you're not the only person complaining about widespread lack
of understanding and support of MIME (in general) and UTF-8 and other
encodings in particular on the part of WebMail service providers. That's
why I don't use any of Web Mail services. Now, Yahoo, Hotmail, LycosMail
seem to be much better in those aspects than they were a few years ago
(when there's virtually no notion of I18N support in those services.
I should have launched my own business with this idea and made some
money :-) ) but still I think there are lots of improvement to be made.
Jungshik Shin
This archive was generated by hypermail 2.1.2 : Wed Jul 11 2001 - 16:20:40 EDT