ICANN/GNSO GNSO Email List Archives

[ga]

<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Draft Revised IDN Guidelines: Public Comment Period

  • To: "GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>, ga@xxxxxxxxxxxxxx
  • Subject: Re: [ga] Draft Revised IDN Guidelines: Public Comment Period
  • From: "M. Morfin" <jefsey@xxxxxxxxxxxxxxxx>
  • Date: Fri, 23 Sep 2005 03:05:22 +0200
  • In-reply-to: <43312DA3.9060408@gnso.icann.org>
  • References: <43312DA3.9060408@gnso.icann.org>
  • Sender: owner-ga@xxxxxxxxxxxxxx
At 11:53 21/09/2005, GNSO.SECRETARIAT@xxxxxxxxxxxxxx wrote: 
* The registries will follow established authoritative language tables
when such exist.

This is a violation of the ccTLD sovereignty as the trustees of their national community. A total contradiction with point 4 to talk about "language tables" and then to call for a policy based on scripts. There can only be "Script tables". They are authoritative by the decision of the TLD Manager.

There is a total misunderstanding of the homograph phishing. It does not concern more IDNs than DNs. It is a result of the IDNA. IDNA is an application level function which translates ASCII "xn--xxxx" DN labels into ISO 10620 strings. Whatever the DN.

* The registries will not permit the co-mingling of scripts in a domain
label when no language table exists.

Registries have absolutely no way to do that except for SLDs where phishing is of low interest.

* The successor document to the current guidelines must maximize the
ability of a registry to support IDN in all regards where it is
reasonably needed, and must minimize the ability for the abuse of IDN
for deceptive purposes.

This is like saying "guns are dangerous for life. Guidlines will maximize the ability to use them to defend you home and minimise the ability of robbers to use them in your place" and to expect this will prevent worldwide wars.

* Policies based on script are needed in addition to those based solely
on language, and developing script-based policies should be an immediate
focus of action.

DNs happen to be written. Languages are of not real interest here except for relations with registrants (regustration form, contract, support). A name is not related to a language. Is "jefsey.com" French, English, Spanish .... Tables are charsets. We talk of charsets. Relating them to a language is an error which has always been explained.

Following the Luxembourg ICANN meeting, a working group of registries
with IDN experience was formed to work on a revision of the guidelines,
to be put forth for public comment. The working group includes the
following members:

* gTLD Registry Constituency Representatives:
Cary Karp, MuseDoma
Pat Kane, VeriSign
Ram Mohan, Afilias

* ccNSO Representatives:
Hiro Hotta, JPRS
Mohammed EL Bashir, .sd Registry

* ICANN Staff:
Tina Dam

May be could we invite them on this list to help them, or we will still be stuck in this language mess for years. Actually this mess has a well defined pupose for avery few: to eventually delegate, out of complexity and network load, the IANA lingual part to a consortium which "knows" what it is talking about. I doubt it knows about this, but it knows why and how controlling the IANA lingual aspects is important for its members.

jfc






<<< Chronological Index >>>    <<< Thread Index >>>