Subject: RE: [Ltru] Support of JAVA

From: "Addison Phillips" <[email-masked]>
Date: Fri, 22 Apr 2005 09:15:35 -0700

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?

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.

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? 

Oh, the horror of it all.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of JFC (Jefsey) Morfin
> Sent: Friday, April 22, 2005 2:35 AM
> To: ltru Working Group
> Subject: [Ltru] Support of JAVA
> 
> I am not a Java developper. I am told there are equivalent problems in
> Java
> to support RFC 3066 and to include the script, Java not permitting the use
> of "-" and "_" in the initial part of the tag? If I am correct the
> proposed
> format does not consider/coordinate with Java's needs. This would be a
> lack
> of extensibility of the format?
> Thank you for the comments.
> jfc
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 23 Apr 2005 02:40:28 +0200

At 18:15 22/04/2005, Addison Phillips wrote:
>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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 23 Apr 2005 03:06:46 +0200

JFC (Jefsey) Morfin wrote:

> there is no RFC 3066 standard since RFC 3066 is only a BCP
> and not a standard

I've asked almost the same question here in
<news://news.gmane.org/[email-masked]>
or <http://article.gmane.org/gmane.ietf.ltru:922> resp.

It's one of those IETF mysteries I don't get, and reading
draft-hoffman-taobis-02 and its references didn't help. :-(

I'm almost sure that BCP 47 (3066) _is_ wrong, the 3166-1
business.  And we're sure that 3066bis is only a temporary
solution until a future 3066ter allows to list ISO 639-3
with extlang etc.

Finally I'd bet that my idea to go back to standards track
instead of a BCP is "dubious" or worse, but I'd really like
to know why.  Are BCPs a dead end, is it impossible to get
rid of them and to return to standards track ?

                          Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 23 Apr 2005 14:42:59 +0200

>rid of them and to return to standards track ?

This idea is correct and does not contradict the RFC 3066 bis project. My 
only opposition to the current Draft is precisely that it does not respect 
the spirit of the Standard Internet process. Let review this main and first 
thorny question risen by the Charter.

There are three problems discussed by the charter.

- the identification of the languages in the Internet standard process 
(first sentences).
- the difficulties of applying RFC 3066 as it is, and the ways to remedy to 
that.
- the filtering solutions.

I say that they should be resolved in the following way

1. in having an language identification framework applicable to _every_ 
Internet Standard Process needs, past and future. This should be 
accompanied by a letter to the IESG or a part in the Draft to provide 
further guidance on the Charter revisions. It should document why this 
brings consistency, stability, security and capacity for Internet standards 
scalability. This general framework should succeed to RFC 3066 as RFC 047.

IMHO as a BCP it should stabilize a WG-TAGS as the maintainer of the subtag 
registry, the current status would be provided in annex. Being a BCP (which 
should be a description of real common practices) it can be easily updated 
by RFC (I suggest every year - as there are RFCs describing the historic 
status of RFCs); using monthly drafts to keep an accurate status of the 
subtags (a BCP is not normative but descriptive, so a Draft can be a 
snapshot of an evolving situation - with a 6 month validity).

The advantage is this corresponds to a well defined, stable and 
acknowledged process. That there are mirrors of RFC everywhere. That an RFC 
annex is not necessarily the place a browser will parse.

Another important advantage is that the WG-TAGS charter is revised every 
year by the IESG under IAB guidance/review. This permits to adapt to the 
Internet standard process and to ISO evolution without problem.

Another advantage is that each yearly RFC is timestamped (I would say every 
January 1st). This gives a good historic spine to leave totally open to 
imaginative thinking the way to address standard evolution question on a 
per application basis (if a new system starts on today document, they will 
not care about the past, while the common BCP 047 will keep them consistent 
with every other application).

2. to evaluate, from the RFC 3066 four years experience, what belongs to 
the general needs of the Internet standard process, which should go to the 
general framework and what is specific to which applications. From this to 
provision in the framework the links to specialised RFCs, to describe the 
requirement an RFC must match to adequately describe an application 
language tag, etc.

I submit that problems difficult to address in the current Draft way, 
result from a lack of underlaying framework, and oblige to the "SHOULD", 
"MUST", etc debate which should only be cases of a framework.

3. to discuss in detail the filtering solution, starting from the 
objective/target for each application (to the light of the framework and of 
possible legacies of _that_ application and of its own standardisers 
evolution strategy) to write the BPC 047 compliant RFC 3066 nth, for each 
application. Please remember RFC 1958 basic principle: but that principle 
everything in the Internet may change and solutions must keep this as 
normal possibility.

In the status of the current debate this means two (or more) documents, as 
described by the charter.

1. a BCP 047 replacement providing a language description framework, also 
supporting the much needed tag names and including the registry present 
yearly status.

2. an RFC 3066 bis documenting most of the areas of use of the present RFC 
3066 bis (HTML, XML, CLDR, etc.): tags, filters, use of the implicits,

3. on demand additional RFCs by members of this group or others groups 
documenting the use of language related information in LDAP, Java, MPEG, 
DNS, OPES, CRC, Internet Architecture, etc.

jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 24 Apr 2005 05:02:49 +0200

JFC (Jefsey) Morfin wrote:
 
> This should be accompanied by a letter to the IESG

The only letter to the IESG I foresee at the moment is
Randy's or Martin's letter asking for another last call.
That's strictly their business.  Of course you're free
to write your own letter to the IESG.

> IAB guidance/review

The IAB and language tags ?  I really don't think so.

> Another advantage is that each yearly RFC is timestamped

The draft registry has a timestamp near line two. as specified
in chapter 3.1 of the registry draft.  Each entry has its own
timestamp Added (and Deprecated if applicable).

BTW, the ABNF in 3.1 is a layout mess, the main ABNF is much
nicer.

> evaluate, from the RFC 3066 four years experience, what
> belongs to the general needs of the Internet standard
> process

That's trivial, DO NOT ABUSE ISO 3166-1 ALPHA-2 CODES OR DIE.
Bang, 3066 is dead after CS (for those who want stable tags).

> to discuss in detail the filtering solution, starting from
> the objective/target for each application

Are you talking about matching ?  Now where's the WG charter
on Addison's page ?  Trying <http://purl.net/xyzzy/-ietf/ltru>,
no, it's <http://www.ietf.org/html.charters/ltru-charter.html>
No "filter", on this page, only "match".

> write the BPC 047 compliant RFC 3066 nth, for each
> application.

There's only one registry, how applications use it should be
documented in the corresponding manuals.

> Please remember RFC 1958 basic principle

"Exponential growth", I refuse to read the rest of this FYI
written 1996.  I'm a big fan of texts like RfC 1591, but not
every FYI.

> everything in the Internet may change and solutions must keep
> this as normal possibility.

Yes, in the case of 3066 and 3066bis we've seen this for the
problem of ISO 3166-1 alpha-2 codes.  And after Unicode is now
used everywhere we need scripts to structure this uniform mass.
 .
> on demand additional RFCs by members of this group or others

BTW, you announced a draft for about mid-April, are you still
working on it, or have you dropped the idea ?  So far Bruce's
draft is the only alternative for those who need scripts.  Not
counting some unpublished 3066-registrations like the MO-stuff.

                          Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 24 Apr 2005 12:26:50 +0200

>counting some unpublished 3066-registrations like the MO-stuff.

Dear Frank,
the old internet leaks everywhere, suffering from scalability (this is a 
normal standard growth phase). Working on four matters (CRCs, IPv6 
deployment/routing, Multilingual Internet and WSIS) and operating daily 
registry services shows me the much needed innovative consistency of the 
propositions to make today. This calls for a lot of parallel thinking, work 
and agreements ... and time (only 48 hours a day).

The current Draft is an acceptable beginning for the second kind of 
documents planned by the Charter, addressing the specific needs of XML and 
possibly (undocumented) of CLDR by the people in charge of their 
specifications. I hoped they understood that from Randy's allusion to the 
Charters thorny points still to discuss, but I give up hoping: I sent a 
basic review Addison requested and joked at; I sent a complete review of 
Draft which was supposed to result in questions by Randy and which was just 
partly commented once. All this is obviously good material for an appeal, 
but it would be certainly better to discuss these issues within the WG.

The problem is that IETF is not interested in multilingualism and that most 
of the members of this WG perceive it through the low layer 
internationalisation issues. The first priority would then be to attract in 
this WG all those who will block the Draft during the Last Call.

I certainly prepare a Draft, but I have a practical work load problem as 
the program my working groups are engaged in is large. It plans several 
RFCs for information for Tunis. So, it can only be consistent with three 
other efforts with long texts for me to write in English. I hope I am 
finished with them by the end of the week. The detailed scope of the Draft 
is ready (documented in part in my mail) and some parts completed.

But I continue to think that such a Draft would be unnecessary should Randy 
start a debate on the Charter thorny points, leading to a review of the 
whole language tags framework. But, IMHO, attracting before the future Last 
Call opponents would be advisable.

jfc