[ga-roots] Some Comments on Multilingual Domains (MLDs)

["Alternate Chair, GA" <patrick@corliss.net>]

Re-Posted from the ORSC Domain Policy List.

From: Stefan Probst <stefan.probst@opticom.v-nam.net>
To: idn-survey@icann.org
Cc: ISTF Discussion List <istf-participants@lyris.isoc.org>,
      ORSC Domain Policy <domain-policy@open-rsc.org>
Date: Thu, 17 May 2001 15:54:07 +0700
Subject: Some comments to MLDs

Dear ICANN Working Group on Internationalized Domain Names,

I am sorry for answering to your questions a bit late - hopefully not too
late.  I came across them only by chance. A small post e.g. to the ISTF list
had surely raised some more comments.

Allow me to post some thoughts:

1. Naming
I wonder, why you call this "Internationalized Domains". Is a domain in an
American Indian's script an "international domain", or rather a
"multilingual domain" (MLD)?

2. Verisign's "Testbed"
Versign started its "testbed" with mixed appreciation of its usefulness.
ISOC discouraged it, but Verisign went ahead, and by indicting that they
would transfer testbed registrations later without additional charge to the
live gTLD zones, they put registrars into a difficult situation: comply
with ISOC's requests and wait with MLD registrations, or accept MLD
registration in order not to loose customers.

Registrants on the other side, as much as they might have wanted to honour
ISOC's request, had to register their rightful names in the testbed, in
order to be sure, not to loose out, once MLDs are accepted in the live
gTLDs, i.e. existing testbed registrations would be transfered to the live
zones.

For everybody it has to look, like Verisign is dictating the conditions,
not ICANN.

3. Verisign and NSI
Verisign had published a time table when they would accept registrations
for which script. UNICODE was after a while scheduled for 5th of April. At
that time, the Network Solution webpage for testbed registrations was way
outdated. I think it said UNICODE registrations would be available by early
March, i.e. the page was done early February and had not been updated until
5th of April. The page was in a language, which didn't suggest, that NSI
was waiting for Verisign, but they themselves would be ready with their
setup until the given times. Without further explanation, Verisign then
delayed UNICODE for the 19th of April. On that date the page on NSI changed
and they accepted registrations.

One cannot help but wonder, whether Verisign delayed the process, because
NSI was not yet ready, and to start earlier had meant much lost revenue for
NSI (other registrars were ready already).

I am aware, that this is a vague suspicion, but in case it would be true,
who could proof it?

4. Register.com
Register.com was one of the few registrars, which accepted
"pre-registrations" for UNICODE domains, even before the 5th of April,
claiming, that they would try to register them, as soon as possible.

On 19th - and even until the 23rd of April, none of the Register.com's
pre-registered domains showed up in whois, and it was even possible to
register them with NSI (again).

Some days later, Register.com informed registrants, that their domains had
been accepted and charged for it. However, until today, those domains show
up in whois only as "registered by Register.com", but don't show the
registrant (whereas the NSI registrations do). This leaves registrants
neither a chance to check "first come, first serve" principles, nor to
fight cybersquatting at an early stage.

5. Client Applications
As far as I know, none of the current client applets (to do the foreign
script to *ACE conversion) supports UNICODE.

Customers in "UNICODE countries" therefore cannot participate in Verisign's
"Phase 3.2" (current) and "Phase 3.3" (which should start soon). A
"testbed" where the testing cannot be done is rather useless.

6. Blocking of MLDs
I didn't find any policy stated, what would happen to domains, which are
directly registered in their *ACE form, before "official" registrations (or
the transfer of testbed domains into the live zones) will occur.

7. Ease of use of Whois.
To check whois info on MLDs (in the testbed) is right now a cumbersome
multistep-procedure: transform the MLD version via an online tool into its
RACE version, then copy and past this RACE version into a whois form on
some other websites.

There need to be tools to make this easier for non-techies.

8. Open Source
I strongly suggest to adopt only technology where, and to "go live" when
required tools (like those applets below) are available under an Open
Source License, so that they can be easily adapted to local languages and
to different computing platforms.

9. MLDs and "alternative TLDs".
During the introduction of the MLDs, every Internet user who wishes to
access those MLD domains has to install a small applet to do the conversion
to a DNS compatible *ACE string. This will make it very easy for companies
like New.net to offer those applets with "double functionality": new MLDs
and at the same time a new root (e.g. the New.net root). Looking at the
latest published numbers from New.net, it seems to me, that ICANN is on the
best way to loose the battle.

If it obviously cannot win on its own (anymore), then it might make the
most sense to look for allies, and the group around the ORSC/Superroot
seems to me the best option. By peering the ICANN root with their root,
there would be immediately lots of new TLDs available for everybody on the
Net (whithout the need for plug-ins), and New.net with their conflicting
TLDs had to fight against lots of TLD holders. The ORSC looks like very
reasonable, has obviously the most "historical legitimacy", and seems to be
willing to co-operate with ICANN.


So far a few thoughts to the subject from my side.

Sincerely,
Stefan Probst,

ISTF, ISSG.



--
This message was passed to you via the ga-roots@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-roots" in the body of the message).
Archives at http://www.dnso.org/archives.html