From: Russ Allbery (rra@stanford.edu)
Date: Wed Mar 05 2003 - 01:59:00 CST
Terje Bless <link@pobox.com> writes:
> ...these aren't the only differences between UTF-8 and RFC2047. There is
> a -- real or imagined, it matters nought -- feeling that UTF-8 is just
> Yet Another Charset whilst RFC2047 is a Transfer Encoding Format.
Yeah, but see, this doesn't make any sense. It's just not true. And
whether this distinction is real or imagined *does* matter.
> RFC2047 won't go away; it's just that it's turned out to not adequately
> address the needs of a portion of the Netnews population.
When Stanford first rolled out AFS in 1992, it was very buggy. It had a
tendency to cause random system crashes and all sorts of other
instability. The CS department tried it on some of their systems and gave
up on it because it was a mess.
Five years later, when they were still not using AFS anywhere, people
occasionally asked why they weren't using AFS like the rest of campus so
that people could get at the same files. They said it was because it
caused all sorts of stability problems and crashed all the time. People
were a bit perplexed, since, well, it was working for everyone else. But
maybe CS had some special needs.
A few years later, when NFS became harder and harder to manage, people
started asking some more, and they started trying AFS on some systems. It
turned out to be pretty stable, and the systems didn't crash any more than
they did before. And there was a lot of stuff in AFS that they'd been
having to duplicate that they could now just use.
Now, they use NFS internally for some things, and AFS for most everything
else, and they're quite happy with it. But every once in a while, there
will still be someone who says that AFS is an obviously bad solution for a
central file system because it's horribly unstable and it crashes a lot.
Now, I mostly just shrug and go on with my life, and sooner or later
they'll either figure it out or they won't.
> UTF-8 is another tack; it may be rejected similarly to RFC2047, but it
> offers a way to achieve the interoperability that _users_ -- as opposed
> to Ivory Tower standards writers (I'm including myself in that
> characterization so please nobody get their panties in a bunch over it!
> ;D) -- care about.
Huh?
It's just another encoding.
> As regards your statement; yes, I do believe that Unicode will
> eventually be the native representation of all OSes and applications.
Unicode really doesn't have anything to do with this. Unicode isn't an
encoding, and therefore doesn't help. We can't "use Unicode." That
doesn't have any useful meaning.
The discussion isn't about Unicode. It's about UTF-8. Which is *not* the
native encoding of much of anything right now, although it's popular in
some Linux circles. (It's certainly not the native encoding of either
Java or of Windows.)
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>