Re: [council] Re: Regarding issues report on IDNs

["Sophia B" <sophiabekele@xxxxxxxxx>]

Greetings Tina:

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.

Regards,
Sophia

On 13/03/06, Tina Dam <dam@xxxxxxxxx> wrote:
>
> Hi Sophia, I will need to take some time to go through your entire email
> for
> a full understanding or overview of your points. However, I wanted to
> reply
> to your email right away to provide some clarification in one area.
>
> In the question about policy vs. technical and what comes first it is
> important to understand that we don't know at this stage if DNAME or NS
> records will work well and keep the DNS stable and secure. So at this
> stage
> there is not decision that either DNAME or NS records will be an option
> that
> the GNSO can start developing policy around.
>
> First we will be testing DNAME and NS records with IDN labels - when we
> know
> the result then we know what options we have for deployment and hence what
> policy questions we need to answer. The GNSO obviously need to be fully
> briefed on what is going on in term of the technical test.
>
> As we are getting really close to Wellington I hope we can spend some time
> to talk over these various issues while there - either within the council
> or
> in other groups as people may be available.
>
> Best regards,
> Tina Dam
> Chief gTLD Registry Liaison
> ICANN
>
> Office: +1-310-301-5838
> Cell: +1-310-862-2026
>
>
>
>
> ________________________________
>
>        From: Sophia B [mailto:sophiabekele@xxxxxxxxx]
>        Sent: Monday, March 13, 2006 11:04 AM
>        To: John C Klensin
>        Cc: Patrik Fältström; Marilyn Cade; Cary Karp; Tina Dam; GNSO
> Council
>        Subject: Fwd: [council] Re: Regarding issues report on IDNs
>
>
>        This is the revised version with "name" references for those whose
> email do not allow the color option. Thanks Patrick.  I hope this will
> suffice. S
>
>        ---------- Forwarded message ----------
>        From: Sophia B <sophiabekele@xxxxxxxxx>
>        Date: 13-Mar-2006 07:36
>        Subject: Re: [council] Re: Regarding issues report on IDNs
>        To: John C Klensin < klensin@xxxxxxx>
>        Cc: Patrik Fältström <paf@xxxxxxxxx>, Marilyn Cade
> <marilynscade@xxxxxxxxxxx >, Cary Karp <ck@nic.museum>, Tina Dam
> <dam@xxxxxxxxx>, GNSO Council council@xxxxxxxxxxxxxx
>
>
>
>                "Sophia"
>        Greetings John:
>
>
>
>        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.
>
>
>
>        I have observed from your last comments and clarifications that
> both
> of us have a proportional amount of agreements.   Dispite your pointing to
> the study of DNS, which I appreciate, my finding tells me that our
> differences are more of a philosophical difference and than a major
> technical gap.
>
>
>        On 15/02/06, John C Klensin <klensin@xxxxxxx> wrote:
>
>                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.
>
>
>        Sophia
>
>        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@xxxxxxxxx> 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.
>
>
>        John:
>        At one level, that has always been the case and is self-evident.
>        At another, it is extremely important that the Council
>        understand how the DNS actually works, what the four major
>        internationalization options are, how different options are seen
>        by the user, and what their consequences and side-effects are in
>        order to discuss these topics... at least from any standpoint
>        other than narrow self-interest.
>
>        Good tutorials on DNS operations, written with policy-makers in
>        mind, are available; if you haven't been given the references,
>        please ask.
>
>        >  That point made, what I am trying to address is 2
>        > business issues:
>        >
>        Sophia> 1- if 'mybrand' is to be protected  i.e trademark in every
>        > country...it is a matter of purchasing all the 'mybrand'
>        > TDLs...
>
>        John
>        It is at least a matter of "purchasing" 'mybrand' in _every_ TLD
>        or of convincing relevant TLDs to not permit it to be registered
>        (by you or anyone else).  However, note that you may not be able
>        to do this and you may not want to.  Some countries require that
>        you have a business locus in those countries to register in
>        their TLDs, so, unless you open an office there, you may not be
>        able to "buy" that name.  In others, your ownership of a
>        well-known trademark (if "mybrand" is one) may be more than
>        sufficient to protect you: you may not have to actually
>        "purchase" (register) the name and might actually be better off
>        not doing so.   Even if you manage to control all of the
>        possible second-level domains of that name, you still need to
>        make a judgment as to whether you have bought yourself adequate
>        protection.   If "mybrand.TLD-name " is a problem for you,
>        "mybrand.some-SLD-name.TLD-name " may also be a problem.  I note
>        that, some years ago, a fairly well known trademark holder in
>        the US decided to take exception to names of the form
>           mickey.someschool.k12.fl.us <http://mickey.someschool.k12.fl.us/
> >
> and
>           minnie.someschool.k12.fl.us <http://minnie.someschool.k12.fl.us/
> >
>
>
>        So far, none of this has anything to do with IDNs.  It might be
>        an argument for not creating any more TLDs of any flavor, but it
>        is worth noting that a new TLD increases your problem by well
>        under 1/2 percent if names below the second level are ignored
>        and by far less than that if they are considered.
>
>        The place where IDNs enter in depends on whether you believe
>        that, if you need to have control of every instance of "mybrand"
>        in the DNS, you also need control of "muybrand" and
>        "meinefabrikzeichen" (both of which can be perfectly well
>        expressed in ASCII characters) or "xn--80aanvhbf1a" and a huge
>        variety of other synonyms and translations.  One can, of course,
>        make a case that you are entitled to, or should protect, all of
>        those things (of which there are many thousands) but one could
>        also suggest that, at some point, silliness sets in.
>
>        Sophia
>        I do not see a big problem with this, as long as protection of say
> for example an "English" trademark in different countries (in English, as
> well when translated into that countries native languages) can be achieved
> at a cost that is far less than what it takes to trademark these things in
> the first place in each country,.   For example if one had an ascii brand
> name in say USA and then a company trademarked in 30 countries, they are
> likely to (a) pay 31 times for "English language" trademarking fees at as
> much as $1000 or more in each country and periodic/yearly maintenance fees
> at some small fraction of that and (b) inclined to translate/transliterate
> (or both) that English brand name into 31 different native languages and
> then trademark all of them - ie. 30 times another $1000 assuming only one
> native language per country, plus periodic maintenance fees for that and
> (c)
> pay for all those 30 or more translations in the first place - decent
> translations can easily cost $1000 or more and (d) perhaps pay also having
> to trademark transliterations as well as translations in each native
> language in each selected country.
>
>
>
>        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.
>
>
>
>        If the need to register many domains while trying to mimic the
> tradmarking activity already embarked upon reaches the point of
> "silliness",
> the trademarking activity itself will have reached a point of far more
> costlier silliness well before that.   So I am not sure if we need to
> worry
> about "silliness".   I think the market will take care of itself just as
> the
> market today knows not to trademark in every language and every country
> etc.
>
>        Sophia
>
>        Sophia> 2-on the other hand, if mybarnd .com is to be protected 'in
>        > every language' under gTLD, then 'com' in every language over
>        > 200 translation need to be protected and approved by ICANN.
>
>        John:
>        First, as I think Cary has pointed out, "every language" puts
>        one somewhere in the 6000 range, not 200.  What is more
>        important is that this problem exists today, with no further
>        action being required on the part of ICANN.  Using the
>        admittedly crude examples above, " muybrand.com
> <http://muybrand.com/> ",
>        " meinefabrikzeichen.com <http://meinefabrikzeichen.com/> ", and "
> xn--80aanvhbf1a.com <http://xn--80aanvhbf1a.com/> " could be
>        registered tomorrow if they have not been registered already.
>        The only nuance that an IDN TLD system would add is the ability
>        to refer to " xn--80aanvhbf1a.com <http://xn--80aanvhbf1a.com/>  "
> as something like
>        "xn--80aanvhbf1a.xn--e1aajebclaqxm4e" (if using DNAMES or local
>        aliases) or to register "mybrand.xn--e1aajebclaqxm4e" and
>        "xn--80aanvhbf1a.xn--e1aajebclaqxm4e " in a new domain if
>        separate domains were created.
>
>        Sophia> So the guardians of this names i.eVerisign etc.. will be
>        > translating and registering them.  ARe they passing
>        > the cost to the customer? Are we going to approve over 200
>        > maybe thousands of translations?
>
>        John:
>        This is, again, a situation in which being very clear about how
>        the DNS actually works and about what one is talking about as a
>        result is very important.  For example, if the DNAME approach is
>        used, and a DNAME record named .xn--e1aajebclaqxm4e is installed
>        pointing to .COM, then there is no difference between
>           mybrand.com <http://mybrand.com/>  and
> mybrand.xn--e1aajebclaqxm4e
>
>        they are the same set of record entries.  By contrast, whether
>        or not "xn--80aanvhbf1a.com <http://xn--80aanvhbf1a.com/>  " could
> be registered, and on what
>        basis, is strictly a registrar issue with the standard fee
>        structure -- I believe that name could be registered today and
>        that, if you didn't like it, you would need to go through a
>        standard UDRP procedure.
>
>
>
>        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 <http://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 <http://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!
>
>
>        John:
>        I would hope that, were ICANN to be willing to install a
>        top-level DNAME record with the label of xn--e1aajebclaqxm4e,
>        that there would be some cost-recovery for doing so, but the
>        amounts would not be large.  The question of which of well over
>        6000 DNAMEs would be inserted pointing to COM and how they would
>        be chosen is a pure policy issue.   And, were ICANN willing to
>        create a separate top-level domain for xn--e1aajebclaqxm4e, the
>        registration policies for that domain would be ... well,
>        whatever was proposed and accepted.
>
>        Sophia:
>                I think you have precisely nailed it.   Policy first or at
> least in parallel.  Experience showed in past icann launches, that
> technology was far lesser problem, policy was far more important.  In the
> end the technology worked, but in practice deployment, unfortunately, it
> proved an abject failure 6 years later.  II think it is because ICANN did
> not follow-up with the policy to ensure after deployment worked, no one
> argued etc. and it might be off  to be repeated it again.
>
>        Sophia> What are the implications above?
>
>        John:
>        The implications clearly differ with the technology chosen.  As
>        I (and others) have pointed out before, few of the existing TLD
>        names actually represent words in English (or any other
>        language), so the matter of translations would be difficult and
>        might call for some policy decisions.  If one were trying to
>        minimize policy issues, the DNAMEs or are clearly the better
>        approach of those involving root changes and local aliases are a
>        better approach yet.  Presumably, if new names are going to be
>        placed in the root (for either DNAME or delegation records),
>        some procedure will need to be devised for applying for and
>        registering those names and I would not predict that it will be
>        easy to devise such a procedure while still being sufficiently
>        fair to all language groups to minimize the risk of people
>        feeling that they are forced into the development of alternate
>        roots.  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.
>
>        Sophia:
>        I see the very heart of the problem here – I distaste bringing up
> east vs west, because personally, I love American steak and Chinese
> noodles,
> but it is the reality and your statement is a bit of icann/west view for
> my
> taste.  First, what you are saying is that people will fight over which
> new
> tlds to choose in new languages, so its perhaps better to just remain with
> the existing tld names in ascii and simply translate/transliterate them,
> of
> course you also say that the existing tlds have no literal meaning ( who
> is
> to say that .com really means commercial , it could mean ".come here
> darling" OR ".CN" MEANS "CHINA" RATHER than a short-code for all "sin"
> WEB-SITES), so translating them meaningless words would in my opinion be
> just as problematic.
>
>
>
>        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 .
>
>
>        --On Sunday, 05 February, 2006 23:23 -0800 Sophia B
>        <sophiabekele@xxxxxxxxx> wrote:
>        >...
>        > Please allow me to present this historic perspective, as well
>        > as some relative considerations regarding the IDNs.
>        >
>        > 1) It is my understanding that ICANN has a fully authorized
>        > TESTBED still ongoing with VERISIGN, operating almost 200
>        > languages under ".com".   It is also my understanding that the
>        > author of the DNAME proposal draft (published in Vancouver) is
>        > from VERISIGN (they are the champions of this and the author
>        > of the document is a fellow who launched the first Versign
>        > testbed. Is it also a fact, pls correct me if I am wrong, to
>        > state that this process sold 1 million names in 200 languages,
>        > but really did not address the long-term solution? uhmm.
>
>        John:
>        I am no particular friend of Verisign's or their behavior, but I
>        believe the explanation above is somewhat distorted.  As I
>        understand it, the vast majority of the names registered under
>        the testbed have been converted to IDNA names and the relevant
>        fees paid for standard registrations.  More important, despite
>        my use of some of them in the examples above, no one really
>        wants to type in, or look at, any of these ACE-encoded names.
>        In general, if I use one of the IDNA (punycode, as above) names
>        in a DNS name context any modern/contemporary browser, I will
>        see the native characters associated with that name.  But
>        nothing contemporary supports the "RACE" names that were used in
>        the testbed.  So, unless one finds a string starting with "bg--"
>        and followed by an arbitrary-looking collection of characters to
>        be amusing or of mnemonic value, that testbed, however badly it
>        was handled, is now irrelevant.
>
>
>        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 <http://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 <http://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.1gwi-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.
>
>
>        John:
>        Verisign has permission to register IDNA names in COM and NET
>        and has had it for several years.  As far as I know, every other
>        gTLD that has asked for permission to register IDNA-style IDNs
>        has gotten that permission.  These are not for testbeds, they
>        are for production registrations.
>
>        Sophia:
>                I would say yes to this of course, but my research tells me
> that no one uses them.  The Chinese from day one in 2000 used their
> ambassadors and their ministers to protest internationally and to this day
> more or less block it for use within China.  All of these are two language
> hybrids ie. native language.ascii-cctld. ie. half my name for eg. in
> Amharic
> and the other half in English.   Totally offensive and does not really
> help
> the non-English speaker who cannot type English, even worst, in most cases
> the non-English speaker has to change KEYBOARD SETTINGS from one language
> to
> another half way through typing a single domain name.  I understand - yes
> some people bought them to protect their names but the average non-English
> speaker who needs IDN has almost never used them.    Probably less than 1%
> of names ever bought under these are actually used or usable.   And the
> total number of all ICANN approved IDN names registered today is probably
> less than 500,000 - mostly in .com. - after 6 years .   And most are not
> hosted and the 1% or less that is hosted are actually not used, because
> ICANN was not able to make them usable by the people who need it.   Wow,
> contrast that with China, who after getting serious about their alterative
> root (started in 2001), about two years ago, that have over 100M people
> being able to use it - only 300M truly IDN needing Internet users in the
> world (note French, Latin, Germans, can use ascii for the most part
> happily).   I hope this are statistics that are not was off base, if so, I
> would need an issues report, to contrast that, like Marylin Cade would
> say.
>
>        John:
>        Now, I believe that testbed was very badly handled and that the
>        way it was approved and handled reflects badly on ICANN (staff,
>        Board, and the then DNSO Council) and on Verisign.  My proposal
>        that we be quite aggressive in being sure that "tests" are
>        actually tests and not some sort of early-start mechanism was
>        developed precisely because of that experience.  We should at
>        least avoid making the same mistake a second time.  More on this
>        below.
>
>        Sophia:
>
>        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 <http://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
> <http://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.
>
>
>        Sophia> Further. John in his document suggested 20 languages for
> each
>        > TLD just for the TEST right?.  Suppose 20 languages or 200
>        > languages may NOT be considered EVERY language, how about when
>        > we have two million languages? Someone mentioned that nobody
>        > is going to put every language in every equivalent of say
>        > ".com" translated. etc. or that English is the root language
>        > of the Internet. Can we you think here that  "WWIII" may not
>        > be a problem.   I do.
>
>        John:
>        At one level, I share your concern.   I have no idea how the
>        policy and approval procedures will work out when one starts
>        talking about even hundreds of names that are somehow associated
>        with each TLD or some set of TLDs.  I have repeatedly sought
>        for, defined, and proposed mechanisms for dealing with the need
>        for internationalization at the TLD level as a client-translation
> problem,
>        rather that trying to force those decisions to be global policy
> matters.
>
>        Sophia:
>        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.
>
>
>
>        The whole point is the Internet is a global policy problem - and
> the
> United Nations understands it, but most scientist or technologist so not.
> I shall hope not, but I think ICANN from what I gather, seem to be seen as
> a
> narrow minded group of scientist /technologist, who have historically
> controlled the Internet since invention ( despite repeated elections of
> global board of directors who are either paralyzed or nod in silence) may
> find it convenient psychologically to shut the noisy world out of their
> IVORY TOWER - trivialize the policy issues, turn a global issue to a
> private
> local caucus group issue, the way they had the Internet before the
> world-at-large discovered it.   I also learned there are those who think
> that the US govt either thru incompetence or as a direct intended form of
> manipulation of existing situation, or a mixture, exploits the
> scientist/engineers' views to keep it from becoming a global issue and
> rather a single nations' national issue for all the obvious political
> superpower reasons.  Interesting!
>        At this point, my view would be that I may have to wear a
> bullet-proof vest and arrive with a contingency of US Navy Seals Team for
> protection at the ICANN Conferences!!. Or maybe I should just wire the
> Enterprise and ask Scotty to be ready to "beam me up" in  in ase of
> emergency!
>         Navy SEALs <http://www.seal.navy.mil/seal/images/splash11.jpg>
>        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:
>
>        1.                      Lack of in-dept technical knowledge and
> information to enable policy making by GNSO.   I think the technologist
> have
> dominated the conversation.   One question like "do you know the
> difference
> between BQ and BG" and everyone is "quite" or goes to "sleep", which could
> include me in the future.
>        2.                      Western companies (who are ONLY resellers
> and who have never developed any new technology i.e not been innovative
> per
> se - even AT&T continues to develop technology while selling phone service
> calls),  may not have interest in IDN unless there is a profit
> justification
> viz a guaranteed profit as a monopoly with no extra work (easy way out is
> DNAMES).
>        3.                      Non-West companies/people say little or
> nothing because they have already bought in to the "ICANN rules the world"
> concept.
>        4.                       Fair-minded western types may have been
> overwhelmed and "retired" at first opportunity
>        5.                         Meanwhile the inventors/founders of the
> Internet speak with GREAT KNOWLEDGE and in a complicated technical terms
> and
> with GREAT ARROGANCE at times (some of our emails are evidences to that),
> it
> silences everyone who after-all are not paid for this volunteer board.
>        6.                         As a result, the board members from
> non-western companies already assisting ICANN (like myself) often have to
> make a living in a ICANN-independent manner - so the ones who are the
> least
> biased tend to be the ones with the least time. (We have to hire research
> assistant at our expense).
>        7.                         The Board member from X country with bad
> English or the guy from Timbuktu who just wants to serve the two years so
> that he/she can leverage that to become Minister of IT back home may be
> unmotivated and to nothing
>        8.                        As such, the silence on GNSO BOARD is
> only
> matched by the silence on the main Board on IDN and other issues.  This
> level of silence, have resulted in the external threats to become REAL -
> china etc.  This silence I think also led to a few, dominating to prevent
> ideas they often arbitrarily did not like about something they never
> wanted
> to do (allow multilingual domains) and then after preventing the matter,
> did
> not helping with the actual carrying out of successfully, that which was
> agreed to by default.
>
>                John:
>        While "WWIII" is probably hyperbole, I believe the most
>        efficient way to get us to alternate roots and a badly
>        fragmented Internet would be to respond to the perceived
>        requirements for increased internationalization with a "just say
>        no" attitude or one that can be interpreted as people from
>        industrialized countries trying to keep populations from
>        less-developed areas from using the Internet effectively.
>
>        On the other hand, unless you succeed in persuading everyone in
>        the world to adopt a writing system that uses Roman characters,
>        the argument for IDNs, and IDNs at the top level (at least in
>        appearance to the user) will not disappear.  If we are going to
>        do such things by entering names in the root, then it is useful
>        to know what will work, what will not, and, to the extent to
>        which we can make estimates, what the operational impact will
>        be.  I believe we should all be quite concerned about making
>        root changes without at least some of that experience and
>        knowledge.  If people want to run experiments, then those
>        experiments should be both controlled and informative.  The
>        choice of 20 was based on an estimate of the minimum number
>        needed to give us some useful information.
>
>        Sophia:
>        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.
>
>        Perhaps the current IDN committee should get us all upto speed on
> the Katoh-committee recommendations and why they suggested what they did
> and
> why we are proceeding along the lines of what we are doing - reasons for
> and
> against. We can always make different decisions from the Katoh-committee
> recommendations.
>
>        John:
>        > 2)- Unfortunately English is the default language of the
>        > Internet today and it is likely to continue to be. Nobody
>        > questions that in a serious way - but what everyone wants I
>        > believe is a reasonable usable field in every major language
>        > today etc. for non-english speaking populations.  Without
>        > having to be condescending to the "non-West" as I am certain
>        > they do understand English is here to stay, what we want to do
>        > is really keep the other languages alive.  From what I have
>        > gathered, it seem that past discussions on this issues suggest
>        > 'Textbook thinking" without due consideration of  is what the
>        > "non-US/West" wants.   If we out to call it IDN and ICAAN
>        > represents a true international organization, we need to NOT
>        > only talk the talk, but walk the walk, applying  the
>        > cornerstone of globalization in a realistic way,  'think
>        > global, act local'.
>
>        I think that some of us who have been working on these issues
>        for many years are at least as sensitive to these issues... and
>        to finding ways to make things work effectively with a variety
>        of scripts and languages, as you are.   Some of us have even
>        spent a good deal of time working with people in the "non-US/
>        non-West" trying to accomplish that while also trying to
>        preserve the integrity of the DNS as a global Internet-object
>        referencing resource.  The problems are complex.  The DNS is not
>        an ideal solution to many of them for reasons that have little
>        to do with English or even Roman characters.  The nature of
>        those problems and the range of alternatives have been rather
>        extensively explored outside the ICANN and Roman-script
>        contexts, especially in East and Southeast Asia.  At the same
>        time, slogans may not be helpful (e.g., the only practical way
>        to realize "think global, act local" with regard to IDNs is to
>        get internationalization issues entirely out of the DNS -- an
>        IDN in the DNS is inherently global because the DNS is
>        inherently global) and wishing the DNS, or the Internet more
>        generally, worked in a way significantly different than it does
>        won't make it so... any more than lamenting how much easier
>        navigation would be if only the earth were flat is helpful to
>        either navigation or earth-flattening.
>
>
>
>        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.
>
>
>        Sophia> 3) I may be presumptuous, but ICANN's argument of resorting
> to
>        > using DNAME seem to come  from the perspective of how ICANN
>        > failed to be responsive for long and now "China" and others
>        > are threatening to "break the single root".  Therefore,
>        > perhaps, we were left to a single view and a quick solution,
>        > neglecting to entertain the CHOICES we may have for IDN.  So,
>        > the easiest implementation approach is DNAME, which is is to
>        > just give the big registries all the languages without having
>        > to change much in the technical stuff - ie. just re-point.com
> <http://re-point.com/>
>        > to every language equivalent - no new TLDs etc.
>
>        John:
>        Actually, I think you misunderstand both the situation and the
>        history.  First, DNAMEs are, in Internet time, a relatively old
>        proposal and protocol specification.  I didn't invent them and
>        neither did Verisign.  Second, there was a proposal from the
>        original ICANN IDN committee that no IDN TLDs be permitted in
>        the root except on a separate application for new TLDs process.
>        For an number of reasons --almost all of them consequences of
>        how the DNS actually works and what is and is not possible as a
>        result-- I still believe that was a wise recommendation,
>        independent of anything China, Verisign, or others might "want"
>        to do.   Some of those who are still on the GNSO Council will
>        probably remember that, because of issues with the number of
>        languages in the world, I recommended that we try to sort out
>        the use of IDNs at the second level and below in relevant ccTLDs
>        before permitting them to be used at all... and recommended that
>        several years before China made essentially the same suggestion
>        (of course, by the time they made that suggestion, it was
>        already too late since several gTLDs were doing production IDN
>        registrations).
>
>        Now, there has been a good deal of pressure from a number of
>        directions to create aliases for country names in national
>        languages.   That pressure has actually been much more intense,
>        with more threats, from other directions than from China.  If an
>        alias is what is really wanted and that alias must, for
>        technical or political reasons, be in the root, then DNAMEs are
>        the right way to do so.  Other solutions are simply not aliases,
>        they are separate domain names.  To me, for separate domain
>        names, the original IDN Committee/Katoh-san recommendation
>        should still apply.    As with IDNs below the top level and the
>        "what languages" question, I understand the idea of an alias for
>        a ccTLD in the relevant country's national language(s) much
>        better than I understand what to do about gTLDs.   Indeed, if I
>        could make recommendations for the GNSO, I would seriously
>        consider a recommendation that, at least for the next several
>        years, the top-level IDN issue is, except for possible
>        completely new applications domains with IDN-style names,
>        entirely a ccTLD problem and that the gTLDs should not
>        participate in any way in the evaluation of what is possible and
>        reasonable other than continuing to register second-level IDNs
>        under existing rules.
>
>        Sophia:
>        I am aware that DNAMES has existed for a long time as a technical
> part of the DNS structure. You and Patrick pointed it out in your recent
> IETF document that was circulated. But you also point out DNAMEs was never
> really invented with IDN in mind and in fact there is some hesitancy for
> "borrowing" it for this purpose of IDN. From my crude understanding the
> reasoning appears to be it would be ideal not to use something for which
> it
> was not really intended.
>
>
>
>        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.
>
>
>        Sophia> John's statement butteres this point:
>        >
>        > If a such programmer in China were to decide that, for her
>        > users to have a good experience, .US and .COM should be able
>        > to be referenced by using Chinese names, there is nothing that
>        > the GNSO, ICANN, IETF, ITU, or the Great Pumpkin could do to
>        > stop or prevent it. Even the control of the Chinese government
>        > would be _extremely_ limited, since those Chinese names would
>        > be visible only to users of that particular application with
>        > that particular extension, and not "on the wire" or to either
>        > DNS servers or the sites or hosts being reached.
>        >
>        > I think if this is the way we have looked at it, it seem that
>        > our response is shortsighted (because it technical-oriented
>        > only and did not consider the business issues)  and is perhaps
>        > why ICANN has failed achieve success in the IDN arena.
>        > Instead of worrying about the political, policy and cultural
>        > implications, first, we may have focused on the easy way
>        > out...technical.   In this case, contrary to what Cary said, I
>        > think  issuing DNAME is equally reckless as using new TLDs in
>        > IDN.
>
>        > The fact that the Chinese has already launched this process
>        > (if we out to call them reckless)  and ICANN who ought to know
>        > better, is forced to 'follow' the same (can we call ICANN
>        > "reckless") as well?  Uhmm.
>
>        John:
>        Again, please understand enough about how the DNS works, and how
>        name resolution and applications on the Internet work more
>        generally, to be able to understand what is said above.  The
>        Chinese have not already "launched" anything along the lines of
>        what I suggested.  That proposal is not "technical-oriented
>        only" and does consider the business issues (even if the
>        business and cultural issues it considers critical might not be
>        the same ones you would choose).  That proposal was actually
>        almost exclusively focused on political, policy, and cultural
>        issues -- many of the technical folks, who prefer a less complex
>        world, actually don't like it.  And that proposal is not, in any
>        way, related to DNAMEs -- it is a third alternative.
>
>        As to whether "issuing DNAME" is "equally reckless" as "using
>        new TLDs in IDN" (whatever that means), I would, again,
>        encourage you to understand what is being proposed and what its
>        technical implications are, if only because doing so is
>        prerequisite to talking intelligently about the business issues
>        (or even most of the political and cultural ones).  The "new
>        domain" issues are simply a superset (a rather large superset)
>        of those associated with DNAMEs.  DNAMEs supply aliases but, as
>        I pointed out long before the GNSO became actively concerned
>        with this, one still needs to decide who gets which names and
>        what they point to.  New domains raise the much more complex
>        issues of allocations and operation, and domain-specific
>        policies as well as those of name selection and assignment,
>        issues that are largely invisible from the DNAME case.
>
>        Could one adopt a DNAME model and reserve names for later
>        "independent TLD" allocation?  Of course.  Could one restrict
>        the DNAMEs that would be associated with gTLDs to some limited
>        set, or even to zero if that were felt to be wise?  Of course.
>        There is nothing that is "all languages in the world or nothing"
>        about any of the proposals I have heard seriously raised.
>
>        Sophia> *Ok, pls correct me if I am wrong when I am trying to speak
>        > DNAME implementation approach:*  eg. CEO of mybrand.com
> <http://mybrand.com/> has to
>        > be protected in every language under a gTLD that means "com"
>        > in every language, right ?  meaning they have to come up with
>        > 200 language translations of ".com" and ICANN can approve
>        > DNAMES.
>
>        John:
>        No, they do not.  And the fact that they do not is actually one
>        of the attractions of the DNAME approach (except to the
>        registrars and registries who are anxious to mount "there is now
>        another new domain in which you need to register to protect your
>        brand... please send money" campaigns.  _That_ approach requires
>        separate domains).
>
>        Sophia>  Then these companies, like Versign, can go and get
>        > everyone of their.com <http://their.com/>  name holders (40
> million in this case)
>        > names translated / transliterated into 200 languages to
>        > everyone's satisfaction and register them all to get 200 x 45
>        > million DNAMES.   *I hope I am on right track so far.*
>
>        John:
>        No, you are not.  Please read the comments above and, more
>        important, please make an effort to understand how the DNS works
>        in general and how DNAMEs work in particular.
>
>         Sophia> Are they also going to charge the CUSTOMER (who has
> already
> paid
>        > some $6 already) for the translation/transliteration work?
>        > Also, if the customer then is upset by the accuracy of
>        > translation or if the customer is sued by some other third
>        > party saying that the wrong translation now impinges on their
>        > own business, will VERISIGN pay for all lawsuit damages? I am
>        > almost certain that these companies will NOT agree to this -
>        > but this is the result of DNAMES.
>
>        John:
>        No, it is not.
>
>        Sophia> Finally, from where I see it, *policy is to be made first
> in
>
>        > complex situations as these.* Technology is a second - fact is
>        > these systems seem to have been working for years already, as
>        > China seem to have has deployed it for years on a large scale
>        > - far larger than anything ICANN has done to date, I believe.
>
>        John:
>        No, China has done something else, and only relatively recently.
>        Once you understand, throughly, how the DNS works and, in
>        particular, the difference between the actions of a caching
>        forwarder and a different TLD, I'll be happy to try to explain
>        just what they are doing, and why, to you.
>        ...
>        Sophia> Therefore, as Avil suggested, I propose the alternatives
> and
>        > solution should be explored by a joint consultation with
>        > relevant IDN circles and the Council.
>
>        John:
>        Sure.  As long as the capabilities and operations of the DNS are
>        sufficiently well understood, and at a policy level, the range
>        and scope of potential ICANN authority is reasonably well
>        understood, that discussions of policies that imply flat earths
>        and more convenient values of PI are avoided.  Otherwise, while
>        the discussions would certainly be interesting, the GNSO will
>        waste its time and the world will ignore ICANN and move forward
>        on its own path.
>
>        Sophia> I myself recommend the POLICY option.   Go for a solution
>        > letting the people speaking a specific language (or script as
>        > they like to say) is a part of their culture – to take care
>        > of it.  We can talk about specific implementation strategies
>        > once we agree with the policy option!
>
>        John:
>        First, the proposal that comes closest to the type of solution
>        you seem to propose above is one that you have rejected out of
>        hand.  Second, scripts and not the same as languages and people
>        don't speak scripts: not understanding the difference can only
>
>        ;p0increase your confusion.  Third, as long as the DNS is to remain
>        a global resource, a solution that involves letting those who
>        speak a particular language to "take care of it" and go in their
>        own direction is essentially impossible.  Or, to put it
>        differently, it is possible in only two ways: with client-level
>        aliasing (which you have rejected) and with different DNS roots
>        for each language group.   The latter is inconsistent with both
>        unambiguous global references on a global Internet and, by the
>        way, with your having any possible hope of protecting your
>        business name or trademark globally... except by legal action in
>        each country in which a similar name might be used.
>
>        regards,
>           john
>
>
>
>
>
>
>
>
>