Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 May 2001 14:38:41 +0900 (JST)
From:      Noriyuki Soda <soda@sra.co.jp>
To:        i18n@FreeBSD.ORG, audit@FreeBSD.ORG
Cc:        bsd-locale@hauN.org
Subject:   Re: CFR: ISO_* -> ISO-* locale renaming
Message-ID:  <200105190538.OAA01191@srapc342.sra.co.jp>
In-Reply-To: <20010519075333.C83245@nagual.pp.ru>
References:  <20010518203702.B79058@nagual.pp.ru> <20010519050946U.tshiozak@din.or.jp> <200105182238.HAA29872@srapc342.sra.co.jp> <20010519031612.B83245@nagual.pp.ru> <200105182356.IAA00242@srapc342.sra.co.jp> <20010519075333.C83245@nagual.pp.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sat, 19 May 2001 12:53:45 +0900,
	"Andrey A. Chernov" <ache@nagual.pp.ru> said:

> On Sat, May 19, 2001 at 08:56:54 +0900, Noriyuki Soda wrote:
>> 
>> The existing standard (ISO8859-1) is reasonable.
>> There is no reason not to use the name.

> Yes, there _is_ that reason. In your case nl_langinfo(CODESET) returns
> _illegal_ and unusable MIME character set so you can't use it f.e. in mail
> exchange or any other MIME format compatible application. So, you need
> conversion table between illegal and legal character sets in case you
> suggest. I am strongly against such practice. Compatibility reasons
> weights very small comparing to that.

You are missing point.

It is existing practice that the return value of nl_langinfo(CODESET)
is not usable for MIME charset name.
So, *ALL* existing programs are using conversion table to
convert nl_langinfo(CODESET) to MIME charset name.
Interestingly, this is true on even Linux. Because Linux uses
"ANSI_X3.4-1968" as nl_langinfo(CODESET) for ASCII as I already
pointed out, and many programs only knows "US-ASCII" as MIME charset
name for ASCII, programs usually have to convert "ANSI_X3.4-1968"
to "US-ASCII" on even Linux.

If a program depends on the fact that an OS retruns MIME compatible
value as nl_langinfo(CODESET), such program is just not-portable.

So, avoiding conversion table has no real gain at all.
All programs are using such conversion table already.
And all future programs also should use such conversion table in the
future, because all commercial UNIX and even Linux returns unsable
value as MIME charset name.

>> That avoids benefit to use IANA registry.
>> 
>> If MIME charset name can be just used as codeset name like Linux,
>> certainly it has its benefit. But if it cannot be used, why do you
>> want to use IANA registry at all?

I said "benefit" above, but it is not *real* benefit, because portable
code cannot rely on such behavior.

> Currently IANA registry codeset can be used in MIME applications as is and
> it is main benefit of choosing IANA and main X11 disadvantage.

> About case insensitive and aliased names at whole as you ask: this must be
> implemented in one direction only, i.e. ideally locale code must
> understand _any_ codeset, including X11 one,

That is very problematic approch.
The codes which understand locale names are not only locale functions
in libc, but also many userland programs. For example, look at charset.c
in "less" program. "less" certainly parse locale name, and the way
that "less" currently use is case *sensitive* (of course).
If any locale code must understand _any_ codeset, there are really
many programs that FreeBSD should modify.

And most importantly, there is no real benefit to implement such
complex rule (because the way is not portable at all).

In contrast to your proposal, using X11 (or OpenGroup) locale name
requires almost *no* code change at all, because they are already
standard and already supported.

>> So, your proposal is not only incompatible with commercial UNIXes,
>> but also incompatible with Linux. Mmmm, how about using X11 name instead?

> I explain my position about multi-names a bit earlier in this
> message. Currently such code is not implemented.

The way I proposed is same with what commercial UNIXes are already do,
and it is already implemented on FreeBSD, and waiting for approvement
for merging to FreeBSD.

In contrast, your proposal is incompatible with commercial UNIXes,
and incompatible with even Linux in some points. Why do you have
to create yet another incompatiblity, even there is no real benefit?
-- 
soda

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105190538.OAA01191>