<div>Greetings Tina:</div>
<div> </div>
<div>Thank you for your feedback. I believe the decision over policy vs. technical seem to be the concern here. I look forward to being part of the discussions in Wellington. <br> </div>
<div>Regards,</div>
<div>Sophia<br> </div>
<div><span class="gmail_quote">On 13/03/06, <b class="gmail_sendername">Tina Dam</b> <<a href="mailto:dam@icann.org">dam@icann.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Sophia, I will need to take some time to go through your entire email for<br>a full understanding or overview of your points. However, I wanted to reply
<br>to your email right away to provide some clarification in one area.<br><br>In the question about policy vs. technical and what comes first it is<br>important to understand that we don't know at this stage if DNAME or NS
<br>records will work well and keep the DNS stable and secure. So at this stage<br>there is not decision that either DNAME or NS records will be an option that<br>the GNSO can start developing policy around.<br><br>First we will be testing DNAME and NS records with IDN labels - when we know
<br>the result then we know what options we have for deployment and hence what<br>policy questions we need to answer. The GNSO obviously need to be fully<br>briefed on what is going on in term of the technical test.<br><br>
As we are getting really close to Wellington I hope we can spend some time<br>to talk over these various issues while there - either within the council or<br>in other groups as people may be available.<br><br>Best regards,
<br>Tina Dam<br>Chief gTLD Registry Liaison<br>ICANN<br><br>Office: +1-310-301-5838<br>Cell: +1-310-862-2026<br><br><br><br><br>________________________________<br><br> From: Sophia B [mailto:<a href="mailto:sophiabekele@gmail.com">
sophiabekele@gmail.com</a>]<br> Sent: Monday, March 13, 2006 11:04 AM<br> To: John C Klensin<br> Cc: Patrik Fältström; Marilyn Cade; Cary Karp; Tina Dam; GNSO<br>Council<br> Subject: Fwd: [council] Re: Regarding issues report on IDNs
<br><br><br> This is the revised version with "name" references for those whose<br>email do not allow the color option. Thanks Patrick. I hope this will<br>suffice. S<br><br> ---------- Forwarded message ----------
<br> From: Sophia B <<a href="mailto:sophiabekele@gmail.com">sophiabekele@gmail.com</a>><br> Date: 13-Mar-2006 07:36<br> Subject: Re: [council] Re: Regarding issues report on IDNs<br> To: John C Klensin <
<a href="mailto:klensin@jck.com">klensin@jck.com</a>><br> Cc: Patrik Fältström <<a href="mailto:paf@cisco.com">paf@cisco.com</a>>, Marilyn Cade<br><<a href="mailto:marilynscade@hotmail.com">marilynscade@hotmail.com
</a> >, Cary Karp <<a href="mailto:ck@nic.museum">ck@nic.museum</a>>, Tina Dam<br><<a href="mailto:dam@icann.org">dam@icann.org</a>>, GNSO Council <a href="mailto:council@gnso.icann.org">council@gnso.icann.org
</a><br><br><br><br> "Sophia"<br> Greetings John:<br><br><br><br> I hope you are keeping well. Here I am again back on the global<br>info super freeway…no STOP signs, so I must continue my dialog with you.
<br>(pls refer to my comments in GREEN)<br><br><br><br> Thank you once again for all your comments and your efforts on the<br>clarification. It really helped. I hope my late response did not create<br>a gap with the momentum that started. I have to work for my living while I
<br>concurrently run research on a subject that probability is like riding a<br>bicycle for you. I can only hope I have come back to you with something you<br>may appreciate.<br><br><br><br> I have observed from your last comments and clarifications that both
<br>of us have a proportional amount of agreements. Dispite your pointing to<br>the study of DNS, which I appreciate, my finding tells me that our<br>differences are more of a philosophical difference and than a major<br>
technical gap.<br><br><br> On 15/02/06, John C Klensin <<a href="mailto:klensin@jck.com">klensin@jck.com</a>> wrote:<br><br> Sophia,<br><br> I needed to take some days to consider your note and,
<br>perhaps,<br> to let things calm down a bit (I, of course, don't know what<br><br> discussions have occurred on the GNSO Council list in the<br> interim). I hope the clarifications and comments below are
<br> helpful, but suspect that we are nearing, and may have<br>reached<br> or passed, the point at which further comments from either a<br><br> technical perspective, or even a "best interests of Internet
<br> users" one, are useful.<br><br><br> Sophia<br><br> I agree with you John and that is where I was fading away. Mind<br>what started it all is a view questioned by many, a question of policy
<br>making over IDNs vs. the need to a technical testbed of a technology that is<br>already well established. We need to find a way that IDN TLDs will be<br>launched in the same process of new gTLDs i.e free for all open bid.
<br><br><br><br> Having said that, I am no expert when it comes to the IDNs. The<br>only things is I got hooked with the substance in the details, which seem<br>more fascinating than the form. As it is eating away my brain cells one at
<br>a time, I may be inclined to hire a FULL TIME research assistance to keep up<br>with you. In any case, I have laid out my thoughts and some of my fact<br>findings for your interest, as well as defined some of the lingua franca of
<br>IDN to re-enforce for myslef and other interested readers.<br><br><br> John:<br><br> I am going to respond to both your note of the 6th<br>and that of<br> the 5th below. My apologies in advance for the length of
<br>this<br> note, but I'm going to try to respond to a number of<br> almost-separate issues while trying to reduce the fairly<br>obvious<br> level of confusion that underlies some of the questions and
<br> assertions.<br><br> --On Monday, 06 February, 2006 00:00 -0800 Sophia B<br> <<a href="mailto:sophiabekele@gmail.com">sophiabekele@gmail.com</a>> wrote:<br><br> > Great...we are making the technical difference and that
<br>they<br> > can be separate .foo and .com and that they can be owned<br>by<br> > two differ registrars and that could be competing with<br>each<br> > other.<br><br><br>
John:<br> At one level, that has always been the case and is self-evident.<br> At another, it is extremely important that the Council<br> understand how the DNS actually works, what the four major
<br> internationalization options are, how different options are seen<br> by the user, and what their consequences and side-effects are in<br> order to discuss these topics... at least from any standpoint
<br> other than narrow self-interest.<br><br> Good tutorials on DNS operations, written with policy-makers in<br> mind, are available; if you haven't been given the references,<br> please ask.<br><br>
> That point made, what I am trying to address is 2<br> > business issues:<br> ><br> Sophia> 1- if 'mybrand' is to be protected i.e trademark in every<br> > country...it is a matter of purchasing all the 'mybrand'
<br> > TDLs...<br><br> John<br> It is at least a matter of "purchasing" 'mybrand' in _every_ TLD<br> or of convincing relevant TLDs to not permit it to be registered<br> (by you or anyone else). However, note that you may not be able
<br> to do this and you may not want to. Some countries require that<br> you have a business locus in those countries to register in<br> their TLDs, so, unless you open an office there, you may not be<br>
able to "buy" that name. In others, your ownership of a<br> well-known trademark (if "mybrand" is one) may be more than<br> sufficient to protect you: you may not have to actually<br>
"purchase" (register) the name and might actually be better off<br> not doing so. Even if you manage to control all of the<br> possible second-level domains of that name, you still need to<br>
make a judgment as to whether you have bought yourself adequate<br> protection. If "mybrand.TLD-name " is a problem for you,<br> "mybrand.some-SLD-name.TLD-name " may also be a problem. I note
<br> that, some years ago, a fairly well known trademark holder in<br> the US decided to take exception to names of the form<br> <a href="http://mickey.someschool.k12.fl.us">mickey.someschool.k12.fl.us
</a> <<a href="http://mickey.someschool.k12.fl.us/">http://mickey.someschool.k12.fl.us/</a>><br>and<br> <a href="http://minnie.someschool.k12.fl.us">minnie.someschool.k12.fl.us</a> <<a href="http://minnie.someschool.k12.fl.us/">
http://minnie.someschool.k12.fl.us/</a>><br><br><br> So far, none of this has anything to do with IDNs. It might be<br> an argument for not creating any more TLDs of any flavor, but it<br> is worth noting that a new TLD increases your problem by well
<br> under 1/2 percent if names below the second level are ignored<br> and by far less than that if they are considered.<br><br> The place where IDNs enter in depends on whether you believe<br> that, if you need to have control of every instance of "mybrand"
<br> in the DNS, you also need control of "muybrand" and<br> "meinefabrikzeichen" (both of which can be perfectly well<br> expressed in ASCII characters) or "xn--80aanvhbf1a" and a huge
<br> variety of other synonyms and translations. One can, of course,<br> make a case that you are entitled to, or should protect, all of<br> those things (of which there are many thousands) but one could
<br> also suggest that, at some point, silliness sets in.<br><br> Sophia<br> I do not see a big problem with this, as long as protection of say<br>for example an "English" trademark in different countries (in English, as
<br>well when translated into that countries native languages) can be achieved<br>at a cost that is far less than what it takes to trademark these things in<br>the first place in each country,. For example if one had an ascii brand
<br>name in say USA and then a company trademarked in 30 countries, they are<br>likely to (a) pay 31 times for "English language" trademarking fees at as<br>much as $1000 or more in each country and periodic/yearly maintenance fees
<br>at some small fraction of that and (b) inclined to translate/transliterate<br>(or both) that English brand name into 31 different native languages and<br>then trademark all of them - ie. 30 times another $1000 assuming only one
<br>native language per country, plus periodic maintenance fees for that and (c)<br>pay for all those 30 or more translations in the first place - decent<br>translations can easily cost $1000 or more and (d) perhaps pay also having
<br>to trademark transliterations as well as translations in each native<br>language in each selected country.<br><br><br><br> Noting that in most countries only one or two native languages<br>dominate, while spending these hundreds of thousands of dollars
<br>translating/trademarking initially and then tens of thousands a year<br>maintaining these trademarks in the 30 countries, domain names may have to<br>be protected. To be reasonably complete, some 31 ascii ccTLD domains will be
<br>registered and an additional 31 (or more if more than one native language is<br>desired per country and if transliterated as well as translated options are<br>both considered) in native language IDN TLDs for that country/region will be
<br>registered. At prevailing domain costs per year the sum total cost of<br>registering this amount of domains (ascii and IDN) to approximately "mimic"<br>the trademark protection above should not exceed a couple of thousand
<br>dollars. In the context of trademarking, these domain costs should be<br>probably a 100 times less than the initial trademarking related protection.<br>And the "labor work" of registering already transliterated/translated and
<br>trademarked words/phrases as domain names is far less than the labor<br>associated with trademarking.<br><br><br><br> So in short, from a biz perspective, the registering of IDN TLDs in<br>addition to ascii TLDs in places is acceptable in view of the far greater
<br>cost/pain of the trademarking we already do today. As to whether it is wiser<br>not to register domains in regions where trademark cover is already present<br>inherently for domains, it is probably a legal decision depending on the
<br>strengths of the laws and the willingness of the courts of the country to<br>actually uphold the law in a timely fashion during litigation. In fact given<br>the cost metric outlined above I would think most companies would simply
<br>register it, rather than depend on the law to save them later.<br><br><br><br> If the need to register many domains while trying to mimic the<br>tradmarking activity already embarked upon reaches the point of "silliness",
<br>the trademarking activity itself will have reached a point of far more<br>costlier silliness well before that. So I am not sure if we need to worry<br>about "silliness". I think the market will take care of itself just as the
<br>market today knows not to trademark in every language and every country etc.<br><br> Sophia<br><br> Sophia> 2-on the other hand, if mybarnd .com is to be protected 'in<br> > every language' under gTLD, then 'com' in every language over
<br> > 200 translation need to be protected and approved by ICANN.<br><br> John:<br> First, as I think Cary has pointed out, "every language" puts<br> one somewhere in the 6000 range, not 200. What is more
<br> important is that this problem exists today, with no further<br> action being required on the part of ICANN. Using the<br> admittedly crude examples above, " <a href="http://muybrand.com">muybrand.com
</a><br><<a href="http://muybrand.com/">http://muybrand.com/</a>> ",<br> " <a href="http://meinefabrikzeichen.com">meinefabrikzeichen.com</a> <<a href="http://meinefabrikzeichen.com/">http://meinefabrikzeichen.com/
</a>> ", and "<br><a href="http://xn--80aanvhbf1a.com">xn--80aanvhbf1a.com</a> <<a href="http://xn--80aanvhbf1a.com/">http://xn--80aanvhbf1a.com/</a>> " could be<br> registered tomorrow if they have not been registered already.
<br> The only nuance that an IDN TLD system would add is the ability<br> to refer to " <a href="http://xn--80aanvhbf1a.com">xn--80aanvhbf1a.com</a> <<a href="http://xn--80aanvhbf1a.com/">http://xn--80aanvhbf1a.com/
</a>> "<br>as something like<br> "xn--80aanvhbf1a.xn--e1aajebclaqxm4e" (if using DNAMES or local<br> aliases) or to register "mybrand.xn--e1aajebclaqxm4e" and<br> "xn--80aanvhbf1a.xn--e1aajebclaqxm4e
" in a new domain if<br> separate domains were created.<br><br> Sophia> So the guardians of this names i.eVerisign etc.. will be<br> > translating and registering them. ARe they passing<br> > the cost to the customer? Are we going to approve over 200
<br> > maybe thousands of translations?<br><br> John:<br> This is, again, a situation in which being very clear about how<br> the DNS actually works and about what one is talking about as a<br> result is very important. For example, if the DNAME approach is
<br> used, and a DNAME record named .xn--e1aajebclaqxm4e is installed<br> pointing to .COM, then there is no difference between<br> <a href="http://mybrand.com">mybrand.com</a> <<a href="http://mybrand.com/">
http://mybrand.com/</a>> and<br>mybrand.xn--e1aajebclaqxm4e<br><br> they are the same set of record entries. By contrast, whether<br> or not "<a href="http://xn--80aanvhbf1a.com">xn--80aanvhbf1a.com</a>
<<a href="http://xn--80aanvhbf1a.com/">http://xn--80aanvhbf1a.com/</a>> " could<br>be registered, and on what<br> basis, is strictly a registrar issue with the standard fee<br> structure -- I believe that name could be registered today and
<br> that, if you didn't like it, you would need to go through a<br> standard UDRP procedure.<br><br><br><br> Sophia:<br><br> Correct me if I am wrong, but URDP does not seem to have much to do<br>
with IDNs per se. I believe URDP- UNIFORM DISPUTE RESOLUTION POLICY- was<br>developed several years ago.for the ascii domains by itu/icann/world<br>intellectual property association (wipo) and adopted by all for resolving
<br>domain disputes – for clarification for all interested readers, this how it<br>works…if you buy Dell's name <a href="http://Dell.com">Dell.com</a> <<a href="http://dell.com/">http://dell.com/</a>> and insist on
<br>squatting on it - Dell argues trademarks on the basis of URDP to get it<br>back. Over the past few years URDP more less in its intact ascii form is<br>being used to idn as well - at least as in <a href="http://idn.com">
idn.com</a> <<a href="http://idn.com/">http://idn.com/</a>><br>varieties and presumably will be pushed by icann for full idn tlds as well.<br>(incidentally the Chinese have adapted a form of the URDP for their own use
<br>in Chinese idn tlds they have launched).<br><br><br><br> Computers can only think in ascii/english . So even multi-lingual<br>domain names have to be finally represented in ascii/english gobbledygook.<br>So for eg. a domain in Amharic (which is an Ethiopian native language BTW)
<br>will get converted by a set of rules (enshrined now in a IETF standard<br>agreed to by all called the IDNA standard) that involve a language<br>representation mechanism called unicode into ascii-string. The Amharic<br>
names gets represented in this example as say "800aavhbf1a". We can<br>differentiate this "Amharic encoded" string as being different from a<br>straight ascii string "800aavhbf1a" by tagging it with "xn--" in front of
<br>it. All "xn--" prefixes tell you its aâ non-ascii/english domain. (the<br>encoding itself tells you which of many languages the domain itself is in -<br>a singular appeal of the unicode language representation is that it
<br>represents all words in all languages mostly unambiguously inherently - it<br>was developed by people having nothing to do with the internet over decades<br>- linguists). In this case the domain tld is the normal ascii gtld
<br>".com"...so we have an "Amharic domain represented in ascii<br>gobbledegook".com . ".com" itself being an ascii tld need not be translated<br>and represented as is. If we are proposing an Amharic word as a new Amharic
<br>gtld, then we need to convert that via unicode and idna rules to say a<br>string "56yi0" and then we pre-pend with "xn-nn" to get the new amharic tlds<br>representation in ascii as "xn--56i0" so we get the full domain "
<br>XN--800AAVHBF1A.xn--56i0". Note today if you wish to type the Amharic<br>domains and you want your browser to understand it you will need a plug-in<br>(except or mozilla which introduced it innately a few months ago) that helps
<br>the browser do the Amharic to "xn--" conversion via IDNA and then sends that<br>converted name to ICANN roots (or alternate roots if the plug-in<br>additionally supports such alternate roots). But if you already know the
<br>"xn--" version of that Amharic domain name you could use ANY existing<br>browser without a plug-in and it will resolve it (you won't see Amharic<br>characters but you will go to right web-site) as long as the relevant root
<br>is supported . In the case of the " xn-800AAVHBF1A.com" ".com" tld is<br>supported by ICANN root so a regular browser will resolve this "xn" version<br>automatically.<br><br><br><br> Certainly this is not my authorship, but my web-engineer stands
<br>corrected if his FACTS are wrong!<br><br><br> John:<br> I would hope that, were ICANN to be willing to install a<br> top-level DNAME record with the label of xn--e1aajebclaqxm4e,<br> that there would be some cost-recovery for doing so, but the
<br> amounts would not be large. The question of which of well over<br> 6000 DNAMEs would be inserted pointing to COM and how they would<br> be chosen is a pure policy issue. And, were ICANN willing to
<br> create a separate top-level domain for xn--e1aajebclaqxm4e, the<br> registration policies for that domain would be ... well,<br> whatever was proposed and accepted.<br><br> Sophia:<br> I think you have precisely nailed it. Policy first or at
<br>least in parallel. Experience showed in past icann launches, that<br>technology was far lesser problem, policy was far more important. In the<br>end the technology worked, but in practice deployment, unfortunately, it
<br>proved an abject failure 6 years later. II think it is because ICANN did<br>not follow-up with the policy to ensure after deployment worked, no one<br>argued etc. and it might be off to be repeated it again.<br><br>
Sophia> What are the implications above?<br><br> John:<br> The implications clearly differ with the technology chosen. As<br> I (and others) have pointed out before, few of the existing TLD<br>
names actually represent words in English (or any other<br> language), so the matter of translations would be difficult and<br> might call for some policy decisions. If one were trying to<br> minimize policy issues, the DNAMEs or are clearly the better
<br> approach of those involving root changes and local aliases are a<br> better approach yet. Presumably, if new names are going to be<br> placed in the root (for either DNAME or delegation records),<br>
some procedure will need to be devised for applying for and<br> registering those names and I would not predict that it will be<br> easy to devise such a procedure while still being sufficiently<br> fair to all language groups to minimize the risk of people
<br> feeling that they are forced into the development of alternate<br> roots. If we do end up with alternate roots, your ability to<br> register "mybrand" in all TLDs, or even to know whether you have
<br> done so, would be severely compromised.<br><br> Sophia:<br> I see the very heart of the problem here – I distaste bringing up<br>east vs west, because personally, I love American steak and Chinese noodles,
<br>but it is the reality and your statement is a bit of icann/west view for my<br>taste. First, what you are saying is that people will fight over which new<br>tlds to choose in new languages, so its perhaps better to just remain with
<br>the existing tld names in ascii and simply translate/transliterate them, of<br>course you also say that the existing tlds have no literal meaning ( who is<br>to say that .com really means commercial , it could mean ".come here
<br>darling" OR ".CN" MEANS "CHINA" RATHER than a short-code for all "sin"<br>WEB-SITES), so translating them meaningless words would in my opinion be<br>just as problematic.<br><br><br>
<br> While surely people will fight over which new language tld will be<br>better (ie. No different from in English trying to argue ".biz" is better<br>than ".com" etc or ".xxx" is better than ".sex"), there is no technical
<br>limitation on selecting literally any of billions of idn tlds in the hundred<br>of languages. There is hardly likely to be any conflict. If people in<br>English could not agree on whether ".biz" is better or ".com" is better,
<br>give them both and see who succeeds. In fact this is exactly what happened<br>in English in a way. There has been long a school of thought that the<br>internet should have an unlimited number of top-level domain names -
<br>millions in English and otherwise. But there is absolutely no technical<br>limitation and this has been shown over and over again by many experts over<br>decades- Karl Auberach and many early icann board directors I understand,
<br>squealed for this - but icann has been resistance to give control with not a<br>lot of justifiable reasoning I gather - it sort of defuses power as in<br>politics.<br><br><br><br> I was captivatingly surprised to read the recent wall street journal
<br>article, which I have shared with you recently that a new company called<br>uniroot, is selling anyone a tld they want (using sort of alternate roots) -<br>a few years ago, I understand there was also another company that promoted
<br>that idea that died as well.<br><br><br><br> Second, relative to the "If we do end up with alternate roots, your<br>ability to register "mybrand" in all TLDs, or even to know whether you have<br>done so, would be severely compromised " comment, I must strongly disagree,
<br>eg. today if i want to buy an airline ticket i cannot go to single airline<br>company and buy them. A travel agent may do the job for me. If I want a<br>phone in a number of countries i can go and easily buy it wherever i want.
<br>Your statement implies a single phone vendor worldwide, which despite your<br>inferences of course presumes English speaking and monopoly of money by<br>western companies.<br><br><br><br> Actually even in domain names today, if I want to register my names
<br>in different cctlds i still have to go around and visit many different<br>registries /registrars and buy them. Many countries do not use registrars.<br>This is the way the world is.<br><br><br><br> And to the extent there is a market need for a single way to buy
<br>many different domains the 50,000 or more resellers in the world take care<br>of it. Basically the proposal you mentioned is a centrally controlled,<br>sort of a star trek future - where the whole world is one government
<br>controlled by one entity. Some may think that this view is of those who<br>invented/controlled the internet and it fits with US political needs as well<br>(a convenient excuse to control a world resource). Others would argue the
<br>opposite actually - by limiting all language domain registrations to de<br>facto, a few global western registry/companies will ensure that they will<br>not have the necessary local expertise in languages/culture to actually help
<br>the global company wishing to protect mybrand in all countries correctly. By<br>employing different local groups to do so (which alternate roots will<br>necessarily suggest) will do a better job of correctly protecting customer.
<br><br> As for resellers and registrars offering everyone's products for<br>one-stop shopping - today registrars are contacting many different<br>registries in USA and all over the world cctlds registries (with all their
<br>odd rules - in Korea only Koreans with a soc sec number can register, in<br>china even today individuals cannot register only companies, in Arabic<br>countries - pornographic names cannot be registered, etc and we pay in all
<br>manner of local currencies over different terms - some countries only allow<br>10 year terms of registration) and offering them seamlessly to customers as<br>it stands. Just like there are different registries supplied by a registrar,
<br>the registers will simply supply products from alternate root registries<br>with their own rules and prices but all using same IDNA standard and<br>Technology (that's what is important). Therefore I would not subscribe at
<br>all to the analogy of alternate roots would severely compromising mybrand<br>registration . Its like saying democracy undermines order, which would be a<br>statement that only a dictator would use and fool believes .
<br><br><br> --On Sunday, 05 February, 2006 23:23 -0800 Sophia B<br> <<a href="mailto:sophiabekele@gmail.com">sophiabekele@gmail.com</a>> wrote:<br> >...<br> > Please allow me to present this historic perspective, as well
<br> > as some relative considerations regarding the IDNs.<br> ><br> > 1) It is my understanding that ICANN has a fully authorized<br> > TESTBED still ongoing with VERISIGN, operating almost 200
<br> > languages under ".com". It is also my understanding that the<br> > author of the DNAME proposal draft (published in Vancouver) is<br> > from VERISIGN (they are the champions of this and the author
<br> > of the document is a fellow who launched the first Versign<br> > testbed. Is it also a fact, pls correct me if I am wrong, to<br> > state that this process sold 1 million names in 200 languages,
<br> > but really did not address the long-term solution? uhmm.<br><br> John:<br> I am no particular friend of Verisign's or their behavior, but I<br> believe the explanation above is somewhat distorted. As I
<br> understand it, the vast majority of the names registered under<br> the testbed have been converted to IDNA names and the relevant<br> fees paid for standard registrations. More important, despite<br>
my use of some of them in the examples above, no one really<br> wants to type in, or look at, any of these ACE-encoded names.<br> In general, if I use one of the IDNA (punycode, as above) names<br> in a DNS name context any modern/contemporary browser, I will
<br> see the native characters associated with that name. But<br> nothing contemporary supports the "RACE" names that were used in<br> the testbed. So, unless one finds a string starting with "bg--"
<br> and followed by an arbitrary-looking collection of characters to<br> be amusing or of mnemonic value, that testbed, however badly it<br> was handled, is now irrelevant.<br><br><br> Sophia:<br>
<br> IDNA to reinforce my own and other readers understanding is the<br>Internationalized Domain Names Applications standard agreed to buy IETF a<br>few years back. It sets the rules for taking multilingual domains and
<br>converting them with the help of unicode into "ascii strings" pre-fixed by<br>"xn--". Everybody has agreed almost completely to this technology<br>including almost all the alternate root efforts (china included) and in fact
<br>the final standard is almost identical to the original idea proposed of all<br>things by an ALTERNATE ROOT company - <a href="http://i-dns.net">i-dns.net</a> <<a href="http://i-dns.net/">http://i-dns.net/</a>> , when
<br>ICANN was not focusing to fulfill the need for IDN for many years.<br><br><br><br> Having said the above, these were my findings. The way of<br>translating multilingual into ascii strings can be done in several different
<br>ways/formats (something trivial like writing left to right or right to left<br>- just a format agreement like driving on left or right when there is a<br>choice) - all these ways are called ACE encodings (ACE means ASCII
<br>Compatible Encoding i think). Originally <a href="http://i-dns.net">i-dns.net</a> <<a href="http://i-dns.net/">http://i-dns.net/</a>><br>proposed a particular ACE known as RACE as an interim standard (which<br>
Versign launched in its testbed/deployment) while IETF looked into agreeing<br>to it or selecting a different one. (Launching technology with preliminary<br>standard while IETF or ITU develops final standards is common practice on
<br>the Internet - example Real Networks video streaming, JPEG or 802.1g wi-fi).<br>The Race encoded names were tagged "BQ--" in front of translated Amharic<br>string. It could have been any tag - they more or less randomly chose BQ.
<br>After 3 years of debate (the longest ietf debate ever by a factor of 3x)<br>IETF after discussing dozens of ACE formats had two finalists - the original<br>RACE or a new version called PUNYCODE. Its really a trivial part of the
<br>whole IDN concept but one argument says that after 3 years the committee<br>must have something tangible and different to show (not just a few minor<br>unidentifiable changes in the guts of the details only) - so they went with
<br>punycode and IDNA was released enshrining punycode - and they essentially<br>drew lots and randomly came up with "XN--" as the identifying tag for<br>PUNYCODE (another member of ACE encodings) names. All new IDN names were
<br>tagged XN and everybody except Versign converted existing BQ to XN within a<br>year. Eventually Versign did it as well.<br><br><br><br> Note: By the way the original tag was "BQ--" and not "BG--" as you
<br>stated John - a very trivial detail . A computer randomly was used to<br>generate a two-letter tag in the case of XN - they sued closing prices of<br>NASDAQ stocks average etc.<br><br><br> John:<br> Verisign has permission to register IDNA names in COM and NET
<br> and has had it for several years. As far as I know, every other<br> gTLD that has asked for permission to register IDNA-style IDNs<br> has gotten that permission. These are not for testbeds, they<br>
are for production registrations.<br><br> Sophia:<br> I would say yes to this of course, but my research tells me<br>that no one uses them. The Chinese from day one in 2000 used their<br>ambassadors and their ministers to protest internationally and to this day
<br>more or less block it for use within China. All of these are two language<br>hybrids ie. native language.ascii-cctld. ie. half my name for eg. in Amharic<br>and the other half in English. Totally offensive and does not really help
<br>the non-English speaker who cannot type English, even worst, in most cases<br>the non-English speaker has to change KEYBOARD SETTINGS from one language to<br>another half way through typing a single domain name. I understand - yes
<br>some people bought them to protect their names but the average non-English<br>speaker who needs IDN has almost never used them. Probably less than 1%<br>of names ever bought under these are actually used or usable. And the
<br>total number of all ICANN approved IDN names registered today is probably<br>less than 500,000 - mostly in .com. - after 6 years . And most are not<br>hosted and the 1% or less that is hosted are actually not used, because
<br>ICANN was not able to make them usable by the people who need it. Wow,<br>contrast that with China, who after getting serious about their alterative<br>root (started in 2001), about two years ago, that have over 100M people
<br>being able to use it - only 300M truly IDN needing Internet users in the<br>world (note French, Latin, Germans, can use ascii for the most part<br>happily). I hope this are statistics that are not was off base, if so, I
<br>would need an issues report, to contrast that, like Marylin Cade would say.<br><br> John:<br> Now, I believe that testbed was very badly handled and that the<br> way it was approved and handled reflects badly on ICANN (staff,
<br> Board, and the then DNSO Council) and on Verisign. My proposal<br> that we be quite aggressive in being sure that "tests" are<br> actually tests and not some sort of early-start mechanism was
<br> developed precisely because of that experience. We should at<br> least avoid making the same mistake a second time. More on this<br> below.<br><br> Sophia:<br><br> I think you misunderstood here. The usual differences arise when
<br>technical people use precise meanings of words, while others are accustomed<br>to speaking in looser terms without loss of communication. I understand the<br>testbed was initially in RACE and then it was converted to IDNA. Your answer
<br>seems to focus on that. The RACE/IDNA difference is not the point in my<br>original comments.<br><br><br><br> By suggesting that the "long-term" solution was not addressed years<br>ago, what I meant was, even to date (and that is years after Versign
<br>converted to IDNA) the IDN names that launched as a testbed in 2000 and then<br>subsequently in 2003/4 converted to IDNA, are hardly usable anywhere where<br>non-English languages matter. For the first few years there was no
<br>resolution either by way of plug-in distribution or other server-side<br>solutions, then there has been a modest rise in plug-in distribution a year<br>or two ago and then probably a relative decline since then.<br><br>
<br><br> Basically from the point of view of a non-English internet user<br>outside of primarily the USA, these IDNs have been hardly usable and are not<br>much used - and this after many other ascii TLDs have been allowed to launch
<br>(not as testbeds). I understand there is one argument for this is, that<br>browser manufacturers are not under the direct control of ICANN etc. ie.<br>Microsoft or left to private hands, that it costs them a lot of money to
<br>distribute plug-ins etc. It has also not been cost effective for these<br>primarily Western companies to do distribute these plug-ins.<br><br><br><br> While these market problems are very real in the West/USA etc., they
<br>are no consolation to the multi-lingual end-user whom ICANN in my opinion<br>has been less successful to date in serving. De facto ICANN is and is<br>certainly seen as being in charge of the "Internet" and it would seem that
<br>if after 5+ plus years there has been very little usage or progress in the<br>already launched IDN usability, ICANN could address the real issue –<br>usability, Even if ICANN does not control the parties, for a<br>
comprehensive solution, it is my understanding that ICANN did not do much<br>more to accelerate the process. Local efforts in countries with local<br>laws seem to be overcoming these problems that ICANN has made, with only
<br>very little progress.<br><br><br><br> My purpose in bringing the Versign tetsbed up was for me to have<br>some input/comments on this dead-on-arrival" status as regards usability<br>that has plagued ICANN IDN launches so far How would we at ICANN avoid
<br>these prior usability problems before we go headlong into another launch -<br>DNAMES or new TLDs? I am all for doing it but wish to ensure that we do<br>not repeat the past. One would imagine that this needs to be sorted out
<br>before we experiment and launch. It is in this way of thinking that I<br>suggest "policy usage" issues first. We had the technical launch before -<br>ie. IDN.ascii - and it worked technically but why is nobody able to use it
<br>much in practice (yes - anyone can go to the link and download - that's not<br>an answer to the real problem). The technology was successful, but the<br>deployment has hardly been successful, while the need is clearly there why
<br>and how are we going to do better this time round?<br><br><br><br> Again, I am no DNS expert and am appreciating all the school-kid<br>style education on the technical details of IDN but correct me if I am wrong
<br>- the early RACE encoded IDN names carried a "BQ--" designator rather than a<br>"BG--" designator as you suggest above. I would assume in any language or<br>script those are different?<br><br><br>
<br> Further research on browser technology: Native browsers until a<br>year ago could not handle IDN for two reasons. First reason- they had to<br>convert multilingual to Punycode "xn--" ascii-gobbledygook strings using
<br>IDNA standard. Second even if translated the domain name has to be sent to a<br>root that understands it - either ICANN or alternate root. In the case of<br>ICANN root, browser simply sends it to your ISP and they are set up to d
<br>fault send it to ICANN root. If your ISP is not (and unless someone went to<br>every ISP and made them include alternate root information (a 2 minute<br>procedure) as the Chinese govt. ordered to all isps in china), then the
<br>browser itself needs to recognize the fact that the name is an IDN and send<br>it to the correct alternate root (browser needs address of alternate root if<br>the ISP does not have it).<br><br> It is my understanding that ICANN has now or NEVER in 6 years told
<br>any ISP to add an alternate root location for obvious reasons. So unless you<br>had billions to pay ISPs or you were China govt hard to get the world's<br>10,000 ISPs to do the 2 minute programming that is needed. So typical ISPs
<br>only point to ICANN root. So until a year ago no browser manufacturer did<br>either. ( I think I brought this point at the DC GNSO meeting)<br><br><br><br> As a result, plug-ins were the rule - the original plug-in was
<br>developed by i-dns and Versign has licensed and re-branded for use and so<br>have virtually everyone else in the world who launched IDN, including<br>Chinese, Japanese, Arabs whether icann-sanctioned IDN or alternate root ones
<br>- copied or licensed the <a href="http://i-dns.net">i-dns.net</a> <<a href="http://i-dns.net/">http://i-dns.net/</a>> one. In the case of<br>ICANN TLDs. the 2-language hybrid IDNS that ICANN has launched to date - ie.
<br>IDN.com variety - the plug-in is not required to handle the alternate root<br>function - because you use the ICANN default root which your ISP knows<br>anyway. So this single-function plug-in was distributed primarily by
<br>Verisign for their large testbed - and since. (Aflilias and Neulevel and<br>JPNIC launched IDNs and sold some names but did not bother to develop<br>their own plug-in for distribution and simply use their competitor's
<br>Versisgn's free plug-in to do so – that is that for innovation - they make<br>money and would like to have IDN but are not spending money to make their<br>own product - to versign's credit, it actually is doing that - the other's
<br>seem to be just making money on ICANN contracts - except of Versign they<br>pretty much do not have an R and D group, I understand of any kind, let<br>alone IDN. But it is interesting they all want DNAMEs though).<br>
<br><br><br> It is believed that ICANN also did not do much effort to develop or<br>promote any plug-in, with anyone. Left to its own devices and with no<br>support, unfortunately, I understand the plug-in deployment failed over 6
<br>years - less than 100,000 plug-ins distributed in first 4 years and since<br>maybe 4 million - almost all by Versisgn. And most of the 4 million where<br>it is really not needed in USA and Scandinavia - no real need for IDN.
<br>ICANN could have allowed Versign and the other IDN ICANN registries to talk<br>to local ISPs to alter their software even further - so that the translation<br>step to xn-- could also be done at ISP server end - so need for plug-ins at
<br>all - a trivial thing that was originally proposed by IDN inventors - but<br>this was rejected for what many think is no good reason by IETF and ICANN<br>(ie. many think it was an ICANN vendetta against Verisign). So yes ICANN
<br>deployed but no one could use it.<br><br><br><br> The alternate root efforts have in some cases patched the ISP side<br>and like in China can do without plug-in at all. ( I think this was what I<br>was attempting to say at the DC meeting, but I was told ISPs do not need any
<br>patches, yes they do not if they adher to ICANN root). Other alternate<br>root efforts use plug-ins (all derived from the early <a href="http://i-dns.net">i-dns.net</a><br><<a href="http://i-dns.net/">http://i-dns.net/
</a>> one) that both translate to xn-- and also point<br>directly to alternate roots. But most efforts, like the Chinese, mix both<br>server side patch and plug-ins to achieve maximum penetration. For later IDN<br>email addreses, plug-ins are required - ISP patch is not enough for
<br>technical reasons. For example once they got serious, in 2 years, the<br>Chinese have pushed out over 50 million plugins and patched enough ISPs by<br>govt order to account for > 90% of China's 130M end-users. One alternate
<br>root company has thru ISP patch and plug-in distribution allowed 60% of<br>Koreas's 36M internet population to access full Korean domains in about 2<br>years. Meanwhile even with Netscape being disbanded and handed over to
<br>Mozilla non-profit and they having agreed to support at least the IDN xn--<br>translation function innately last year and therefore ICANN IDN not<br>requiring a plug-in if you use Netscape, is why I think the ICANN IDN
<br>experiment after 6 years seem to have resulted in utter tragedy in<br>comparison, as far as usability.<br><br><br> Sophia> Further. John in his document suggested 20 languages for<br>each<br> > TLD just for the TEST right?. Suppose 20 languages or 200
<br> > languages may NOT be considered EVERY language, how about when<br> > we have two million languages? Someone mentioned that nobody<br> > is going to put every language in every equivalent of say
<br> > ".com" translated. etc. or that English is the root language<br> > of the Internet. Can we you think here that "WWIII" may not<br> > be a problem. I do.<br><br> John:
<br> At one level, I share your concern. I have no idea how the<br> policy and approval procedures will work out when one starts<br> talking about even hundreds of names that are somehow associated<br>
with each TLD or some set of TLDs. I have repeatedly sought<br> for, defined, and proposed mechanisms for dealing with the need<br> for internationalization at the TLD level as a client-translation<br>
problem,<br> rather that trying to force those decisions to be global policy<br>matters.<br><br> Sophia:<br> Of course the natural attraction of DNAMEs is that each incumbent<br>registry selects its own translation (without being sensitive to the local
<br>culture who have yet to be represented at ICANN . It's implication is<br>those who already know best and who can profit the most can do it for you).<br>In every language (even ones they have never heard of or have staff to
<br>handle) the whole problem is avoided. I think we should be reminded here<br>that the internet is A GLOBAL POLICY MEDIUM. Its a GLOBAL COMMUNICATION<br>SYSTEM and interestingly, for the first time in history, people are
<br>attempting to make the FIRST BOTTOM-UP GLOBALLY DESIGNED COMMUNICATIONS<br>NETWORK. Phone companies are patchwork of national phone systems in<br>comparison.<br><br><br><br> If Multilingual communication between people that will eventually
<br>handle virtually every form of communication (post office is dead, VOIP is<br>coming) in a service-oriented (ie. data movement IS the ECONOMY - not goods)<br>handle increasingly as much as 90% of commercial activity in a GLOBALised,
<br>OUT-sourced world and the addressing of one's IDENTITY and NAME in this<br>end-all communication/business platform is what the Internet domain name<br>system is about, SHOULD NOT THIS BE A GLOBAL POLICY PROBLEM.<br><br>
<br><br> The whole point is the Internet is a global policy problem - and the<br>United Nations understands it, but most scientist or technologist so not.<br>I shall hope not, but I think ICANN from what I gather, seem to be seen as a
<br>narrow minded group of scientist /technologist, who have historically<br>controlled the Internet since invention ( despite repeated elections of<br>global board of directors who are either paralyzed or nod in silence) may
<br>find it convenient psychologically to shut the noisy world out of their<br>IVORY TOWER - trivialize the policy issues, turn a global issue to a private<br>local caucus group issue, the way they had the Internet before the
<br>world-at-large discovered it. I also learned there are those who think<br>that the US govt either thru incompetence or as a direct intended form of<br>manipulation of existing situation, or a mixture, exploits the<br>
scientist/engineers' views to keep it from becoming a global issue and<br>rather a single nations' national issue for all the obvious political<br>superpower reasons. Interesting!<br> At this point, my view would be that I may have to wear a
<br>bullet-proof vest and arrive with a contingency of US Navy Seals Team for<br>protection at the ICANN Conferences!!. Or maybe I should just wire the<br>Enterprise and ask Scotty to be ready to "beam me up" in in ase of
<br>emergency!<br> Navy SEALs <<a href="http://www.seal.navy.mil/seal/images/splash11.jpg">http://www.seal.navy.mil/seal/images/splash11.jpg</a>><br> Others again are in the view that if ICANN does not want to deal
<br>with it as a global problem, then we let it turn into a national sovereignty<br>problem, with alternate roots that countries decide. The thought is that<br>ICANN does not want it not to be global but chose to give it to incumbents -
<br>happens to be all the right people in the western companies, US govt, their<br>friends etc. - all in their comfort zone - people who having signed onto<br>ICANN for their bread-butter contracts can be depended upon to continue
<br>courting them . As such, a "not a global policy issue" can not pass or<br>should not be commented as even reasonable to an ICANN BOARD - and Board<br>members need to wake up to this. Ok, how does ICANN respond to this?
<br><br><br><br> Note: My own observation for few months now, and having researched<br>and talked with people interested in IDNs, I am inclined to deduce there a<br>number of reasons why the IDN issues have not been pursued competently as
<br>well as why GNSO was silent:<br><br> 1. Lack of in-dept technical knowledge and<br>information to enable policy making by GNSO. I think the technologist have<br>dominated the conversation. One question like "do you know the difference
<br>between BQ and BG" and everyone is "quite" or goes to "sleep", which could<br>include me in the future.<br> 2. Western companies (who are ONLY resellers<br>and who have never developed any new technology
i.e not been innovative per<br>se - even AT&T continues to develop technology while selling phone service<br>calls), may not have interest in IDN unless there is a profit justification<br>viz a guaranteed profit as a monopoly with no extra work (easy way out is
<br>DNAMES).<br> 3. Non-West companies/people say little or<br>nothing because they have already bought in to the "ICANN rules the world"<br>concept.<br> 4. Fair-minded western types may have been
<br>overwhelmed and "retired" at first opportunity<br> 5. Meanwhile the inventors/founders of the<br>Internet speak with GREAT KNOWLEDGE and in a complicated technical terms and<br>
with GREAT ARROGANCE at times (some of our emails are evidences to that), it<br>silences everyone who after-all are not paid for this volunteer board.<br> 6. As a result, the board members from
<br>non-western companies already assisting ICANN (like myself) often have to<br>make a living in a ICANN-independent manner - so the ones who are the least<br>biased tend to be the ones with the least time. (We have to hire research
<br>assistant at our expense).<br> 7. The Board member from X country with bad<br>English or the guy from Timbuktu who just wants to serve the two years so<br>that he/she can leverage that to become Minister of IT back home may be
<br>unmotivated and to nothing<br> 8. As such, the silence on GNSO BOARD is only<br>matched by the silence on the main Board on IDN and other issues. This<br>level of silence, have resulted in the external threats to become REAL -
<br>china etc. This silence I think also led to a few, dominating to prevent<br>ideas they often arbitrarily did not like about something they never wanted<br>to do (allow multilingual domains) and then after preventing the matter, did
<br>not helping with the actual carrying out of successfully, that which was<br>agreed to by default.<br><br> John:<br> While "WWIII" is probably hyperbole, I believe the most<br> efficient way to get us to alternate roots and a badly
<br> fragmented Internet would be to respond to the perceived<br> requirements for increased internationalization with a "just say<br> no" attitude or one that can be interpreted as people from
<br> industrialized countries trying to keep populations from<br> less-developed areas from using the Internet effectively.<br><br> On the other hand, unless you succeed in persuading everyone in<br> the world to adopt a writing system that uses Roman characters,
<br> the argument for IDNs, and IDNs at the top level (at least in<br> appearance to the user) will not disappear. If we are going to<br> do such things by entering names in the root, then it is useful<br>
to know what will work, what will not, and, to the extent to<br> which we can make estimates, what the operational impact will<br> be. I believe we should all be quite concerned about making<br> root changes without at least some of that experience and
<br> knowledge. If people want to run experiments, then those<br> experiments should be both controlled and informative. The<br> choice of 20 was based on an estimate of the minimum number<br> needed to give us some useful information.
<br><br> Sophia:<br> I I see no issue with running experiments, but once again, we<br>launched technology that worked before. The issue is not technology one<br>would think. It is POLICY. Should we not settle on some idea of how
<br>policy-wise ICANN should delegate languages (if DNAMES) and TLDs (if new<br>ones) or at least have some parallel debate. I understand the Katoh<br>committees studied it in the past and had recommendations, but I have not
<br>heard any actual discussions on what the committee thought then about<br>Policy. It appears to me from your comments that the Katoh-committee<br>(spent far more time than we have so far I would have thought this time
<br>around) from a policy perspective (ie. bickering) had only a few<br>recommendations to make - and one quite clearly recommended that new TLDs<br>should be issued for IDN TLDs and that these TLDs should not be handed in a
<br>grandfathered way to existing gTLDs OR ccTLDs ... correct me if I am wrong.<br><br><br><br> That it should be brandname new "bids" by all-comers. If that<br>reading is right, one would imagine while the technical merits of DNAMES
<br>were not discussed (or for that matter DNAMEs as an option was not brought<br>up at all) the prevailing assumption that DNAMES will be a way of awarding<br>existing ccTLDs and gTLDs equivalent IDN TLDs in effect would be counter to
<br>what the Katoh-committee was presumably explicitly trying to avoid -<br>incumbents getting IDN TLD equivalents. (I understand in principle that new<br>IDN TLDs can be deployed and DNAMES made only operational in that new IDN
<br>TLD as you point out later but I think most people in these discussions<br>presume DNAMES implies incumbents eventually getting their IDN TLD<br>equivalents in many languages - certainly in the Versign DNAME proposal that
<br>seems to have jump-started the current fascination with DNAMES that is their<br>assumption/hope).<br><br><br><br> Again I am puzzled that after having gone to so much trouble and<br>time we are now ignoring even a modest discussion of the original Katoh
<br>committee recommendations . They suggested various policies - long before<br>any experiment. Now we seem to be going ahead without any policy discussion<br>and worse ignoring the policy recommendations made earlier, straight to
<br>experiments. I must say I am puzzled.<br><br> Perhaps the current IDN committee should get us all upto speed on<br>the Katoh-committee recommendations and why they suggested what they did and<br>why we are proceeding along the lines of what we are doing - reasons for and
<br>against. We can always make different decisions from the Katoh-committee<br>recommendations.<br><br> John:<br> > 2)- Unfortunately English is the default language of the<br> > Internet today and it is likely to continue to be. Nobody
<br> > questions that in a serious way - but what everyone wants I<br> > believe is a reasonable usable field in every major language<br> > today etc. for non-english speaking populations. Without
<br> > having to be condescending to the "non-West" as I am certain<br> > they do understand English is here to stay, what we want to do<br> > is really keep the other languages alive. From what I have
<br> > gathered, it seem that past discussions on this issues suggest<br> > 'Textbook thinking" without due consideration of is what the<br> > "non-US/West" wants. If we out to call it IDN and ICAAN
<br> > represents a true international organization, we need to NOT<br> > only talk the talk, but walk the walk, applying the<br> > cornerstone of globalization in a realistic way, 'think<br> > global, act local'.
<br><br> I think that some of us who have been working on these issues<br> for many years are at least as sensitive to these issues... and<br> to finding ways to make things work effectively with a variety
<br> of scripts and languages, as you are. Some of us have even<br> spent a good deal of time working with people in the "non-US/<br> non-West" trying to accomplish that while also trying to<br>
preserve the integrity of the DNS as a global Internet-object<br> referencing resource. The problems are complex. The DNS is not<br> an ideal solution to many of them for reasons that have little<br> to do with English or even Roman characters. The nature of
<br> those problems and the range of alternatives have been rather<br> extensively explored outside the ICANN and Roman-script<br> contexts, especially in East and Southeast Asia. At the same<br> time, slogans may not be helpful (
e.g., the only practical way<br> to realize "think global, act local" with regard to IDNs is to<br> get internationalization issues entirely out of the DNS -- an<br> IDN in the DNS is inherently global because the DNS is
<br> inherently global) and wishing the DNS, or the Internet more<br> generally, worked in a way significantly different than it does<br> won't make it so... any more than lamenting how much easier<br> navigation would be if only the earth were flat is helpful to
<br> either navigation or earth-flattening.<br><br><br><br> Sophia:<br><br> It seems rather puzzling to me that, after 6 years or more of<br>activity, the best that ICANN has done to date is to being able to deliver
<br>from "those of that have been sensitive to the needs of the non-US/non-West"<br>is a two-language/script domain name. ie. the IDN.ascii-tld, technical<br>people can make all the distinction they want but in general use you will
<br>never see any significant change I fear. eg. is I would not like the US<br>passport agency to finally recognize that there are many Arab US citizens<br>and that their passport should contain their personal name in the original
<br>Arabic and then proceed to write in their passport "Ismael" in Arabic and<br>then "Mohammed" in English.<br><br><br><br> The whole point is to allow non-native English speakers to skip<br>English in domain addressing . Making them type half in English is not
<br>really a solution?, becomes bad-mannered, if we were not all brainwashed to<br>think that "English" is the "end-all". Worse, whether you need a plug-in<br>or not, or if ISP or Microsoft patches it, these two-language domains will
<br>always require end-user to switch KEYBOARD from one language to another<br>while typing a single domain name in a browser (in Hebrew and in Arabic also<br>switch direction of typing). I gather this has been a huge problem , hardly
<br>anyone bothers to mention - because no one is really using these things<br>after 6 years . But if you put IDN TLDs - alternate roots or ICANN root,<br>with or without plug-in, this problem goes away - you do not need to switch
<br>keyboard settings halfway.<br><br><br><br> I find it hard to believe that this two-language oddity is what the<br>non-English speaking people have wanted out of their internationalized<br>Internet . It would seem anyone with any sensitivity to non-English
<br>languages using scripts far divergent from roman-like would want single<br>language/script domains - to push the point home, I doubt there is much of a<br>market for " arabic.hebrew" names. What I mean is, "Arabic" on left and
<br>"Hebrew" on right - two-language . Hebrew TLD and Arabic company domain<br>name. This is the sort of thing I believe what ICANN has been launching for<br>the past years - two languages, which has been criticized with the IDN
<br>community and has not found much of a user.<br><br><br><br> The more likely scenario would be that perhaps those who were<br>"sensitive to the needs of the non-West" did not understand . The real<br>reason might just have been technical and political convenience and
<br>incumbent-market economic convenience - none of it necessarily helpful to<br>those who really need the internationalization. Technical, because less<br>has to be changed (similar logic as in DNAMES for now I presume). Political,
<br>because there was no need to introduce new TLDs way back at a time when<br>ICANN had other on-going battles to defend its authority and<br>incumbent-market economics - it benefited the major existing registries -<br>the early ones being commercial gTLDs or if ccTLDs, then privatized
<br>profit-making ones.<br><br><br><br> I bring this up not to apportion blame (even you conceded the<br>initial launches were terrible and we don't need anyone to tell us that the<br>whole IDN roll-out has been a practical failure in the general public's
<br>minds) but rather to counter your matter-of-fact assumed suggestion that<br>"everything is in good hands and we have been sensitive to non-US/non-West<br>needs". It is said that those who do not consider the past maybe doomed to
<br>repeat it. My real worry is that once again we may be going down a path of<br>technical expediency ( eg. DNAMES) all the while insisting that we are<br>"sensitive".<br><br><br><br> Given the past, in my opinion, to be truly "sensitive" one needs to
<br>consider the policy side of what we are about to before we embark headlong<br>into another "better testbed" directed down a channel guided by technical<br>expediency (possibly DNAMES) and by the identical commercial forces as
<br>before (Verisign initiated proposal). And add to that no one seems to even<br>bothering to recall that a prior Katoh-led Committee spent substantial<br>effort coming up with guidelines for the future may have specifically
<br>recommended against the path that things currently seem to be pointing -<br>incumbent awarded mappings ie. DNAMES. If we have the same organization,<br>possibly some of the same sensitive people, similar technical expediency
<br>directed technical solutions, same arguments, same commercial proposers – I<br>doubt if we do we expect a different outcome?<br><br><br><br> Finally, I truly believe we need policy discussions first and should<br>
at least consider for discussion the Katoh-committee recommendations as a<br>first step.<br><br><br> Sophia> 3) I may be presumptuous, but ICANN's argument of resorting<br>to<br> > using DNAME seem to come from the perspective of how ICANN
<br> > failed to be responsive for long and now "China" and others<br> > are threatening to "break the single root". Therefore,<br> > perhaps, we were left to a single view and a quick solution,
<br> > neglecting to entertain the CHOICES we may have for IDN. So,<br> > the easiest implementation approach is DNAME, which is is to<br> > just give the big registries all the languages without having
<br> > to change much in the technical stuff - ie. just <a href="http://re-point.com">re-point.com</a><br><<a href="http://re-point.com/">http://re-point.com/</a>><br> > to every language equivalent - no new TLDs etc.
<br><br> John:<br> Actually, I think you misunderstand both the situation and the<br> history. First, DNAMEs are, in Internet time, a relatively old<br> proposal and protocol specification. I didn't invent them and
<br> neither did Verisign. Second, there was a proposal from the<br> original ICANN IDN committee that no IDN TLDs be permitted in<br> the root except on a separate application for new TLDs process.<br>
For an number of reasons --almost all of them consequences of<br> how the DNS actually works and what is and is not possible as a<br> result-- I still believe that was a wise recommendation,<br> independent of anything China, Verisign, or others might "want"
<br> to do. Some of those who are still on the GNSO Council will<br> probably remember that, because of issues with the number of<br> languages in the world, I recommended that we try to sort out<br> the use of IDNs at the second level and below in relevant ccTLDs
<br> before permitting them to be used at all... and recommended that<br> several years before China made essentially the same suggestion<br> (of course, by the time they made that suggestion, it was<br>
already too late since several gTLDs were doing production IDN<br> registrations).<br><br> Now, there has been a good deal of pressure from a number of<br> directions to create aliases for country names in national
<br> languages. That pressure has actually been much more intense,<br> with more threats, from other directions than from China. If an<br> alias is what is really wanted and that alias must, for<br> technical or political reasons, be in the root, then DNAMEs are
<br> the right way to do so. Other solutions are simply not aliases,<br> they are separate domain names. To me, for separate domain<br> names, the original IDN Committee/Katoh-san recommendation<br> should still apply. As with IDNs below the top level and the
<br> "what languages" question, I understand the idea of an alias for<br> a ccTLD in the relevant country's national language(s) much<br> better than I understand what to do about gTLDs. Indeed, if I
<br> could make recommendations for the GNSO, I would seriously<br> consider a recommendation that, at least for the next several<br> years, the top-level IDN issue is, except for possible<br> completely new applications domains with IDN-style names,
<br> entirely a ccTLD problem and that the gTLDs should not<br> participate in any way in the evaluation of what is possible and<br> reasonable other than continuing to register second-level IDNs<br> under existing rules.
<br><br> Sophia:<br> I am aware that DNAMES has existed for a long time as a technical<br>part of the DNS structure. You and Patrick pointed it out in your recent<br>IETF document that was circulated. But you also point out DNAMEs was never
<br>really invented with IDN in mind and in fact there is some hesitancy for<br>"borrowing" it for this purpose of IDN. From my crude understanding the<br>reasoning appears to be it would be ideal not to use something for which it
<br>was not really intended.<br><br><br><br> In any case in my understanding the DNAMEs approach is being<br>championed right now - it was not the case I believe in the previous 6 years<br>of ICANN IDN history. The Katon-committee didn't consider it after 3 years
<br>of IDN history at ICANN. If this thing has been around for as long as the<br>Internet, then why all of a sudden this proposal is being championed -<br>whatever the true reasons, it certainly has the suggestions of technical
<br>expediency in the face of potential external threats/pressure.<br><br><br><br> Well, its great that you bring up the Katoh-committee<br>recommendations that you too seem to agree with , and at some level these<br>
are against the grain of the direction in which a DNAMES like deployment<br>would head - awarding incumbent existing gTLD registries equivalents. Saying<br>that DNAMEs is just a technology and how it need not be given to existing
<br>registries in principle is true technically. But the real issue is that's<br>where it is likely to head and that's why the POLICY needs to be discussed<br>first. Why are we not even discussing them after having invested so much
<br>time and effort on their recommendation?<br><br><br><br> I understand that the Versign testbed was done badly and everybody<br>acknowledges that . Now when China came up with a solution they liked, it<br>was already too late because we at ICANN had gone ahead and gone beyond "bad
<br>testbed' to actual production registrations under a few major commercial<br>registries ( gTLDs and ccTLDs I guess) and it was too late to go back.<br>Perhaps it is no little wonder that the same China and others are now
<br>forging their own path ahead. So two mistakes - not just one - presumably<br>all driven by the stronger commercial registries wanting to increase sales<br>in their existing ascii TLDs by way of promoting somewhat insulting
<br>two-language/script hybrid domain names.<br><br><br><br> If there is pressure from other sources - other than China to move -<br>would it not be useful or proper for those of us who believe policy issues<br>are equally or more important than technical testing of fairly
<br>well-established technology (perhaps as old as the Internet you suggested<br>for DNAMES) to know what these "pressures" are if we as members of various<br>ICANN boards have to endorse the eventual policy chosen. No matter what the
<br>spin from wherever, it is abundantly clear that the current IDN activity<br>within ICANN after 2 or 3 year relative hiatus, is happening because of<br>considerable external pressure . I am not sure I am speaking for all the
<br>GNSO members, but for my part I generally viewed the pressure from China as<br>the biggest one while I have heard rumors of others and unhappiness from<br>various other quarters . If as you say the pressure from China is not the
<br>main one and there are multiple others, it would appear that we would need<br>to discuss this pronto!<br><br><br><br> Could someone please share this with us? So that our job is NOT to<br>simply endorse everything.
<br><br> Incidentally I would not be surprised if many of our board members<br>learnt of the China deployed/commercial activity while reading a recent Wall<br>Street Journal article. I have since learnt reliably that this activity was
<br>launched initially in a small way with full backing by their Ministry<br>(published statements by Ministers) more than 4 years ago, and starting<br>about 18 months ago it has been extensively deployed all over China. A
<br>large fraction of the 130M+ Chinese Internet population is already<br>enabled-to use it and many tens of registrars have actually been selling<br>these domains (which for all external purposes look like real IDN TLDs as
<br>described in the Wall Street Journal article) for well over a year and many<br>tens of thousands of names registered and in use. A quick visit to the CNNIC<br>web-site confirms all this.<br><br><br><br> It would be nice to know of these things earlier and not from the
<br>likes of the Wall Street journal.<br><br><br> Sophia> John's statement butteres this point:<br> ><br> > If a such programmer in China were to decide that, for her<br> > users to have a good experience, .US and .COM should be able
<br> > to be referenced by using Chinese names, there is nothing that<br> > the GNSO, ICANN, IETF, ITU, or the Great Pumpkin could do to<br> > stop or prevent it. Even the control of the Chinese government
<br> > would be _extremely_ limited, since those Chinese names would<br> > be visible only to users of that particular application with<br> > that particular extension, and not "on the wire" or to either
<br> > DNS servers or the sites or hosts being reached.<br> ><br> > I think if this is the way we have looked at it, it seem that<br> > our response is shortsighted (because it technical-oriented
<br> > only and did not consider the business issues) and is perhaps<br> > why ICANN has failed achieve success in the IDN arena.<br> > Instead of worrying about the political, policy and cultural
<br> > implications, first, we may have focused on the easy way<br> > out...technical. In this case, contrary to what Cary said, I<br> > think issuing DNAME is equally reckless as using new TLDs in
<br> > IDN.<br><br> > The fact that the Chinese has already launched this process<br> > (if we out to call them reckless) and ICANN who ought to know<br> > better, is forced to 'follow' the same (can we call ICANN
<br> > "reckless") as well? Uhmm.<br><br> John:<br> Again, please understand enough about how the DNS works, and how<br> name resolution and applications on the Internet work more<br>
generally, to be able to understand what is said above. The<br> Chinese have not already "launched" anything along the lines of<br> what I suggested. That proposal is not "technical-oriented
<br> only" and does consider the business issues (even if the<br> business and cultural issues it considers critical might not be<br> the same ones you would choose). That proposal was actually<br>
almost exclusively focused on political, policy, and cultural<br> issues -- many of the technical folks, who prefer a less complex<br> world, actually don't like it. And that proposal is not, in any<br>
way, related to DNAMEs -- it is a third alternative.<br><br> As to whether "issuing DNAME" is "equally reckless" as "using<br> new TLDs in IDN" (whatever that means), I would, again,
<br> encourage you to understand what is being proposed and what its<br> technical implications are, if only because doing so is<br> prerequisite to talking intelligently about the business issues<br> (or even most of the political and cultural ones). The "new
<br> domain" issues are simply a superset (a rather large superset)<br> of those associated with DNAMEs. DNAMEs supply aliases but, as<br> I pointed out long before the GNSO became actively concerned
<br> with this, one still needs to decide who gets which names and<br> what they point to. New domains raise the much more complex<br> issues of allocations and operation, and domain-specific<br> policies as well as those of name selection and assignment,
<br> issues that are largely invisible from the DNAME case.<br><br> Could one adopt a DNAME model and reserve names for later<br> "independent TLD" allocation? Of course. Could one restrict<br>
the DNAMEs that would be associated with gTLDs to some limited<br> set, or even to zero if that were felt to be wise? Of course.<br> There is nothing that is "all languages in the world or nothing"
<br> about any of the proposals I have heard seriously raised.<br><br> Sophia> *Ok, pls correct me if I am wrong when I am trying to speak<br> > DNAME implementation approach:* eg. CEO of <a href="http://mybrand.com">
mybrand.com</a><br><<a href="http://mybrand.com/">http://mybrand.com/</a>> has to<br> > be protected in every language under a gTLD that means "com"<br> > in every language, right ? meaning they have to come up with
<br> > 200 language translations of ".com" and ICANN can approve<br> > DNAMES.<br><br> John:<br> No, they do not. And the fact that they do not is actually one<br> of the attractions of the DNAME approach (except to the
<br> registrars and registries who are anxious to mount "there is now<br> another new domain in which you need to register to protect your<br> brand... please send money" campaigns. _That_ approach requires
<br> separate domains).<br><br> Sophia> Then these companies, like Versign, can go and get<br> > everyone of <a href="http://their.com">their.com</a> <<a href="http://their.com/">http://their.com/
</a>> name holders (40<br>million in this case)<br> > names translated / transliterated into 200 languages to<br> > everyone's satisfaction and register them all to get 200 x 45<br> > million DNAMES. *I hope I am on right track so far.*
<br><br> John:<br> No, you are not. Please read the comments above and, more<br> important, please make an effort to understand how the DNS works<br> in general and how DNAMEs work in particular.<br>
<br> Sophia> Are they also going to charge the CUSTOMER (who has already<br>paid<br> > some $6 already) for the translation/transliteration work?<br> > Also, if the customer then is upset by the accuracy of
<br> > translation or if the customer is sued by some other third<br> > party saying that the wrong translation now impinges on their<br> > own business, will VERISIGN pay for all lawsuit damages? I am
<br> > almost certain that these companies will NOT agree to this -<br> > but this is the result of DNAMES.<br><br> John:<br> No, it is not.<br><br> Sophia> Finally, from where I see it, *policy is to be made first in
<br><br> > complex situations as these.* Technology is a second - fact is<br> > these systems seem to have been working for years already, as<br> > China seem to have has deployed it for years on a large scale
<br> > - far larger than anything ICANN has done to date, I believe.<br><br> John:<br> No, China has done something else, and only relatively recently.<br> Once you understand, throughly, how the DNS works and, in
<br> particular, the difference between the actions of a caching<br> forwarder and a different TLD, I'll be happy to try to explain<br> just what they are doing, and why, to you.<br> ...<br> Sophia> Therefore, as Avil suggested, I propose the alternatives and
<br> > solution should be explored by a joint consultation with<br> > relevant IDN circles and the Council.<br><br> John:<br> Sure. As long as the capabilities and operations of the DNS are<br>
sufficiently well understood, and at a policy level, the range<br> and scope of potential ICANN authority is reasonably well<br> understood, that discussions of policies that imply flat earths<br> and more convenient values of PI are avoided. Otherwise, while
<br> the discussions would certainly be interesting, the GNSO will<br> waste its time and the world will ignore ICANN and move forward<br> on its own path.<br><br> Sophia> I myself recommend the POLICY option. Go for a solution
<br> > letting the people speaking a specific language (or script as<br> > they like to say) is a part of their culture – to take care<br> > of it. We can talk about specific implementation strategies
<br> > once we agree with the policy option!<br><br> John:<br> First, the proposal that comes closest to the type of solution<br> you seem to propose above is one that you have rejected out of<br>
hand. Second, scripts and not the same as languages and people<br> don't speak scripts: not understanding the difference can only<br><br> ;p0increase your confusion. Third, as long as the DNS is to remain
<br> a global resource, a solution that involves letting those who<br> speak a particular language to "take care of it" and go in their<br> own direction is essentially impossible. Or, to put it
<br> differently, it is possible in only two ways: with client-level<br> aliasing (which you have rejected) and with different DNS roots<br> for each language group. The latter is inconsistent with both
<br> unambiguous global references on a global Internet and, by the<br> way, with your having any possible hope of protecting your<br> business name or trademark globally... except by legal action in<br>
each country in which a similar name might be used.<br><br> regards,<br> john<br><br><br><br><br><br><br><br><br></blockquote></div><br>