The 2004 new sTLD round brought about a new type of TLD in the form of .asia and .cat. As we always struggle for words to capture their nature, I call them “geoTLDs”. Culture, language and ethnicity are also part of geography.

Contrary to ccTLDs, geoTLDs do not have a territorial meaning. They are a wonderful addition to the Internet as they provide a way to demonstrate one’s commitment to a community that is not defined by borders, yet linked to where the individual chooses to be.

A number of language communities have come forward and describe the strings they propose. Have a look at .cym, .sco, .gal or .bzh. Other initiatives are regional, such as .lac, for cities, such as .berlin or .nyc. GeoTLDs will be a significant component of the next TLD introduction phase, I believe.

Will they be? They will, unless we do the wrong thing now.

Feed them to the speculators, or send them down the infinite loop?

Initially, the discussion in the GNSO PDP oscillated between these extremes.

One mistake would be to send geoTLD applications to an infinite loop. And indeed, at the Wellington ICANN meeting, one proposal went as far as to say: “we cannot define any policy on place names”. That is the infinite loop. Who else will ever define a policy?

The other mistake would be hand them out to the cyber-real-estate developer with the deepest pockets. This was indeed implied in the first consensus for the first-come-first-served approach on the TLD level. Speculators can move swiftly, communities have to do their homework. Taken literally, first-come-first-served implies that the natural community of a Geo name wouldn’t have a chance against a speculator.

Emerging consensus? The TLD community matters

During the Amsterdam meeting of the GNSO council, significant progress was made to establish a relationship between the TLD string and its community—or its communities. The idea is to use the concept of community support. For the time being, this merely appears as a way to deal with contention.

Deriving the TLD requirements from the meaning of the string

Of course that is only a first attempt to find a wording. I believe that we should not look for a single generically phrased principle, across all types of TLDs. The criteria must depend on the meaning of the TLD string, at least in the case of geoTLDs. It is obvious that an international city name cannot be subject to the same criteria as the name of a small town. Nor can the name of a large ethnic or cultural group be treated like the name of a domestic animal.

Dirk Krischenowski from dotBerlin and I have worked a bit on that approach. Rather than throwing all geoTLDs in the same basket, we propose to look at the properties of each name. In the case of geoTLDs, this leads to about half a dozen key properties. From each property, it is relatively easy to derive the logical requirements. If a name matches more than one property, a TLD proposal to use it should obviously satisfy all the requirements.

As a byproduct, the line that separates ccTLD-IDN from gTLD-IDN

The meaning-based approach also helps differentiate between gTLDs and ccTLDs in the case of IDN.IDN TLDs. A given IDN string may be a popular name or abbreviation for an ISO-3166 territory. If its meaning matches the territory, one can safely regard the string as an IDN equivalent of a ccTLD. How this should be handled is of course up to the relevant community, and logically subject to ccTLD principles. If the meaning is not congruent to that of a country code, then it can be treated as a gTLD that must satisfy the requirements linked to its meaning.

All this is to say that geoTLDs have a big role to play thanks to their diversity. Diversity solves problems. We don’t have to create it, it is there. We just have to take into account the meanings (mind the plural) of the TLD strings proposed.