ICANN ICANN Email List Archives

[gnso-idn-wg]


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

RE: [gnso-idn-wg] One string per application

  • To: "'Tan, William'" <William.Tan@xxxxxxxxxxx>, <gnso-idn-wg@xxxxxxxxx>
  • Subject: RE: [gnso-idn-wg] One string per application
  • From: "Olof Nordling" <olof.nordling@xxxxxxxxx>
  • Date: Sat, 17 Feb 2007 15:33:50 +0100

Dear Wil and all,
The example you bring up is very much to the point regarding the handling of
variants within a script for a top-level label, which we have brought up as
a topic in the discussions under the "techno-policy details" heading. I
suppose more will follow on that one.
Best regards
Olof

-----Original Message-----
From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On
Behalf Of Tan, William
Sent: Thursday, February 15, 2007 11:32 PM
To: gnso-idn-wg@xxxxxxxxx
Subject: [gnso-idn-wg] One string per application

Dear all,

This may be a bit premature but I'll bring it up anyway given that we 
will eventually get to the "Existing gTLD Strings" topic, and that the 
following has at least some overlap with the "Introduction of New gTLDs" 
topic that we discussed in the last call.

In one of the documents that Olof sent out in preparation of the Feb 6 
calls, we had the following bullet point under "Existing gTLD Strings":

    4.1 Agreement that the approach of the New gTLD PDP is one string 
for each application.

Have we considered provisions for TLDs in scripts that require bundling? 
This is at least applicable to Chinese domain names, where variants are 
widely regarded as necessary for proper utility of the TLD (or, more 
generally, the domain name.)

For example, if someone were to apply for .西雅? (Traditional Chinese 
transliteration of Seattle), it would only make sense to have .西雅图 as 
well so that people who use Simplified Chinese (China, Singapore) can 
expect to find it. By restricting applications to a single string, the 
utility of the TLD would be vastly reduced.

Thoughts?

Best regards,
=wil





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

Privacy Policy | Terms of Service | Cookies Policy