From: Terje Bless (link@pobox.com)
Date: Wed Mar 05 2003 - 12:09:57 CST
Russ Allbery <rra@stanford.edu> wrote:
>I'm saying that UTF-8 will still be, for that OS, an *encoding* that has
>to be undone. You're not actually getting to "just put the bits on the
>wire," which is the world that proponents of UTF-8 seem to believe that
>they're going to be living in. You still have to encode and decode the
>bits, at which point it's just as easy to use RFC 2047 as well.
No, the crucial difference between UTF-8 and RFC2047 in this regard is that
the grunt work of the encoding, normalization, etc., will be handled either
by the OS or by generic libraries for UTF-8 while RFC2047 will, at best, be
handled by special-purpose libraries for email and news or, at worst, be
doomed to be reimplemented by each newsreader author.
Offhand, I can think of no less then four separate implementations for news
clients and not a single case where an implementation has been shared. And
three of the four have a common heritage from an open source newsreader!
And another very significant factor here is that after you've handled the
RFC2047 encoding, you'll _still_ have to do the Unicode bit if you want to
be able to handle i18n properly. Unless in among outlawing "8bit" UTF-8 in
headers we also end up outlawing the sending of RFC2047-encoded UTF-8...
-- Now Playing "Highway To Hell" by "AC/DC"", from the album "Highway To Hell".