Subject: [Ltru] follow-up of an exchange on [email-masked]

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 18 Mar 2005 17:00:21 +0100

I have been questioned on the ietf-languages mailing list. The dialog lead 
to a threat which belongs to this WG. We agreed to transfer it. Here is the 
status of the current relevant exchange.

>>[I respond to one question] ... they are/this is more related to the 5 
>>levels/points underlaying a multilingual internet (I am not sure they are 
>>layers, they just are necessary)

Addison comments them and obviously we are in rough agreement (these points 
are in the Charter as "identifying languages and language preferences" - 
like in the Word tools menu. We only disagree on scope and application of 
the RFC. I think there are many ways to make the two positions converging 
and to see new synergy resulting from it. But I need first to review the 
draft (I said I will do it early next week). Responses from Addison and 
Mark to these comments will help, as weel as comments of this WG.

On 19:29 17/03/2005, Addison Phillips said:
> > - identification of the language (ISO 693 or the like) -> interrelation
> > between people - we can talk
>RFC 3066 and 3066bis call this "primary language"

Correct. However a general remark: this is an analysis. It permits the use 
of the words we agree upon, but it is more general. I am interested in the 
users needs and in the network systems' answer to support them in the way 
applications/developers may want to perform them. My priority is to the 
users, to the network and to the applications, not to the RFC or ISO 
document. And I live in a real world. I am not interested in good document 
you cannot implement due to (may be stupid but real) external objections.

- as a user I consider myself (the need I know the best), the people I 
develop/consult for in my position of "super IANA like" (CRC) project, the 
Governments I relate with and most of all multilingualism in naming, 
e-government, day to day life as per the various ITU, WSIS, UNESCO 
unanimous declarations.

- as far as network are concerned I consider the Internet current 
architecture, the Interbox architecture I work on (first guidelines a 
delayed by all this and current debates, presented to Govs and ITU last 
months: roughly a virtual user centric NGN permitting the transition from 
current Internet), the management of the few extended services of the 
Internet architecture (name space - DNS, ONS, Handles, PAD, OPES, ONES), 
the dramatic architectural impact on a robust yet rustic end to end 
oriented architecture of multilingualism.

- as far as applications are concerned I am interested in the consistency 
of the different existing tools, but I am also interested in all the 
applications delayed by the limitations of the current systems. I am 
advocating the most robust, simple and open common basis to permit to 
develop compatible tools rather than standardizing one single application 
which will become overloaded with incompatible demands. A good example of a 
success in that direction is the DNS which has well resisted since 1983 
(RFC 920).

- as a Registry Manager involved for 30 years in the international public 
and private real intergovernance.

> > - internationalization (what discusses RFC 3066 - ISO 15924) ->
> > interoperation between machines - we can write
>RFC 3066bis calls this "script"

Yes. Same as above.
Also, users are not bond to scripting. Other supports (voice, signals, 
commands, icons, images, fax, Minitel, music, etc.) are OK with this 
analysis. In your context we agree.

> > > - multinationalization (taking into account ISO 3166 or other 
> geopolitical
> > attribute) -> interculturization between communities - we can share same
> > cultural references, the same meanings (for example, what may be missing
> > in
> > here).
>RFC 3066 and 3066bis call this "region"

Yes. Same as above. But in your context you refer to a region. IAnalysis is 
not limited only to that. It can be a Diaspora, a Church, a culture, etc. 
Look at Tamils for example, as a population.

> > - multilingualization (semantic, grammar, dictionary, syntax, etc.) ->
> > interintelligibility -> we can understand each other
>
>RFC 3066bis calls this a "variant"--variations within a language, which 
>may take many forms (orthography, dialect, etc. etc.). RFC 3066 allows 
>entries that represent this to be registered (but doesn't identify them 
>explicitly with a name). Both allow multiple variations to be applied to a 
>text.

Here I think we have a real difference.

If I read you correctly, you discuss of variation _within_ a language. I 
discuss of what describes a language. I suppose that you will translate 
this into a different code/description permitting someone to qualify a text 
with a different tag. I will translate that into a CD including all the 
data necessary to describe the language to a computer, to permit to 
authenticate the origin of the text and to write and edit the text.

> > - vernacularization (procedures, styles, tools, etc.) -> interusability ->
> > we can do something together
>
>Language tags identify text, not the processes that are applied to them.

This is the contentious point we have from the very beginning. Would you 
have included that sentence in the RFC 3066 bis it would be an applauded 
RFC by everyone. I will come back below on this key point.

>A French text that has had French hyphenation rules applied to it is just 
>a French text. Particular vernacular distinctions may be candidates for 
>registration, though, although this dives into more difficulty: is it 
>another language or merely stylistic license? Merriam-Webster defines 
>vernacular thus:
>
>1 a : using a language or dialect native to a region or country rather 
>than a literary, cultured, or foreign language b : of, relating to, or 
>being a nonstandard language or dialect of a place, region, or country c : 
>of, relating to, or being the normal spoken form of a language.

The interest of this langtag is to show that the questions you rise are 
structurally well addressed by our common analysis. The lang3tag you 
propose relates to a region and matches (a) and (b). But these are old 
description outdated by the current world which is more generally described 
in (c). Here you have a problem because your tag could (but your ISO 3166 
oriented approach prevents that) to use virtual regions.

Obviously we lack the common usage of a model where we could spot these 
issues as I am accustomed in my working groups. But you are in W3C and you 
know about web services. When two web services interacts they actually use 
a vernacular and their Man/machine interface will try to accommodate it to 
the users' language and brainware (the way people commonly use a network 
system). This results in a web vernacular, in a mail vernacular which 
currently is an ASCII vernacular but should multilingualize (and RVC 3066 
is a key building block). When I see To: From: these are vernacular terms. 
This is very interesting to see when people know/can change the mail answer 
back line to see the formula they use from English "said" to Latin "Scripsit".

Obviously vernacular with that meaning includes a quasi illimited type of 
procedures.

>In other words, Twain's "Pudd'nhead Wilson" is written in a particular 
>vernacular form of U.S. English. One can register a variant (under 
>3066bis--or a tag under 3066) that conveys this distinction (perhaps 
>"en-US-twain"):
>
>"Say it ag'in! En keep on sayin' it! It's all de pay a
>body kin want in dis worl', en it's mo' den enough.
>Laws bless you, honey, when I's slav' aroun', en dey 'buses me,
>if I knows you's a-sayin' dat, 'way off yonder somers,
>it'll heal up all de sore places, en I kin stan' 'em."
>
>Generally though this is considered unnecessary. There are many 
>vernaculars in the world. Only in exceptional cases does it become 
>necessary to identify a particular language variation as distinct. But 
>this does not obviate the point that RFC 3066 (and its proposed successor) 
>already provide a mechanism for doing exactly that to identify text in the 
>cases where the differences matter.

I do not dispute the case. I just document an analysis. I am glad to see 
that even if we may have slight differences, we are basically in agreement. 
And that you testify that what I say is in RFC 3066. I documented that in 
telling that I could encapsulate the RFC 3066 in my own approach. And asked 
if the way I was doing it was reducing in anyway your proposition. The only 
objections I received were on my own part, not on my support of yours.

>(For that matter, 3066bis relaxes strictures surrounding the use of 
>private use subtags so that specialists can identify various dialects or 
>vernacular usages among themselves without the use of registration: 
>"en-US-x-twain".)

This is internal to your proposition. I am glad you increase flexibility. 
The only remarks I have is that I am not only concerned in specialists but 
in every Internet user. I have observed that what is supposed to be 
reserved to specialists is quickly used by everyone with easy to use tools 
and support. This is what RFCs call scalability. Everything has to be 
documented and planned in a standard as if it was going to be used by 
everyone all the time. RFC 1958.

>So how is what you're saying different from RFC 3066bis? Heck, how is it 
>different from RFC 3066?!?

In the way RFC 3066 is actually used, it is not. This is what we are trying 
to tell you for two months. The problem is:
- if we are perfectly happy with RFC 3066 as it is applied today and we can 
stay happy for ever.
- you documented you are not. And we certainly want your needs to be 
satisfied, but in making us unsatisfied.
And I extensively documented what is detrimental, I can come back again on it.

I will use some HTML to make the presentation clearer. I hope all the 
readers can use it.

RFC 3066 IS NOT APPLIED
RFC 3066 works well because it is not really applied. What you want will 
make it applied and will show its lacks and the lacks of its 
implementation. This lacks are to be corrected. There are mainly three.

1. the ietf-language mailing list

The ietf-languages mailing list is not the IANA list presented in the RFC 
3066. It should be managed and archived by IANA and documented on the IANA 
site to get the necessary exposure, participation and recognition by the 
international community. This would most probably help it to self correct 
what I reproach to it. One of the things it would probably have permitted 
to evaluate is its moderation and the reviewer which should probably be a 
three persons committee selected as two linguistic experts of English and 
of French culture and one network expert.

2. a consistency with the considered (ISO) lists
The RFC 3066 confuse the process and the deliverable. Up to now this is not 
too much notice because RFC 3066 is only occasionally used and the tables 
updated. It will change when it is extensively used.

The deliverable is the IANA added code. It should be consistent with the 
ISO lists it intend to complete. There is too much confusing information 
(name of the referent, documentation of the language). And there is no 
French translation. If someone needs the additional subtag she will know 
what it is. All the subtags must be of same weight and definition. How do I 
know that an ISO 693 code is really what I mean and if someone is not going 
to introduce a new IANA code which will better define my need? How do I 
know what ISO meant when I know what IANA means. On an other end what 
should I do when the IANA added code match my need but not the description? 
How do I make its use consistent with the use of the other ISO codes?

3. the default format being unique
RFC 3066 to my knowledge is used by your W3C applications, by Unicode, etc. 
outside of Internet documents and IANA except for IDNs. This obviously does 
not help to identify this problem and I am taxed to underline it, people 
focusing in the only example at hand, rather than on the  fundamental problem.

RFC 3066 starts with the conclusion. The format proposed format should be 
tone of the conclusion of the analysis. As the use, as the registration 
procedure, etc. Because you use a given format in a certain kind of 
applications, you want to use that format for ever. By this token UNIX 
would use DOS which would use DEC file format. Life is more flexible and 
innovation comes from flexibility. The format you propose does not suit my 
needs. It should not be a big deal to stay compatible.

4. You do not care about others' needs
The lack of RFC 3066 apparent use in other areas than your current 
applications gives the feeling that RFC 3066 can conduct the world. The 
idea that Countries may be taught to ask for ISO 3166 langtag compliant 
codes from other countries experience seems odd.

This also does not help to understand that you are shaking an existing 
stable situation and status quo. But you actually come and propose changes, 
you do not care about those who are affected ("you" - at large - even want 
to expel them).

Multilingual Internet

The status quo is based upon the very low interest in multilingualism by 
IAB. Demonstrated by the only RFC 3066, the low consideration of  Paul 
Hoffman's initial work, and the clear disinterest signal of the IAB's RFC 
3869 (which lists the development priorities to be funded by the 
Governments - of every nations and languages - and does not even allude to 
multilingualism). Now, you want to make it a core issue interfering with 
the core issue of country codes through your ability to discuss ISO 3166, 
but more questioning the entire Internet architecture!

To understand this, you have remember how a network is built. Every 
network. Even if it is quite buried in the Internet defaults. A network 
permits a class of users to relate with a group of resources in using 
common identifier they register and manage in a registry (NIC) and 
parameters they store in a common repository (IANA, CRC). The initial 
international public network technology (1971) we deployed fully supported 
classes and groups and permitted to support an unlimited number of 
national, linguistic, corporate, public interest externets (a class, a 
group, a registry, a context supported by reference center). OSI principles 
(1975?) reduced externets to the notion of closed user groups, making the 
class (users) and the group a single list. Internet (1978-83) as a private 
network internetting (Vint Cerf/Bob Khan) into a DoD catenet (Louis Pouzin) 
only considered the Internet users class ("IN" and the "CHAOS" test class) 
and did not really mind about groups (DNS views can very partly reproduce, 
as well as intra/extranets). This permitted to dramatically reduce the 
intelligence expected from the network and to build a robust (but quite 
rustic!) network based upon the two "core values": dumb network, end to end.

Now, multilingualism was initially started (Japan, EBCDIC and 
France/Minitel) in using classes of non ASCII users interacting with group 
of resources able to respond them. This would correspond in the Internet to 
create 1.600.000 classes and to implement a group support which is totally 
inexplored today. A totally new DNS technology. Also, to speed up routing 
the group support would probably call for a different IPv6 structuring such 
as the one proposed for the ITU-T /3 block. We will have to come to that, 
but not now! Let experiment the transition first.

IDN introduced the idea of supporting multilingualism in the ASCII class in 
using internationalization. But this does not work because the analysis is 
not correct. It just focused on the DN and not on the FQDN and introduced a 
hierarchy (punycode or not are filtered) in the label rather than in the 
namespace. This means that they did not identified the need for virtual 
zones (sub-classes in the IN class) and the need of consistence of the 
vernacular (IDN Tables) used in that virtual zones. Result: the current 
homographs problem. The correct solution consists in respecting the 
standard network architecture in a scalable way and to force the 
multilingual FQDN (FQMLDN) to be consistent from the TLD to the last level. 
Due to the inclusion on the IN class and its existing number of TLD there 
must be a _presentation_ of the zone (lingual SLD) as a single label (ex 
nnn.chinesetag.cn being displayed as nnn.chinese_printing_of_cn) and a 
filtering of all the codes which are not permitted in a correct FQMLDN. For 
that all the concerned machine must have the necessary (limited) 
information of how to present a lingual SLD as a lingual TLD, and the 
corresponding IDN Table. There are three places to distribute them: either 
the IANA and the CRCs, either a dynamic repository like Akamai, or the Locales.

So, you understand that langtags are actually the names of the lingual 
externets or their aliases. Also, that depending on the way they are 
organized, they may fit or not into the DNS as it is managed today. Also, 
that while the WSIS is discussing the intergovernance there are a lot of 
interest to play it clearly, not to confuse the issues.

Applications
you consider only the applications you know. But you disregard the 
applications others are/should be (:-) working on (like OPES at the WG-OPES 
and ONES in other places, the CRCs as far I am concerned). And all those a 
correct support of multilingualism and vernacular could unlock. The web is 
a dazibao. One does spend our life reading. As Hitch says: 90% of the human 
communication is not with words. This leaves   a large number of 
applications  to develop. Their tagging needs are as much important than 
any other.

THE KEY ISSUE

The key issue is what the langtag for?
The charter says: they are necessary from (a) cataloging to (b) processing.
You say: "Language tags (c) identify text, (d) not the processes that are 
applied to them".
The Draft says:  "This document describes the structure, content, 
construction, and semantics of language tags for use in cases where it is 
desirable to (e) indicate the language used in an information object. "
Introduction of the draft says: "(f) Information about a user's language 
preferences commonly needs to be identified (g) so that appropriate 
processing can be applied"

Dictionary.com says:
"indicate":
(h) to show the way to or the direction of; point out: an arrow indicating 
north; indicated the right road by nodding toward it.
(i) to serve as a sign, symptom, or token of; signify: "The cracking and 
booming of the ice indicate a change of temperature" (Henry David Thoreau).
(j) to suggest or demonstrate the necessity, expedience, or advisability 
of: The symptoms indicate immediate surgery.
(k) to state or express briefly: indicated his wishes in a letter; 
indicating her approval with a nod.

If the purpose is informative, the way I read (a), (c), (d), (e), (f), (i), 
things are OK with me.
If the purpose is normative, the way I read (b), (g), (h), (j) and possibly 
(k), things are not in the present status of the document.

Due to the limited use of RFC 3066  discusses above the question was not 
risen. They were used the way you say, to qualify/catalog texts in 
different applications and for IDN Tables.

But RFC 3066 - and you and Charter - uses a wording and you use examples 
(Introduction) which creates ambiguity and confusion about the intended use 
of the langtags. You can qualify a text with any descriptor you want, this 
creates no problem. You can use the langtags as a search key the way you want.

But to document the definition of the way a text is to be processed, you 
need at least all the five the descriptors we described. This is not 
something you can dispute or you kill the analysis you described as being 
also the RFC 3066 analysis.

If you do not provide these 5 elements, you actually imply the defaults are 
to be used. There is no default documented in the RFC 3066 and in your 
draft, except the name of the registrant/referent. He the becomes the 
default to tell what are the missing parameters. If the name is of a 
person, the opposition to that person will unnecessarily creates an 
opposition of the lingual community - even if the tag is correct. If the 
name is of a corporation or associated to a corporation this may be worse 
and detrimental to the interest of the voluntaries who carried the effort.

>>>  didn't think any Microsoft product dealt with "style" or "authority"
>>>attributes, nor in script except to the extent that is covered by
>>>registered RFC 3066 tags.
>>
>>Name the reference/authority, etc. the way you want. Authoritative in its 
>>domain is an usual concept in the Internet culture. You can certainly 
>>find other words. This is what says a computer that when I write in 
>>French this is not Greek, or what make you sure that when I write in 
>>Provencal it is not Berrichon.
>>
>>I gave in my response to Peer how and where the Word system does that.
>>- tools - languages : language, script, country  (you can qualify even if 
>>you do not understand).
>>- tools - options (preferences?) : dictionary, style (you need them to 
>>understand and write).
>>Which system do you use? Does it support the same descriptors?

This addresses an objection you made in another email, saying that these 5 
points were not covered by Word and that your Word 2003 was great because 
it did not support RFC 3066 which was not yet published. Actually, I do use 
Word. My copy is Word 97, and even in these ancient times, these points we 
identified/share are here. It only add the proof of the age.

>>This being said, I understand your remark about what I name the 
>>multilingualization level. You say English is not defined. I belong to a 
>>culture where definition is known and supported for 4 centuries. This 
>>makes me more aware of this point. Actually English, in a way is more 
>>defined than French. When we introduce a computer in a culture, we do in 
>>a few months, a few years, what Richelieu and France did a long ago and 
>>matured over centuries: we create an "Académie de cette Langue".

BTW this is probably a very interesting and exciting field of work.

>>What I object is that this Académie may belong to anyone else than to the 
>>people sharing that culture. And naming is already a way to own. As long 
>>as it is to qualify the culture it is OK because there is a need. When it 
>>comes to enter in its definition this is - IMHO - an intrusion. And I 
>>refuse to share in that kind of intrusion.  To the contrary my approach 
>>is to say we are here to serve, help, educate so they can first share in 
>>this process, comment it and eventually conduct it for themselves.

I fully understand and support (with may be some tunings, like the support 
of namespace related information) the Unicode CLDR project - which is in 
the IESG charter but not documented - I wonder why. But I would strongly 
object to it if it was not carried under the supervision of Members of the 
concerned communities. Frank hates Governments. I tend to think they are 
our only protectors against e-colonization. Each of us have our fancies.

>>I note that three days ago this list had 2 Greek languages. Now 3 and 
>>probably 4. Because Greek persons stepped in and documented _their_ own 
>>languages. This is the way it should happen for every language, the 
>>request should come from each Internet community. This is the spirit of 
>>the text of RFC 3066. I fully understand that people may want urgently 
>>scan the cultural patrimonies of others, to sell it or to protect it from 
>>being merchandized, want to speed up the process. I do not think it is 
>>commercially or charity advisable to by-pass their future 
>>customers/friends in this process (as the reactions to the Google's 
>>annoucement show it). To the contrary they should help empowering the 
>>language and help their cultural, linguistic, political authorities 
>>through the registration process.
>>
>>For example, I fully agree with you that the name of the langtag 
>>registrant is not necessary. But I would suggest to remove it only when 
>>the registration is by an outsider.

I note that if two languages are used at ISO (while UNESCO and ITU use 6 
languages) there is probably good reasons, which may be to make sure that 
several and at least two cultures shared into the analysis (for defining 
the tag and when using it). This forces an openness of mind we often need. 
It means alternative thinking, searching, etc. Back-up is always a good 
thing. Two languages help also help the user to make sure the code she 
wants to use is the good one. Acceptance of a bilingual table will be far 
higher in a multilingual context than an ASCII only table.

Coopetition tends to foster quality.

I hope that this will eventually help.
jfc

=====================================================
For your convenience:
Draft:  http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt
Charter: http://ietf.org/html.charters/ltru-charter.html
gmane: http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
=====================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
  as a basis for country code top-level domain names was made with
  the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=====================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=====================================================
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=====================================================
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Fri, 18 Mar 2005 12:21:20 -0500

JFC (Jefsey) Morfin scripsit:

> to a threat which belongs to this WG. 

Since we are on the record here, it is important to clarify whether this was
a threat or a thread.  As a participant in both lists, I believe it was a thread.

-- 
Híggledy-pìggledy / XML programmers            John Cowan
Try to escape those / I-eighteen-N woes;        http://www.ccil.org/~cowan
Incontrovertibly / What we need more of is      http://www.reutershealth.com
Unicode weenies and / François Yergeaus.        [email-masked]