Return-Path: Received: from eikenes.alvestrand.no ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.1.11-Mandrake-RPM-2.1.11-1mdk) with LMTP; Fri, 18 Mar 2005 17:02:55 +0100 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E18261B8F for ; Fri, 18 Mar 2005 17:02:55 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25804-10 for ; Fri, 18 Mar 2005 17:02:51 +0100 (CET) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F66061B8E for ; Fri, 18 Mar 2005 17:02:48 +0100 (CET) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJu4-0005fS-IM; Fri, 18 Mar 2005 11:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJu1-0005fJ-T6 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 11:00:46 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21388 for ; Fri, 18 Mar 2005 11:00:42 -0500 (EST) Received: from lns-p19-19-idf-82-249-5-14.adsl.proxad.net ([82.249.5.14] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCJtf-0003UO-LM; Fri, 18 Mar 2005 08:00:27 -0800 Message-Id: <6.1.2.0.2.20050318030616.0398feb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Mar 2005 17:00:21 +0100 To: "LTRU Working Group" From: "JFC (Jefsey) Morfin" In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AA9E6BA@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AA9E6BA@irvmbxw01.quest.com> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com Cc: Subject: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0520657625==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no --===============0520657625== Content-Type: multipart/alternative; boundary="=====================_22284413==.ALT" --=====================_22284413==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA21388 I have been questioned on the ietf-languages mailing list. The dialog lea= d=20 to a threat which belongs to this WG. We agreed to transfer it. Here is t= he=20 status of the current relevant exchange. >>[I respond to one question] ... they are/this is more related to the 5=20 >>levels/points underlaying a multilingual internet (I am not sure they a= re=20 >>layers, they just are necessary) Addison comments them and obviously we are in rough agreement (these poin= ts=20 are in the Charter as "identifying languages and language preferences" -=20 like in the Word tools menu. We only disagree on scope and application of= =20 the RFC. I think there are many ways to make the two positions converging= =20 and to see new synergy resulting from it. But I need first to review the=20 draft (I said I will do it early next week). Responses from Addison and=20 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) -> interrelati= on > > 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 us= e=20 of the words we agree upon, but it is more general. I am interested in th= e=20 users needs and in the network systems' answer to support them in the way= =20 applications/developers may want to perform them. My priority is to the=20 users, to the network and to the applications, not to the RFC or ISO=20 document. And I live in a real world. I am not interested in good documen= t=20 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=20 develop/consult for in my position of "super IANA like" (CRC) project, th= e=20 Governments I relate with and most of all multilingualism in naming,=20 e-government, day to day life as per the various ITU, WSIS, UNESCO=20 unanimous declarations. - as far as network are concerned I consider the Internet current=20 architecture, the Interbox architecture I work on (first guidelines a=20 delayed by all this and current debates, presented to Govs and ITU last=20 months: roughly a virtual user centric NGN permitting the transition from= =20 current Internet), the management of the few extended services of the=20 Internet architecture (name space - DNS, ONS, Handles, PAD, OPES, ONES),=20 the dramatic architectural impact on a robust yet rustic end to end=20 oriented architecture of multilingualism. - as far as applications are concerned I am interested in the consistency= =20 of the different existing tools, but I am also interested in all the=20 applications delayed by the limitations of the current systems. I am=20 advocating the most robust, simple and open common basis to permit to=20 develop compatible tools rather than standardizing one single application= =20 which will become overloaded with incompatible demands. A good example of= a=20 success in that direction is the DNS which has well resisted since 1983=20 (RFC 920). - as a Registry Manager involved for 30 years in the international public= =20 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,=20 commands, icons, images, fax, Minitel, music, etc.) are OK with this=20 analysis. In your context we agree. > > > - multinationalization (taking into account ISO 3166 or other=20 > geopolitical > > attribute) -> interculturization between communities - we can share s= ame > > cultural references, the same meanings (for example, what may be miss= ing > > in > > here). >RFC 3066 and 3066bis call this "region" Yes. Same as above. But in your context you refer to a region. IAnalysis = is=20 not limited only to that. It can be a Diaspora, a Church, a culture, etc.= =20 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=20 >may take many forms (orthography, dialect, etc. etc.). RFC 3066 allows=20 >entries that represent this to be registered (but doesn't identify them=20 >explicitly with a name). Both allow multiple variations to be applied to= a=20 >text. Here I think we have a real difference. If I read you correctly, you discuss of variation _within_ a language. I=20 discuss of what describes a language. I suppose that you will translate=20 this into a different code/description permitting someone to qualify a te= xt=20 with a different tag. I will translate that into a CD including all the=20 data necessary to describe the language to a computer, to permit to=20 authenticate the origin of the text and to write and edit the text. > > - vernacularization (procedures, styles, tools, etc.) -> interusabili= ty -> > > 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=20 have included that sentence in the RFC 3066 bis it would be an applauded=20 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 jus= t=20 >a French text. Particular vernacular distinctions may be candidates for=20 >registration, though, although this dives into more difficulty: is it=20 >another language or merely stylistic license? Merriam-Webster defines=20 >vernacular thus: > >1 a : using a language or dialect native to a region or country rather=20 >than a literary, cultured, or foreign language b : of, relating to, or=20 >being a nonstandard language or dialect of a place, region, or country c= :=20 >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=20 structurally well addressed by our common analysis. The lang3tag you=20 propose relates to a region and matches (a) and (b). But these are old=20 description outdated by the current world which is more generally describ= ed=20 in (c). Here you have a problem because your tag could (but your ISO 3166= =20 oriented approach prevents that) to use virtual regions. Obviously we lack the common usage of a model where we could spot these=20 issues as I am accustomed in my working groups. But you are in W3C and yo= u=20 know about web services. When two web services interacts they actually us= e=20 a vernacular and their Man/machine interface will try to accommodate it t= o=20 the users' language and brainware (the way people commonly use a network=20 system). This results in a web vernacular, in a mail vernacular which=20 currently is an ASCII vernacular but should multilingualize (and RVC 3066= =20 is a key building block). When I see To: From: these are vernacular terms= .=20 This is very interesting to see when people know/can change the mail answ= er=20 back line to see the formula they use from English "said" to Latin "Scrip= sit". Obviously vernacular with that meaning includes a quasi illimited type of= =20 procedures. >In other words, Twain's "Pudd'nhead Wilson" is written in a particular=20 >vernacular form of U.S. English. One can register a variant (under=20 >3066bis--or a tag under 3066) that conveys this distinction (perhaps=20 >"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=20 >vernaculars in the world. Only in exceptional cases does it become=20 >necessary to identify a particular language variation as distinct. But=20 >this does not obviate the point that RFC 3066 (and its proposed successo= r)=20 >already provide a mechanism for doing exactly that to identify text in t= he=20 >cases where the differences matter. I do not dispute the case. I just document an analysis. I am glad to see=20 that even if we may have slight differences, we are basically in agreemen= t.=20 And that you testify that what I say is in RFC 3066. I documented that in= =20 telling that I could encapsulate the RFC 3066 in my own approach. And ask= ed=20 if the way I was doing it was reducing in anyway your proposition. The on= ly=20 objections I received were on my own part, not on my support of yours. >(For that matter, 3066bis relaxes strictures surrounding the use of=20 >private use subtags so that specialists can identify various dialects or= =20 >vernacular usages among themselves without the use of registration:=20 >"en-US-x-twain".) This is internal to your proposition. I am glad you increase flexibility.= =20 The only remarks I have is that I am not only concerned in specialists bu= t=20 in every Internet user. I have observed that what is supposed to be=20 reserved to specialists is quickly used by everyone with easy to use tool= s=20 and support. This is what RFCs call scalability. Everything has to be=20 documented and planned in a standard as if it was going to be used by=20 everyone all the time. RFC 1958. >So how is what you're saying different from RFC 3066bis? Heck, how is it= =20 >different from RFC 3066?!? In the way RFC 3066 is actually used, it is not. This is what we are tryi= ng=20 to tell you for two months. The problem is: - if we are perfectly happy with RFC 3066 as it is applied today and we c= an=20 stay happy for ever. - you documented you are not. And we certainly want your needs to be=20 satisfied, but in making us unsatisfied. And I extensively documented what is detrimental, I can come back again o= n it. I will use some HTML to make the presentation clearer. I hope all the=20 readers can use it. RFC 3066 IS NOT APPLIED RFC 3066 works well because it is not really applied. What you want will=20 make it applied and will show its lacks and the lacks of its=20 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= =20 3066. It should be managed and archived by IANA and documented on the IAN= A=20 site to get the necessary exposure, participation and recognition by the=20 international community. This would most probably help it to self correct= =20 what I reproach to it. One of the things it would probably have permitted= =20 to evaluate is its moderation and the reviewer which should probably be a= =20 three persons committee selected as two linguistic experts of English and= =20 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 n= ot=20 too much notice because RFC 3066 is only occasionally used and the tables= =20 updated. It will change when it is extensively used. The deliverable is the IANA added code. It should be consistent with the=20 ISO lists it intend to complete. There is too much confusing information=20 (name of the referent, documentation of the language). And there is no=20 French translation. If someone needs the additional subtag she will know=20 what it is. All the subtags must be of same weight and definition. How do= I=20 know that an ISO 693 code is really what I mean and if someone is not goi= ng=20 to introduce a new IANA code which will better define my need? How do I=20 know what ISO meant when I know what IANA means. On an other end what=20 should I do when the IANA added code match my need but not the descriptio= n?=20 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, et= c.=20 outside of Internet documents and IANA except for IDNs. This obviously do= es=20 not help to identify this problem and I am taxed to underline it, people=20 focusing in the only example at hand, rather than on the fundamental pro= blem. RFC 3066 starts with the conclusion. The format proposed format should be= =20 tone of the conclusion of the analysis. As the use, as the registration=20 procedure, etc. Because you use a given format in a certain kind of=20 applications, you want to use that format for ever. By this token UNIX=20 would use DOS which would use DEC file format. Life is more flexible and=20 innovation comes from flexibility. The format you propose does not suit m= y=20 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=20 applications gives the feeling that RFC 3066 can conduct the world. The=20 idea that Countries may be taught to ask for ISO 3166 langtag compliant=20 codes from other countries experience seems odd. This also does not help to understand that you are shaking an existing=20 stable situation and status quo. But you actually come and propose change= s,=20 you do not care about those who are affected ("you" - at large - even wan= t=20 to expel them). Multilingual Internet The status quo is based upon the very low interest in multilingualism by=20 IAB. Demonstrated by the only RFC 3066, the low consideration of Paul=20 Hoffman's initial work, and the clear disinterest signal of the IAB's RFC= =20 3869 (which lists the development priorities to be funded by the=20 Governments - of every nations and languages - and does not even allude t= o=20 multilingualism). Now, you want to make it a core issue interfering with=20 the core issue of country codes through your ability to discuss ISO 3166,= =20 but more questioning the entire Internet architecture! To understand this, you have remember how a network is built. Every=20 network. Even if it is quite buried in the Internet defaults. A network=20 permits a class of users to relate with a group of resources in using=20 common identifier they register and manage in a registry (NIC) and=20 parameters they store in a common repository (IANA, CRC). The initial=20 international public network technology (1971) we deployed fully supporte= d=20 classes and groups and permitted to support an unlimited number of=20 national, linguistic, corporate, public interest externets (a class, a=20 group, a registry, a context supported by reference center). OSI principl= es=20 (1975?) reduced externets to the notion of closed user groups, making the= =20 class (users) and the group a single list. Internet (1978-83) as a privat= e=20 network internetting (Vint Cerf/Bob Khan) into a DoD catenet (Louis Pouzi= n)=20 only considered the Internet users class ("IN" and the "CHAOS" test class= )=20 and did not really mind about groups (DNS views can very partly reproduce= ,=20 as well as intra/extranets). This permitted to dramatically reduce the=20 intelligence expected from the network and to build a robust (but quite=20 rustic!) network based upon the two "core values": dumb network, end to e= nd. Now, multilingualism was initially started (Japan, EBCDIC and=20 France/Minitel) in using classes of non ASCII users interacting with grou= p=20 of resources able to respond them. This would correspond in the Internet = to=20 create 1.600.000 classes and to implement a group support which is totall= y=20 inexplored today. A totally new DNS technology. Also, to speed up routing= =20 the group support would probably call for a different IPv6 structuring su= ch=20 as the one proposed for the ITU-T /3 block. We will have to come to that,= =20 but not now! Let experiment the transition first. IDN introduced the idea of supporting multilingualism in the ASCII class = in=20 using internationalization. But this does not work because the analysis i= s=20 not correct. It just focused on the DN and not on the FQDN and introduced= a=20 hierarchy (punycode or not are filtered) in the label rather than in the=20 namespace. This means that they did not identified the need for virtual=20 zones (sub-classes in the IN class) and the need of consistence of the=20 vernacular (IDN Tables) used in that virtual zones. Result: the current=20 homographs problem. The correct solution consists in respecting the=20 standard network architecture in a scalable way and to force the=20 multilingual FQDN (FQMLDN) to be consistent from the TLD to the last leve= l.=20 Due to the inclusion on the IN class and its existing number of TLD there= =20 must be a _presentation_ of the zone (lingual SLD) as a single label (ex=20 nnn.chinesetag.cn being displayed as nnn.chinese_printing_of_cn) and a=20 filtering of all the codes which are not permitted in a correct FQMLDN. F= or=20 that all the concerned machine must have the necessary (limited)=20 information of how to present a lingual SLD as a lingual TLD, and the=20 corresponding IDN Table. There are three places to distribute them: eithe= r=20 the IANA and the CRCs, either a dynamic repository like Akamai, or the Lo= cales. So, you understand that langtags are actually the names of the lingual=20 externets or their aliases. Also, that depending on the way they are=20 organized, they may fit or not into the DNS as it is managed today. Also,= =20 that while the WSIS is discussing the intergovernance there are a lot of=20 interest to play it clearly, not to confuse the issues. Applications you consider only the applications you know. But you disregard the=20 applications others are/should be (:-) working on (like OPES at the WG-OP= ES=20 and ONES in other places, the CRCs as far I am concerned). And all those = a=20 correct support of multilingualism and vernacular could unlock. The web i= s=20 a dazibao. One does spend our life reading. As Hitch says: 90% of the hum= an=20 communication is not with words. This leaves a large number of=20 applications to develop. Their tagging needs are as much important than=20 any other. THE KEY ISSUE The key issue is what the langtag for? The charter says: they are necessary from (a) cataloging to (b) processin= g. You say: "Language tags (c) identify text, (d) not the processes that are= =20 applied to them". The Draft says: "This document describes the structure, content,=20 construction, and semantics of language tags for use in cases where it is= =20 desirable to (e) indicate the language used in an information object. " Introduction of the draft says: "(f) Information about a user's language=20 preferences commonly needs to be identified (g) so that appropriate=20 processing can be applied" Dictionary.com says: "indicate": (h) to show the way to or the direction of; point out: an arrow indicatin= g=20 north; indicated the right road by nodding toward it. (i) to serve as a sign, symptom, or token of; signify: "The cracking and=20 booming of the ice indicate a change of temperature" (Henry David Thoreau= ). (j) to suggest or demonstrate the necessity, expedience, or advisability=20 of: The symptoms indicate immediate surgery. (k) to state or express briefly: indicated his wishes in a letter;=20 indicating her approval with a nod. If the purpose is informative, the way I read (a), (c), (d), (e), (f), (i= ),=20 things are OK with me. If the purpose is normative, the way I read (b), (g), (h), (j) and possib= ly=20 (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=20 risen. They were used the way you say, to qualify/catalog texts in=20 different applications and for IDN Tables. But RFC 3066 - and you and Charter - uses a wording and you use examples=20 (Introduction) which creates ambiguity and confusion about the intended u= se=20 of the langtags. You can qualify a text with any descriptor you want, thi= s=20 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=20 need at least all the five the descriptors we described. This is not=20 something you can dispute or you kill the analysis you described as being= =20 also the RFC 3066 analysis. If you do not provide these 5 elements, you actually imply the defaults a= re=20 to be used. There is no default documented in the RFC 3066 and in your=20 draft, except the name of the registrant/referent. He the becomes the=20 default to tell what are the missing parameters. If the name is of a=20 person, the opposition to that person will unnecessarily creates an=20 opposition of the lingual community - even if the tag is correct. If the=20 name is of a corporation or associated to a corporation this may be worse= =20 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 i= ts=20 >>domain is an usual concept in the Internet culture. You can certainly=20 >>find other words. This is what says a computer that when I write in=20 >>French this is not Greek, or what make you sure that when I write in=20 >>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=20 >>you do not understand). >>- tools - options (preferences?) : dictionary, style (you need them to=20 >>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=20 points were not covered by Word and that your Word 2003 was great because= =20 it did not support RFC 3066 which was not yet published. Actually, I do u= se=20 Word. My copy is Word 97, and even in these ancient times, these points w= e=20 identified/share are here. It only add the proof of the age. >>This being said, I understand your remark about what I name the=20 >>multilingualization level. You say English is not defined. I belong to = a=20 >>culture where definition is known and supported for 4 centuries. This=20 >>makes me more aware of this point. Actually English, in a way is more=20 >>defined than French. When we introduce a computer in a culture, we do i= n=20 >>a few months, a few years, what Richelieu and France did a long ago and= =20 >>matured over centuries: we create an "Acad=E9mie de cette Langue". BTW this is probably a very interesting and exciting field of work. >>What I object is that this Acad=E9mie may belong to anyone else than to= the=20 >>people sharing that culture. And naming is already a way to own. As lon= g=20 >>as it is to qualify the culture it is OK because there is a need. When = it=20 >>comes to enter in its definition this is - IMHO - an intrusion. And I=20 >>refuse to share in that kind of intrusion. To the contrary my approach= =20 >>is to say we are here to serve, help, educate so they can first share i= n=20 >>this process, comment it and eventually conduct it for themselves. I fully understand and support (with may be some tunings, like the suppor= t=20 of namespace related information) the Unicode CLDR project - which is in=20 the IESG charter but not documented - I wonder why. But I would strongly=20 object to it if it was not carried under the supervision of Members of th= e=20 concerned communities. Frank hates Governments. I tend to think they are=20 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=20 >>probably 4. Because Greek persons stepped in and documented _their_ own= =20 >>languages. This is the way it should happen for every language, the=20 >>request should come from each Internet community. This is the spirit of= =20 >>the text of RFC 3066. I fully understand that people may want urgently=20 >>scan the cultural patrimonies of others, to sell it or to protect it fr= om=20 >>being merchandized, want to speed up the process. I do not think it is=20 >>commercially or charity advisable to by-pass their future=20 >>customers/friends in this process (as the reactions to the Google's=20 >>annoucement show it). To the contrary they should help empowering the=20 >>language and help their cultural, linguistic, political authorities=20 >>through the registration process. >> >>For example, I fully agree with you that the name of the langtag=20 >>registrant is not necessary. But I would suggest to remove it only when= =20 >>the registration is by an outsider. I note that if two languages are used at ISO (while UNESCO and ITU use 6=20 languages) there is probably good reasons, which may be to make sure that= =20 several and at least two cultures shared into the analysis (for defining=20 the tag and when using it). This forces an openness of mind we often need= .=20 It means alternative thinking, searching, etc. Back-up is always a good=20 thing. Two languages help also help the user to make sure the code she=20 wants to use is the good one. Acceptance of a bilingual table will be far= =20 higher in a multilingual context than an ASCII only table. Coopetition tends to foster quality. I hope that this will eventually help. jfc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D For your convenience: Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.t= xt 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 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." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 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 a= s possible, without of course using this argument to reject improvements." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --=====================_22284413==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA21388 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 t= he 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.

> - internationalizatio= n (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.

> > - multinationali= zation (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=20 "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 sayi= ng 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: =93The cracking an= d booming of the ice indicate a change of temperature=94 (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=E9mie de cette Langue".

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

What I object is that this Acad=E9mie 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






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
For your convenience:
If you were Bcced for information and not familliar with the IETF process:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
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."
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
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."
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
--=====================_22284413==.ALT-- --===============0520657625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0520657625==--