Avri, Werner, Edmon, Sophia, all,
I would first like to express my support in the views of Edmon and Sophia.
Furthermore, I would like to re-visit the core issues that troubled 
those people that addressed Avri. I generally think that they are 
wrong in their fears and in there views, and I'll explain why:
   1. IDNs have been created to remove the language barrier for those
      the English/ASCII script creates a barrier to use the Internet.
      The whole idea of IDNs is to solve LOCAL community barriers,
      from the language/script side. They were not intended and would
      not be able to solve local government censorship. Isolation of
      local Internet communities and restriction of freedom of speech
      already exists these days in several countries, and is
      controlled by governments through different technical methods
      including the monitoring of email communication, the blocking of
      IP addresses and domain names, etc. These methods will continue
      to exist after IDNs are launched. IDNs are not intended to solve
      this problem, not would it matter or solve the problem if they
      are aliased to an ASCII TLD.
   2. Furthermore, the use of IDNs would enable more people in the
      world to be exposed and enjoy the enormous possibilities of the
      Internet. IDNs would certainly reduce the barrier for
      local/language communities that currently do not use the
      Internet. I believe the existence of IDNs will not affect the
      policy of those certain governments and they might continue in
      their censorship. But if those communities will be relieved from
      the language barrier, with time they will be more and more
      exposed to the goods of the Internet, and the censorship would
      certainly become weaker and weaker. One of the main strengths of
      the Internet is in the fact it allows easy and cheap
      communication among its users – and I believe that even if this
      communication would be made within censored communities – on the
      long run these communities would be far better off regarding
      freedom of speech, new ideas, knowledge, etc.
   3. About the email issues – I would first like to remind all of us
      that we are currently talking about Internationalized Domain
      Names. Although I believe that one of the immediate and most
      important applications would be IEAs (Internationalized Email
      Addresses) their full implementation is more complicated (from
      the technical side), and it would take time till email software
      vendors would develop supporting versions, and some more time
      till ISPs and email service suppliers would implement it.
   4. IEAs are certainly intended for use within local/language
      communities. It is clear that communication using IEAs from
      people of that community traveling or leaving abroad would need
      special measures. Yet, this could be simply solved in many ways;
      one is for example – a web-based IEA solution that also offers a
      web-based keyboard in the designated language. Such services are
      actually available today for the typing of email content in
      local languages without having IDNs and IEAs implemented yet.
   5. I do not believe that IEA's should or would replace the use of
      ascii email addresses. Nor would IDNs replace the use of adcii
      domain names. It is to my belief that those that English is a
      barrier to them, would use IEAs nd IDNs, and those from the
      local communities that English is not a barrier to them would
      use both. The fact that IEAs and IDNs would exist without having
      an alias in ascii, has nothing to do to whether those people
      will or can communicate with people outside of their community
      using English (English in general – the email address is just a
      part of it). English would probably continue to be the common
      international communication language – also in domain names and
      email addresses, while other languages will be used in IDNs and
      IEAs for local communication in local/language communities.
   6. Regarding IDN ccTLDs – Sophia stated that IDN ccTLDs should not
      be automatically given to current ccTLD registries. And I would
      like to add - who said we must have IDN ccTLDs at all? I believe
      that if we are able to implement one to a few gTLDs in each
      relevant non-ascii language/script it would be more than enough,
      and I am not sure whether going on an IDN ccTLD path would not
      bring us to a point where we have hundreds of IDN ccTLDs in each
      language, which will expand the name space to enormous levels,
      while creating many new problems – political (think about the
      .il – Israel's extension in Farsi – who will get it? The
      Iranians?!?! Israelis?!?! ...), legal, etc..
To summarize, I believe that:
- Ascii aliases are not needed.
- IDN TLDs should not be automatically given to anyone. Process should 
be open and free.
Best,
Yoav
------------------------------------------------------------------------
*From:* owner-gnso-idn-wg@xxxxxxxxx 
[mailto:owner-gnso-idn-wg@xxxxxxxxx] *On Behalf Of *Sophia B
*Sent:* Saturday, February 24, 2007 9:11 PM
*To:* Avri Doria
*Cc:* gnso-idn-wg@xxxxxxxxx
*Subject:* Re: [gnso-idn-wg] Passing on a request for aliasing of IDNs
Dear Avri,
Thanks for sharing this with us. I think it is interesting as well.
    A concern that if site or email addresses can only be accessed with
    an IDN keyboard, then those using IDNs will essentially be cut off
    from the rest of the internet. I.e those without the right keyboard
    would not be able to communicate with them.
    - A compounded concern that this would lead to greater pressures for
    isolation and restriction of freedom of expression in certain
    countries.
    - A concern that when these people travelled abroad, they would be
    unable to communicate with people back home if they did not bring
    their national keyboards with them - i.e. it would prevent them using
    cyber cafes, borrowing a western friend's laptop or using the
    ubiquitous keyboard one finds at conferences etc.
However, first of all, allow me to kindly say that the three (3) 
differnet reasons you gave above are one and the same. So basically, 
these people while there concern is valid, are worried mostly about 
cosmetics vs. substance of the global issues we are trying to resolve.
Therefore, I tend to agree with Edmond and his point of view than that 
of Werner. Werner's opinion is a bit premature and is based on the 
assumption that in cctld, the country-code IDN will automatically be 
GIVEN to the current cctld of that country. So far there is no policy 
of this nature , therefore, there is a good chance that the operator 
of IDN cctld may end up being soemone who is not the existing cctld 
operator. My sources substanciate this by telling me that the origianl 
Katoh-IDN commitee after 1 year of study by a panel far ORE 
international in character than the currnet GNSO expert group actually 
recomended to ICANN BOARD (its in archives) 3 years ago that the IDN 
cctld should NOT AUTOMATICALLY go to existing cctld. In fact maybe 
bidded out for etc.
My personal opinion on this is, the whole analogy as stated will 
bypass current ICANN's efforts to trying to get IDNs at the root and 
using ascii aliasing expediently to support the already tried and true 
failuer of DNAMES at a policy level, therefore a fruitless excersice r 
going in circles!
Regardng devise communication issues pointed out by the respectve 
persons, implying a full UNICODE can not be used on the devise, again 
is a superfical argument: Here is why:
a) having the alterative 'fallback mechanism' that Werner suggested 
maybe even discourage devise manifacturers from supporting future 
development of IDN based devises. If the mission is to have all 
devices capable of inputting IDN TLDs, then one should not have 
english fallback mechanisms, so the device manufactueres are 
incentivised to change.
b) The whole point of IDN was to quickly remove English barrier.
cI E7 finally supported IDNA not becuase of ICANN etc. but becuase the 
other browser manufactuers supported it.
d) Moreover, these devices are limited and in most cases the IDN 
ethnic poor we are serving do not own them anyway, so if we force them 
to support UNicode now, by the time they have the money to own them, 
the support will be there.
I strongly hope the group could see this view and question the damage 
that Dname or its fancy transation of 'aliasing' would bring. BTW, I 
am still at a loss on the interchangebility of ''DNAME' and 
'aliasing', which has been one of "confusingly similar' ascii string 
for most in the group;) Maybe, these two strings should be the 'test' 
we use for 'criteria' we are developing in GNSO policy over 
confusingly similar strings!
Best
Sophia
On 23/02/07, *Avri Doria* <avri@xxxxxxx <mailto:avri@xxxxxxx>> wrote:
hi,
I know this issue really isn't on the table yet, but I want to pass
on the content of an issue that several people passed on to me in
Geneva last week at the IGF consultations. I got essentially the
same request from 2 native Arabic speakers and 1 native Chinese
speaker. The request surprised me as I had not given it
consideration, but after several hours of conversations, it starts to
make sense.
The request was that IDN always be established with an unencoded
ascii alias (staying out of the implementation details). I was given
3 basic reasons:
- A concern that if site or email addresses can only be accessed with
an IDN keyboard, then those using IDNs will essentially be cut off
from the rest of the internet. I.e those without the right keyboard
would not be able to communicate with them.
- A compounded concern that this would lead to greater pressures for
isolation and restriction of freedom of expression in certain countries.
- A concern that when these people travelled abroad, they would be
unable to communicate with people back home if they did not bring
their national keyboards with them - i.e. it would prevent them using
cyber cafes, borrowing a western friend's laptop or using the
ubiquitous keyboard one finds at conferences etc.
Obviously one could require them to use the xn-- encoding but this is
almost as bad as using IP addresses (actually IPv4 addresses might be
easier to use then the xn-- encoding - IPv6 might be a challenge)
In any case I felt I should pass this concern on to this group.
a.