I hope you are keeping well. Here I am again back on the global info super freeway…no STOP signs, so I must continue my dialog with you. (pls refer to my comments in GREEN)
Thank you once again for all your comments and your efforts on the clarification. It really helped. I hope my late response did not create a gap with the momentum that started. I have to work for my living while I concurrently run research on a subject that probability is like riding a bicycle for you. I can only hope I have come back to you with something you may appreciate.
Sophia,
I needed to take some days to consider your note and, perhaps,
to let things calm down a bit (I, of course, don't know what
discussions have occurred on the GNSO Council list in the
interim). I hope the clarifications and comments below are
helpful, but suspect that we are nearing, and may have reached
or passed, the point at which further comments from either a
technical perspective, or even a "best interests of Internet
users" one, are useful.
I agree with you John and that is where I was fading away. Mind what started it all is a view questioned by many, a question of policy making over IDNs vs. the need to a technical testbed of a technology that is already well established. We need to find a way that IDN TLDs will be launched in the same process of new gTLDs i.e free for all open bid.
Having said that, I am no expert when it comes to the IDNs. The only things is I got hooked with the substance in the details, which seem more fascinating than the form. As it is eating away my brain cells one at a time, I may be inclined to hire a FULL TIME research assistance to keep up with you. In any case, I have laid out my thoughts and some of my fact findings for your interest, as well as defined some of the lingua franca of IDN to re-enforce for myslef and other interested readers.
John:
I am going to respond to both your note of the 6th and that of
the 5th below. My apologies in advance for the length of this
note, but I'm going to try to respond to a number of
almost-separate issues while trying to reduce the fairly obvious
level of confusion that underlies some of the questions and
assertions.
--On Monday, 06 February, 2006 00:00 -0800 Sophia B
<sophiabekele@gmail.com> wrote:
> Great...we are making the technical difference and that they
> can be separate .foo and .com and that they can be owned by
> two differ registrars and that could be competing with each
> other.
Noting that in most countries only one or two native languages dominate, while spending these hundreds of thousands of dollars translating/trademarking initially and then tens of thousands a year maintaining these trademarks in the 30 countries, domain names may have to be protected. To be reasonably complete, some 31 ascii ccTLD domains will be registered and an additional 31 (or more if more than one native language is desired per country and if transliterated as well as translated options are both considered) in native language IDN TLDs for that country/region will be registered. At prevailing domain costs per year the sum total cost of registering this amount of domains (ascii and IDN) to approximately "mimic" the trademark protection above should not exceed a couple of thousand dollars. In the context of trademarking, these domain costs should be probably a 100 times less than the initial trademarking related protection. And the "labor work" of registering already transliterated/translated and trademarked words/phrases as domain names is far less than the labor associated with trademarking.
So in short, from a biz perspective, the registering of IDN TLDs in addition to ascii TLDs in places is acceptable in view of the far greater cost/pain of the trademarking we already do today. As to whether it is wiser not to register domains in regions where trademark cover is already present inherently for domains, it is probably a legal decision depending on the strengths of the laws and the willingness of the courts of the country to actually uphold the law in a timely fashion during litigation. In fact given the cost metric outlined above I would think most companies would simply register it, rather than depend on the law to save them later.
Sophia:
Correct me if I am wrong, but URDP does not seem to have much to do with IDNs per se. I believe URDP- UNIFORM DISPUTE RESOLUTION POLICY- was developed several years ago.for the ascii domains by itu/icann/world intellectual property association (wipo) and adopted by all for resolving domain disputes – for clarification for all interested readers, this how it works…if you buy Dell's name Dell.com and insist on squatting on it - Dell argues trademarks on the basis of URDP to get it back. Over the past few years URDP more less in its intact ascii form is being used to idn as well - at least as in idn.com varieties and presumably will be pushed by icann for full idn tlds as well. (incidentally the Chinese have adapted a form of the URDP for their own use in Chinese idn tlds they have launched).
Computers can only think in ascii/english . So even multi-lingual domain names have to be finally represented in ascii/english gobbledygook. So for eg. a domain in Amharic (which is an Ethiopian native language BTW) will get converted by a set of rules (enshrined now in a IETF standard agreed to by all called the IDNA standard) that involve a language representation mechanism called unicode into ascii-string. The Amharic names gets represented in this example as say "800aavhbf1a". We can differentiate this "Amharic encoded" string as being different from a straight ascii string "800aavhbf1a" by tagging it with "xn--" in front of it. All "xn--" prefixes tell you its aâ non-ascii/english domain. (the encoding itself tells you which of many languages the domain itself is in - a singular appeal of the unicode language representation is that it represents all words in all languages mostly unambiguously inherently - it was developed by people having nothing to do with the internet over decades - linguists). In this case the domain tld is the normal ascii gtld ".com"...so we have an "Amharic domain represented in ascii gobbledegook".com . ".com" itself being an ascii tld need not be translated and represented as is. If we are proposing an Amharic word as a new Amharic gtld, then we need to convert that via unicode and idna rules to say a string "56yi0" and then we pre-pend with "xn-nn" to get the new amharic tlds representation in ascii as "xn--56i0" so we get the full domain " XN--800AAVHBF1A.xn--56i0". Note today if you wish to type the Amharic domains and you want your browser to understand it you will need a plug-in (except or mozilla which introduced it innately a few months ago) that helps the browser do the Amharic to "xn--" conversion via IDNA and then sends that converted name to ICANN roots (or alternate roots if the plug-in additionally supports such alternate roots). But if you already know the "xn--" version of that Amharic domain name you could use ANY existing browser without a plug-in and it will resolve it (you won't see Amharic characters but you will go to right web-site) as long as the relevant root is supported . In the case of the " xn-800AAVHBF1A.com" ".com" tld is supported by ICANN root so a regular browser will resolve this "xn" version automatically.
Certainly this is not my authorship, but my web-engineer stands corrected if his FACTS are wrong!
While surely people will fight over which new language tld will be better (ie. No different from in English trying to argue ".biz" is better than ".com" etc or ".xxx" is better than ".sex"), there is no technical limitation on selecting literally any of billions of idn tlds in the hundred of languages. There is hardly likely to be any conflict. If people in English could not agree on whether ".biz" is better or ".com" is better, give them both and see who succeeds. In fact this is exactly what happened in English in a way. There has been long a school of thought that the internet should have an unlimited number of top-level domain names - millions in English and otherwise. But there is absolutely no technical limitation and this has been shown over and over again by many experts over decades- Karl Auberach and many early icann board directors I understand, squealed for this - but icann has been resistance to give control with not a lot of justifiable reasoning I gather - it sort of defuses power as in politics.
I was captivatingly surprised to read the recent wall street journal article, which I have shared with you recently that a new company called uniroot, is selling anyone a tld they want (using sort of alternate roots) - a few years ago, I understand there was also another company that promoted that idea that died as well.
Second, relative to the "If we do end up with alternate roots, your ability to register "mybrand" in all TLDs, or even to know whether you have done so, would be severely compromised " comment, I must strongly disagree, eg. today if i want to buy an airline ticket i cannot go to single airline company and buy them. A travel agent may do the job for me. If I want a phone in a number of countries i can go and easily buy it wherever i want. Your statement implies a single phone vendor worldwide, which despite your inferences of course presumes English speaking and monopoly of money by western companies.
Actually even in domain names today, if I want to register my names in different cctlds i still have to go around and visit many different registries /registrars and buy them. Many countries do not use registrars. This is the way the world is.
And to the extent there is a market need for a single way to buy many different domains the 50,000 or more resellers in the world take care of it. Basically the proposal you mentioned is a centrally controlled, sort of a star trek future - where the whole world is one government controlled by one entity. Some may think that this view is of those who invented/controlled the internet and it fits with US political needs as well (a convenient excuse to control a world resource). Others would argue the opposite actually - by limiting all language domain registrations to de facto, a few global western registry/companies will ensure that they will not have the necessary local expertise in languages/culture to actually help the global company wishing to protect mybrand in all countries correctly. By employing different local groups to do so (which alternate roots will necessarily suggest) will do a better job of correctly protecting customer.
As for resellers and registrars offering everyone's products for one-stop shopping - today registrars are contacting many different registries in USA and all over the world cctlds registries (with all their odd rules - in Korea only Koreans with a soc sec number can register, in china even today individuals cannot register only companies, in Arabic countries - pornographic names cannot be registered, etc and we pay in all manner of local currencies over different terms - some countries only allow 10 year terms of registration) and offering them seamlessly to customers as it stands. Just like there are different registries supplied by a registrar, the registers will simply supply products from alternate root registries with their own rules and prices but all using same IDNA standard and Technology (that's what is important). Therefore I would not subscribe at all to the analogy of alternate roots would severely compromising mybrand registration . Its like saying democracy undermines order, which would be a statement that only a dictator would use and fool believes .
Sophia:
IDNA to reinforce my own and other readers understanding is the Internationalized Domain Names Applications standard agreed to buy IETF a few years back. It sets the rules for taking multilingual domains and converting them with the help of unicode into "ascii strings" pre-fixed by "xn--". Everybody has agreed almost completely to this technology including almost all the alternate root efforts (china included) and in fact the final standard is almost identical to the original idea proposed of all things by an ALTERNATE ROOT company - i-dns.net, when ICANN was not focusing to fulfill the need for IDN for many years.
Having said the above, these were my findings. The way of translating multilingual into ascii strings can be done in several different ways/formats (something trivial like writing left to right or right to left - just a format agreement like driving on left or right when there is a choice) - all these ways are called ACE encodings (ACE means ASCII Compatible Encoding i think). Originally i-dns.net proposed a particular ACE known as RACE as an interim standard (which Versign launched in its testbed/deployment) while IETF looked into agreeing to it or selecting a different one. (Launching technology with preliminary standard while IETF or ITU develops final standards is common practice on the Internet - example Real Networks video streaming, JPEG or 802.1g wi-fi). The Race encoded names were tagged "BQ--" in front of translated Amharic string. It could have been any tag - they more or less randomly chose BQ. After 3 years of debate (the longest ietf debate ever by a factor of 3x) IETF after discussing dozens of ACE formats had two finalists - the original RACE or a new version called PUNYCODE. Its really a trivial part of the whole IDN concept but one argument says that after 3 years the committee must have something tangible and different to show (not just a few minor unidentifiable changes in the guts of the details only) - so they went with punycode and IDNA was released enshrining punycode - and they essentially drew lots and randomly came up with "XN--" as the identifying tag for PUNYCODE (another member of ACE encodings) names. All new IDN names were tagged XN and everybody except Versign converted existing BQ to XN within a year. Eventually Versign did it as well.
Note: By the way the original tag was "BQ--" and not "BG--" as you stated John - a very trivial detail . A computer randomly was used to generate a two-letter tag in the case of XN - they sued closing prices of NASDAQ stocks average etc.
I think you misunderstood here. The usual differences arise when technical people use precise meanings of words, while others are accustomed to speaking in looser terms without loss of communication. I understand the testbed was initially in RACE and then it was converted to IDNA. Your answer seems to focus on that. The RACE/IDNA difference is not the point in my original comments.
By suggesting that the "long-term" solution was not addressed years ago, what I meant was, even to date (and that is years after Versign converted to IDNA) the IDN names that launched as a testbed in 2000 and then subsequently in 2003/4 converted to IDNA, are hardly usable anywhere where non-English languages matter. For the first few years there was no resolution either by way of plug-in distribution or other server-side solutions, then there has been a modest rise in plug-in distribution a year or two ago and then probably a relative decline since then.
Basically from the point of view of a non-English internet user outside of primarily the USA, these IDNs have been hardly usable and are not much used - and this after many other ascii TLDs have been allowed to launch (not as testbeds). I understand there is one argument for this is, that browser manufacturers are not under the direct control of ICANN etc. ie. Microsoft or left to private hands, that it costs them a lot of money to distribute plug-ins etc. It has also not been cost effective for these primarily Western companies to do distribute these plug-ins.
While these market problems are very real in the West/USA etc., they are no consolation to the multi-lingual end-user whom ICANN in my opinion has been less successful to date in serving. De facto ICANN is and is certainly seen as being in charge of the "Internet" and it would seem that if after 5+ plus years there has been very little usage or progress in the already launched IDN usability, ICANN could address the real issue – usability, Even if ICANN does not control the parties, for a comprehensive solution, it is my understanding that ICANN did not do much more to accelerate the process. Local efforts in countries with local laws seem to be overcoming these problems that ICANN has made, with only very little progress.
My purpose in bringing the Versign tetsbed up was for me to have some input/comments on this dead-on-arrival" status as regards usability that has plagued ICANN IDN launches so far How would we at ICANN avoid these prior usability problems before we go headlong into another launch - DNAMES or new TLDs? I am all for doing it but wish to ensure that we do not repeat the past. One would imagine that this needs to be sorted out before we experiment and launch. It is in this way of thinking that I suggest "policy usage" issues first. We had the technical launch before - ie. IDN.ascii - and it worked technically but why is nobody able to use it much in practice (yes - anyone can go to the link and download - that's not an answer to the real problem). The technology was successful, but the deployment has hardly been successful, while the need is clearly there why and how are we going to do better this time round?
Again, I am no DNS expert and am appreciating all the school-kid style education on the technical details of IDN but correct me if I am wrong - the early RACE encoded IDN names carried a "BQ--" designator rather than a "BG--" designator as you suggest above. I would assume in any language or script those are different?
Further research on browser technology: Native browsers until a year ago could not handle IDN for two reasons. First reason- they had to convert multilingual to Punycode "xn--" ascii-gobbledygook strings using IDNA standard. Second even if translated the domain name has to be sent to a root that understands it - either ICANN or alternate root. In the case of ICANN root, browser simply sends it to your ISP and they are set up to d fault send it to ICANN root. If your ISP is not (and unless someone went to every ISP and made them include alternate root information (a 2 minute procedure) as the Chinese govt. ordered to all isps in china), then the browser itself needs to recognize the fact that the name is an IDN and send it to the correct alternate root (browser needs address of alternate root if the ISP does not have it).
It is my understanding that ICANN has now or NEVER in 6 years told any ISP to add an alternate root location for obvious reasons. So unless you had billions to pay ISPs or you were China govt hard to get the world's 10,000 ISPs to do the 2 minute programming that is needed. So typical ISPs only point to ICANN root. So until a year ago no browser manufacturer did either. ( I think I brought this point at the DC GNSO meeting)
As a result, plug-ins were the rule - the original plug-in was developed by i-dns and Versign has licensed and re-branded for use and so have virtually everyone else in the world who launched IDN, including Chinese, Japanese, Arabs whether icann-sanctioned IDN or alternate root ones - copied or licensed the i-dns.net one. In the case of ICANN TLDs. the 2-language hybrid IDNS that ICANN has launched to date - ie. IDN.com variety - the plug-in is not required to handle the alternate root function - because you use the ICANN default root which your ISP knows anyway. So this single-function plug-in was distributed primarily by Verisign for their large testbed - and since. (Aflilias and Neulevel and JPNIC launched IDNs and sold some names but did not bother to develop their own plug-in for distribution and simply use their competitor's Versisgn's free plug-in to do so – that is that for innovation - they make money and would like to have IDN but are not spending money to make their own product - to versign's credit, it actually is doing that - the other's seem to be just making money on ICANN contracts - except of Versign they pretty much do not have an R and D group, I understand of any kind, let alone IDN. But it is interesting they all want DNAMEs though).
It is believed that ICANN also did not do much effort to develop or promote any plug-in, with anyone. Left to its own devices and with no support, unfortunately, I understand the plug-in deployment failed over 6 years - less than 100,000 plug-ins distributed in first 4 years and since maybe 4 million - almost all by Versisgn. And most of the 4 million where it is really not needed in USA and Scandinavia - no real need for IDN. ICANN could have allowed Versign and the other IDN ICANN registries to talk to local ISPs to alter their software even further - so that the translation step to xn-- could also be done at ISP server end - so need for plug-ins at all - a trivial thing that was originally proposed by IDN inventors - but this was rejected for what many think is no good reason by IETF and ICANN (ie. many think it was an ICANN vendetta against Verisign). So yes ICANN deployed but no one could use it.
The alternate root efforts have in some cases patched the ISP side and like in China can do without plug-in at all. ( I think this was what I was attempting to say at the DC meeting, but I was told ISPs do not need any patches, yes they do not if they adher to ICANN root). Other alternate root efforts use plug-ins (all derived from the early i-dns.net one) that both translate to xn-- and also point directly to alternate roots. But most efforts, like the Chinese, mix both server side patch and plug-ins to achieve maximum penetration. For later IDN email addreses, plug-ins are required - ISP patch is not enough for technical reasons. For example once they got serious, in 2 years, the Chinese have pushed out over 50 million plugins and patched enough ISPs by govt order to account for > 90% of China's 130M end-users. One alternate root company has thru ISP patch and plug-in distribution allowed 60% of Koreas's 36M internet population to access full Korean domains in about 2 years. Meanwhile even with Netscape being disbanded and handed over to Mozilla non-profit and they having agreed to support at least the IDN xn-- translation function innately last year and therefore ICANN IDN not requiring a plug-in if you use Netscape, is why I think the ICANN IDN experiment after 6 years seem to have resulted in utter tragedy in comparison, as far as usability.
Of course the natural attraction of DNAMEs is that each incumbent registry selects its own translation (without being sensitive to the local culture who have yet to be represented at ICANN . It's implication is those who already know best and who can profit the most can do it for you). In every language (even ones they have never heard of or have staff to handle) the whole problem is avoided. I think we should be reminded here that the internet is A GLOBAL POLICY MEDIUM. Its a GLOBAL COMMUNICATION SYSTEM and interestingly, for the first time in history, people are attempting to make the FIRST BOTTOM-UP GLOBALLY DESIGNED COMMUNICATIONS NETWORK. Phone companies are patchwork of national phone systems in comparison.
If Multilingual communication between people that will eventually handle virtually every form of communication (post office is dead, VOIP is coming) in a service-oriented (ie. data movement IS the ECONOMY - not goods) handle increasingly as much as 90% of commercial activity in a GLOBALised, OUT-sourced world and the addressing of one's IDENTITY and NAME in this end-all communication/business platform is what the Internet domain name system is about, SHOULD NOT THIS BE A GLOBAL POLICY PROBLEM.
Others again are in the view that if ICANN does not want to deal with it as a global problem, then we let it turn into a national sovereignty problem, with alternate roots that countries decide. The thought is that ICANN does not want it not to be global but chose to give it to incumbents - happens to be all the right people in the western companies, US govt, their friends etc. - all in their comfort zone - people who having signed onto ICANN for their bread-butter contracts can be depended upon to continue courting them . As such, a "not a global policy issue" can not pass or should not be commented as even reasonable to an ICANN BOARD - and Board members need to wake up to this. Ok, how does ICANN respond to this?
Note: My own observation for few months now, and having researched and talked with people interested in IDNs, I am inclined to deduce there a number of reasons why the IDN issues have not been pursued competently as well as why GNSO was silent:
I I see no issue with running experiments, but once again, we launched technology that worked before. The issue is not technology one would think. It is POLICY. Should we not settle on some idea of how policy-wise ICANN should delegate languages (if DNAMES) and TLDs (if new ones) or at least have some parallel debate. I understand the Katoh committees studied it in the past and had recommendations, but I have not heard any actual discussions on what the committee thought then about Policy. It appears to me from your comments that the Katoh-committee (spent far more time than we have so far I would have thought this time around) from a policy perspective (ie. bickering) had only a few recommendations to make - and one quite clearly recommended that new TLDs should be issued for IDN TLDs and that these TLDs should not be handed in a grandfathered way to existing gTLDs OR ccTLDs ... correct me if I am wrong.
That it should be brandname new "bids" by all-comers. If that reading is right, one would imagine while the technical merits of DNAMES were not discussed (or for that matter DNAMEs as an option was not brought up at all) the prevailing assumption that DNAMES will be a way of awarding existing ccTLDs and gTLDs equivalent IDN TLDs in effect would be counter to what the Katoh-committee was presumably explicitly trying to avoid - incumbents getting IDN TLD equivalents. (I understand in principle that new IDN TLDs can be deployed and DNAMES made only operational in that new IDN TLD as you point out later but I think most people in these discussions presume DNAMES implies incumbents eventually getting their IDN TLD equivalents in many languages - certainly in the Versign DNAME proposal that seems to have jump-started the current fascination with DNAMES that is their assumption/hope).
Again I am puzzled that after having gone to so much trouble and time we are now ignoring even a modest discussion of the original Katoh committee recommendations . They suggested various policies - long before any experiment. Now we seem to be going ahead without any policy discussion and worse ignoring the policy recommendations made earlier, straight to experiments. I must say I am puzzled.
Sophia:
It seems rather puzzling to me that, after 6 years or more of activity, the best that ICANN has done to date is to being able to deliver from "those of that have been sensitive to the needs of the non-US/non-West" is a two-language/script domain name. ie. the IDN.ascii-tld, technical people can make all the distinction they want but in general use you will never see any significant change I fear. eg. is I would not like the US passport agency to finally recognize that there are many Arab US citizens and that their passport should contain their personal name in the original Arabic and then proceed to write in their passport "Ismael" in Arabic and then "Mohammed" in English.
The whole point is to allow non-native English speakers to skip English in domain addressing . Making them type half in English is not really a solution?, becomes bad-mannered, if we were not all brainwashed to think that "English" is the "end-all". Worse, whether you need a plug-in or not, or if ISP or Microsoft patches it, these two-language domains will always require end-user to switch KEYBOARD from one language to another while typing a single domain name in a browser (in Hebrew and in Arabic also switch direction of typing). I gather this has been a huge problem , hardly anyone bothers to mention - because no one is really using these things after 6 years . But if you put IDN TLDs - alternate roots or ICANN root, with or without plug-in, this problem goes away - you do not need to switch keyboard settings halfway.
I find it hard to believe that this two-language oddity is what the non-English speaking people have wanted out of their internationalized Internet . It would seem anyone with any sensitivity to non-English languages using scripts far divergent from roman-like would want single language/script domains - to push the point home, I doubt there is much of a market for " arabic.hebrew" names. What I mean is, "Arabic" on left and "Hebrew" on right - two-language . Hebrew TLD and Arabic company domain name. This is the sort of thing I believe what ICANN has been launching for the past years - two languages, which has been criticized with the IDN community and has not found much of a user.
The more likely scenario would be that perhaps those who were "sensitive to the needs of the non-West" did not understand . The real reason might just have been technical and political convenience and incumbent-market economic convenience - none of it necessarily helpful to those who really need the internationalization. Technical, because less has to be changed (similar logic as in DNAMES for now I presume). Political, because there was no need to introduce new TLDs way back at a time when ICANN had other on-going battles to defend its authority and incumbent-market economics - it benefited the major existing registries - the early ones being commercial gTLDs or if ccTLDs, then privatized profit-making ones.
I bring this up not to apportion blame (even you conceded the initial launches were terrible and we don't need anyone to tell us that the whole IDN roll-out has been a practical failure in the general public's minds) but rather to counter your matter-of-fact assumed suggestion that "everything is in good hands and we have been sensitive to non-US/non-West needs". It is said that those who do not consider the past maybe doomed to repeat it. My real worry is that once again we may be going down a path of technical expediency ( eg. DNAMES) all the while insisting that we are "sensitive".
Given the past, in my opinion, to be truly "sensitive" one needs to consider the policy side of what we are about to before we embark headlong into another "better testbed" directed down a channel guided by technical expediency (possibly DNAMES) and by the identical commercial forces as before (Verisign initiated proposal). And add to that no one seems to even bothering to recall that a prior Katoh-led Committee spent substantial effort coming up with guidelines for the future may have specifically recommended against the path that things currently seem to be pointing - incumbent awarded mappings ie. DNAMES. If we have the same organization, possibly some of the same sensitive people, similar technical expediency directed technical solutions, same arguments, same commercial proposers – I doubt if we do we expect a different outcome?
Finally, I truly believe we need policy discussions first and should at least consider for discussion the Katoh-committee recommendations as a first step.
In any case in my understanding the DNAMEs approach is being championed right now - it was not the case I believe in the previous 6 years of ICANN IDN history. The Katon-committee didn't consider it after 3 years of IDN history at ICANN. If this thing has been around for as long as the Internet, then why all of a sudden this proposal is being championed - whatever the true reasons, it certainly has the suggestions of technical expediency in the face of potential external threats/pressure.
Well, its great that you bring up the Katoh-committee recommendations that you too seem to agree with , and at some level these are against the grain of the direction in which a DNAMES like deployment would head - awarding incumbent existing gTLD registries equivalents. Saying that DNAMEs is just a technology and how it need not be given to existing registries in principle is true technically. But the real issue is that's where it is likely to head and that's why the POLICY needs to be discussed first. Why are we not even discussing them after having invested so much time and effort on their recommendation?
I understand that the Versign testbed was done badly and everybody acknowledges that . Now when China came up with a solution they liked, it was already too late because we at ICANN had gone ahead and gone beyond "bad testbed' to actual production registrations under a few major commercial registries ( gTLDs and ccTLDs I guess) and it was too late to go back. Perhaps it is no little wonder that the same China and others are now forging their own path ahead. So two mistakes - not just one - presumably all driven by the stronger commercial registries wanting to increase sales in their existing ascii TLDs by way of promoting somewhat insulting two-language/script hybrid domain names.
If there is pressure from other sources - other than China to move - would it not be useful or proper for those of us who believe policy issues are equally or more important than technical testing of fairly well-established technology (perhaps as old as the Internet you suggested for DNAMES) to know what these "pressures" are if we as members of various ICANN boards have to endorse the eventual policy chosen. No matter what the spin from wherever, it is abundantly clear that the current IDN activity within ICANN after 2 or 3 year relative hiatus, is happening because of considerable external pressure . I am not sure I am speaking for all the GNSO members, but for my part I generally viewed the pressure from China as the biggest one while I have heard rumors of others and unhappiness from various other quarters . If as you say the pressure from China is not the main one and there are multiple others, it would appear that we would need to discuss this pronto!
Could someone please share this with us? So that our job is NOT to simply endorse everything.
Incidentally I would not be surprised if many of our board members learnt of the China deployed/commercial activity while reading a recent Wall Street Journal article. I have since learnt reliably that this activity was launched initially in a small way with full backing by their Ministry (published statements by Ministers) more than 4 years ago, and starting about 18 months ago it has been extensively deployed all over China. A large fraction of the 130M+ Chinese Internet population is already enabled-to use it and many tens of registrars have actually been selling these domains (which for all external purposes look like real IDN TLDs as described in the Wall Street Journal article) for well over a year and many tens of thousands of names registered and in use. A quick visit to the CNNIC web-site confirms all this.
It would be nice to know of these things earlier and not from the likes of the Wall Street journal.