Re: Backwards compatible
Claus Färber <list-ietf-wg-apps-usefor <at> faerber.muc.de>
2002-09-01 23:50:00 GMT
Erland Sommarskog <sommar-usefor <at> algonet.se> schrieb/wrote:
> Thus, it is precisely the same issue. The RFC2047 client cannot change
> which character set that is in use, so the best it can do is translate
> the codes into raw bytes, and let the user handle it. OK, it could use
> fallback characters as well, but that's a much worse solution, because
> the agent does not really know which charset the user is using. It could
> check the locale, but the locale may disagree with reality.
So it's better if the user has to guess the charset, exit the
newsreader, change the charset of the terminal, restart the newsreader,
look for the newsgroup, search through all read articles to find the
posting she was unable to read to be finally able to read it -- on a
Better than having the user set a configuration option *once* (only if
the newsreader can't determine it automatically) and having the news-
reader handle the rest?
Remember, in a transition period from raw leagacy 8bit and RFC 2047 to
UTF-8, we *will* see all of these three encodings. Currently, the 8bit
charset can be set on a per-group basis, RFC 2047 is detected automati-
cally. With a mix of UTF-8 and 8bit, this is no longer true.
Newsreaders will have to be able to recognize and retranslate different
charsets to the terminal charset anyway... and most of them already do.
The only big difference between RFC 2047 and raw UTF-8 here is
that there is existing software that can handle RFC 2047 without user
intervention while UTF-8 will often require the user to manually guess
and set the charset until they can detect UTF-8 themselves.