Re: [ga] IDN.IDN wikipedia, out of my league
On 21:02 11/04/2006, Simon Schuster said: I started a stub to the best of my ability, and I'll bet from reading the posts on this list, that this is probably low-priority, but if anyone has an account and an interest might want to help a sad stub of an article about an interesting issue. http://en.wikipedia.org/wiki/IDN.IDN
1. the Chinese set-up uses several "new to Internet" old architectural concepts I promised to document (but do not find the time to do). They set-up "TLDs" in a "DNS walled garden", the same as NeuStar did with ".gprs". We worked on that concept through an experimentation named "dot-root", addressing the ICANN ICP-3 request. We named that kind of "TLD" a "ULD" (User Level Domain). Many many people do this in their intranet walled garden. The difference is that the Chinese "DNS walled garden" is an externet, rather than an intranet. An externet is a very old notion the Internet can support but has not much used. It is an "external network look-alike within the network". This mean that an externet group of hosts (here referenced by the three Chinese ULDs) can only be targeted by their externet's classes of users, through methods building its walled garden. Here four methods are used. (1) ISP resolvers support direct resolution [China] (2) ISP are patched to provide a second step resolution just before a 404 [usually abroad] (3) users use a plug-in supporting the ULD as an 2LD or a 3LD for every applications (4) users chose a resolver that supports the ULD. Everyone can do this. 2. The IETF proposition actually includes two different propositions: (1) a Unicode/ASCII conversion named "punycode" (2) the IDNA. IDNA is a proposition to use punycode to internationalise the domain names at application level. IDNA is inadequate for TLD operators. It permits phishing when punycode is enabled. The "IDN.IDN" term is therefore actually absurd. IDN means "chinese.com". IDN.IDN therefore means "chinese.com.chinese.com". What it intends to mean is "punycoded(SLD).punycoded(language TLD)". IDN.IDN therefore presupposes the technology being used. It is therefore not transparent to the Internet ASCII Bias. However this ASCII Bias is necessary if one wants to keep the same zone as the ASCII TLD. 3. The real need is ML.ML. This means Multilingual. Multilingual name format. ML.ML _CAN_ be supported in using punycode or in using - one way or another - the or a Unicode charset, or other charsets. However the political, economical and architectural implications of the word "multilingual" are so significant that the IAB prefers continuing to say the word should not be used. While the IGF makes it a top priority. The IETF supports the US stakeholders Unicode "globalization" doctrine (Unicode executives, directors active contributors/influential persons are from Google, Yahoo! Cisco, IBM, MS, Apple, Verisign, etc.). The "globalization" purpose is to remove the language barriers between English speaking providers and foreign speakers in "internationalizing" the environment (ex. supporting punycoded TLD in the root) and "localizing" the ends (ex. running punycode to transcoded the IDN.IDN). It is embodied into the RFC 3066 Bis recently approved by the IESG. It supports an interesting possibility: to tag a limited number of languages (around 250 ... over 30.000 language units the world actually counts) using the same tag to name the locale files, the IANA IDN files, the content applications scopes, and even possibly the language TLDs, ... plus - de facto - the Internet traffic (a risk the IESG refused to document).. I oppose that doctrine for its English bias and risks of divide [balkanization]. I support Multilingualisation. This means giving everyone the same advantages as the English speakers can get (this is a fundamental Human Right). This is not easy with the current prevalent vision of the Internet technology inherited from OSI : they lack a interapplication layer between the network application layer (DNS, mail, etc.) and the user agents' application (the Browser, the Mail agent, etc.). This is far easier if one considers such an interapplication layer. BTW this is the layer of the NATs, of the middleboxes, etc. But it is also the layer of the WG-OPES (open pluggable edge services), so the IETF has an embryo of expertise which could be used. This is why the Multilingual Internet is a key change in the Internet architectural culture, restoring the possibilities offered by the first implementation of the International Services (IPSS, Tymnet). This is also a key change for us, the users. A better understanding of the externets and an adequate support of multilingualism will introduce possibilities, solutions, etc. leading for example to a distributed IANA and an IPv6 deployment for free. ICANN may loses control, RIRs may lose their revenues, Unicode will fail in their attempt to control OS's through an exclusive on locale files , the IAB/IETF may see the Internet technology documented elsewhere unless they decide to take the lead of the Multilingual Internet. They did not consider to take that lead, but to block the Multilingual Internet project by lack of interoperability with IANA registries. I defeated that exclusion in forcing the RFC 3066 Bis consensus I was denied. Interoperability will be possible from outside of the IETF. Then the WSIS decided the USA would keep control of the Internationalized US Externet and the IGF would take care of the Multilingual Internet. So, they suspended me ... permitting me to appeal to the IAB. The first time the IAB turned me right. The second time (I will send it in a few days) I just need its public answer. It will tell if the IESG is free or not to disrespect our FC 3066 Bis consensus, so the world know if they want Multilingual Internet to be interoperable or not with the Internationalised US Internet. It is sad a major evolution like Multilingual International Convergence Network leads to such contentions and exclusion attitudes, instead of resulting from an exciting consensual inter-cultural effort. The reason why is probably the mainly commercial funding of the Internet R&D. The IAB documents it (RFC 3869) as a major and an urgent problem. jfc
|