Message-Id: <6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.com>
Date: Sat, 23 Apr 2005 02:40:28 +0200
To: "Addison Phillips" <addison.phillips@quest.com>,
	"ltru Working Group" <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Support of JAVA
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 18:15 22/04/2005, Addison Phillips wrote:
>I am a Java developer and Java java.util.Locale objects are not to be 
>confused with language tags.
>
>What Java does internally has nothing to do with language tags. The only 
>real touchpoint is in J2EE, in which the Accept-Language header in an HTTP 
>request is mapped onto Locale objects in a rather brain-dead fashion (I 
>mentioned this on-list recently).
>
>The use of "_" as a token separator in Java locales has nothing to do with 
>language tags. The fact that Java locales use ISO 639-1 and ISO 3166 
>internally is nice, but that doesn't make a Locale object into a language 
>tag. Perhaps you should read up on the alleged problem before proposing it 
>as one?

I only ask if there is a problem. I am not interested in each problem and 
each solution, but to make sure to offer the possibility of a solution in 
every case.

The charter says one of the problems to address is the "Lack of 
parseability and the ability to verify well-formedness". You presume that 
the only format you discuss offers the best parseability. I presume nothing 
because this prevents scalability. The charter says "The RFC 3066 standard 
for language tags has been widely adopted in various protocols and text 
formats". This rises "thorny" questions:

1. there is no RFC 3066 standard since RFC 3066 is only a BCP and not a 
standard
2. this implies - what is true - that the language tags are used in various 
formats.

For example, I submit that the best parseability is a fixed hexa format, 
which in addition permits - in being used as an interface ID - a direct 
IPv6 access to an information server, for example for accessing the locale 
data.

This is only a debate to better the Draft after two lasts calls, not a full 
discussion of the Charter.

>The folks at Sun in the J2SE group are aware of the work going on this 
>area. I believe they are waiting to see the outcome before creating an 
>implementation.

I doubt this is a response acceptable to the IESG.

>In any case, I fail to see how making language tags compatible with every 
>proprietary locale tagging scheme in the world (and there are many of 
>these) serves the greater good. It is up to proprietary schemes to adapt 
>to standards and not the other way around. Hey, while we're all boggling 
>about the potential effects, I notice that Microsoft's CultureInfo class 
>in C# and their LangID/LCID system might be affected too! And what about 
>those POSIX locales?

Question is how does your proposition help them all to converge, to best 
develop?
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru