ICANN ICANN Email List Archives


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

Please add in to the fast track process notification to the browser applications

  • To: fast-track-review-2010@xxxxxxxxx
  • Subject: Please add in to the fast track process notification to the browser applications
  • From: Jothan Frakes <jothan@xxxxxxxxx>
  • Date: Sat, 30 Oct 2010 01:49:48 -0700


I am writing this in a personal capacity and not representing the
Mozilla Foundation in any formal capacity,  but I have been privileged
to participate as a volunteer with the Mozilla Foundation to liase /
aid with ccTLDs and gTLDs as I know and am on a first name basis with
many of the administrators.

I commend the ICANN ccTLD fast-track process as an example of a low
cost, high efficacy manner in which to delegate additional TLDs.

This entire program and those who made it possible are commendable.
The application process is (relatively) fast, has low costs, and
provides such valuable benefit toward making the internet a truly
global resource.

In the interests of expanded global benefit from these wonderful new
extensions, I have a suggestion for inclusion somewhere within the
fast-track process that I have socialized with some of the staff and
participants of the fast-track, but wanted to put in writing so that
it can be discussed and hopefully incorporated.

Because it has taken ICANN and the global community over a decade to
introduce more than a handful of new Top Level Domains, the root zone
has been typically treated pro grammatically like a static file.  To
compund upon this, root zone also only holds top level delegation,
(.uk) but authority below that is autonomous to the delegated party
(in the example .UK this would be Nominet) as to what is and is not a
valid subdomain (co.uk).

The latter of these two has been addressed by a number of parties, and
I am a volunteer that helps to manicure and curate the public suffix
list at Mozilla.

The problem:
The fluid and efficient manner in which new IDN ccTLDs have been being
introduced means that there are some notifications and updates so that
programs, networks, and services that will need to be updated, to
compensate for the presence of a static list of TLDs in software.
These requests should come from the administrators/registries because
these will have information about the IDN codepoints that will be
valid in the TLD as well as what subdomains should be expected by

Additionally, if there were some process whereby the recipients of
update requests could then validate that the requests came from an
approved party, to ensure that they are actually the registry contact
submitting them, this would benefit the integrity of the process

Anyway, there are third party resources that don't track the delta in
the root zone for new TLDs because they have come to expect a glacial
pace of new entries and mistaken it as being a static list.

I would like to request that within the fast track process, that the
administrator receive a checklist that indicates some of the global
resources that can be notified about the upcoming availability of
their TLD.
That checklist could include some websites / and/or contacts to update
at some point between the time that string evaluation has been passed
and the root delegation of the TLD,

Mozilla.org maintains two such resources which the global community
(and the TLD registry as well) would benefit from updating or adding
information for a new TLD, as many subsequently create derivative
lists from these as a main source.

1] Public Suffix List, located at this URL:

The public suffix list is a repository of Top Level Domains (:.com,
.ca, .fr)  and Second Level Domains (example: com.au, com.mx, co.uk)
under which one might see subdomains.
Software from Mozilla.org, as well as third party developers and
languages such as the Ruby Programming Language, as well as security
providers and many other applications and languages use this list to
provide a much more elegant and granular authoritative list of valid
TLDs when used in conjunction with the IANA root for programmatic
validation of domain names.

An official registry may submit their new IDN-ccTLD via this link:

Again, include any subdomains that will be in the zone, in native form utf8.

2] IDN-enabled TLDs

I would appreciate having official contacts from the registry provide
information for in order to ensure that the the links for the
following items using the link below:

* The Native String in UTF-8
* The English Word or romanized pronounciation of the native string
* The Punicode String (and the full punicode sting if there will be
subdomains at third level offered for each subdomains ie
xn--[punicode for network in code language].xn--[punicode for
* URL to the Registry Website
* URL to the IDN Policy

There are two areas that would be of great help for updating resources
that software developers everywhere draw from, and they will in turn
help make the promise and benefit of the new extensions available to
the global community of internet users.

It would be of great benefit to the larger community if this request
could be accomodated.

My feedback is otherwise that all things appear to be working
smoothly, and the fast-track program seems a success.

Thank you,

Jothan Frakes
.nxt - New TLD conference in San Francisco, February 9-10, 2011

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

Privacy Policy | Terms of Service | Cookies Policy