Re: [gnso-idn-wg] Passing on a request for aliasing of IDNs
Dear Avri, Thanks for sharing this. It was interesting. 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. First of all, allow me to kindly say that the three (3) different reasons stated separately are in fact one and the same. So basically, the peoples concern is valid, they are mostly worried about cosmetics vs. substance of the global issues we are trying to find resolve for. 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 someone who is not the existing cctld operator. As such, my sources tell me that the original Katoh-IDN commitee after 1 year of study by a panel far ORE international in character than the current GNSO expert group actually recommended 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. Myself, I am of the view that the whole analogy as stated attempts to bypass current ICANN's efforts to trying to implement IDNs at the root and using ascii aliasing expediently, to support the already tried and true failiuer of DNAMES at a policy level! Regarding devise communication issues implication that a full UNICODE cannot be used on the devise, is a superficial and perhaps false argument: Here is why: a) If you do allow a fallback mechanism, like Werner suggested, these device manufactures will NEVER change or very slowly. If your mission is to have all devices capable of inputting IDN TLDs then one should not have English fallback mechanisms, PERIOD, so the device manufactures are incentivised to change b) The whole point of IDN was to quickly to remove English barrier. c) IE7 finally supported IDNA not because of ICANN etc. but because the other browser manufactures supported it. d) Moreover these devices are limited and in most cases the IDN ethnic poor we were serving do not own them anyway, and 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 finance translation of 'aliasing' would bring. BTW, I am still at a loss on the interchangeability of ''DNAME' and 'aliasing'. They seem to be "confusingly similar' ascii strings;) Maybe we should be thinking to use them as 'test' strings in the PDP for 'confusingly similar'! Best;) Sophia On 23/02/07, Avri Doria <avri@xxxxxxx> wrote:
|