Skip to main content

How global domains can cater for local preferences

Last year, American retailer Wal-Mart gave up in an attempt to expand into Germany, and one of the reasons they cited was that they didn’t understand the local market. “Did you know that American pillow cases are a different size than those in Germany?” Wal-Mart Germany CEO David Wild asked Welt am Sonntag.

Hearing this reminded me of an apocryphal story told to me by a friend. When IKEA, the Swedish furnishing store, opened up in North America they were surprised. Their vases were selling better than expected, and they did not know why. An investigation of their customers revealed that in fact they were buying the vases as drinking glasses, because IKEA’s traditional European sizes were too small.

Every country has their own unique needs, and one of the ways this is recognised in the domain name system is through country-code top-level domains, or ccTLDs.

You can tell country-code top-level domains from others in that they are two letters long. For example, Canada operates the country-code domain of “.ca”, whilst Spain operates “.es”.

Each of these countries is empowered to operate these domains within their countries, under their own local laws. Domain name policies, pricing structure and so forth are fully forged within the country. The local Internet community and local government all have a role to play in deciding how their country’s country-code is operated. ICANN, through its IANA function, is involved in this discussion when it comes to assigning or reassigning operators, but is not involved in the day-to-day operation of country-code top-level domains.

Another thing ICANN is not involved in is deciding the actual codes, or what constitutes a country eligible for a code. Valid country codes are defined by the ISO 3166-1 standard, which is used internationally not just for domain names — but for physical mail routing, currency codes, and more. The ISO 3166 Maintenance Agency is responsible for keeping the list of codes up to date, taking advice from the United Nations Statistics Office on what constitutes a country eligible for a country code.

By ensuring ICANN is not tasked with deciding what country codes are valid, ICANN can focus its coordination role by ensuring the country-code domains in the DNS root zone match those allowed by the ISO standard. When new countries are formed, new ISO codes are created, and ultimately they can be added as new country code domains. Similarly, countries disappear, their codes are revoked, and they are retired from the DNS root zone.

The procedure of retiring country codes when the country no longer exists is the focus of one of our current calls for public comment, closing January 31st. Whilst some communities have been diligent in transitioning away from their expired country-codes when they have been replaced by new codes, other closures have taken longer. Our aim is to create clear, predictable and transparent procedures so that there is certainty for registries, registrants and the community on the process for decommissioning an inactive country-code domain. This will help communities to migrate to the appropriate new country-codes reflecting their new country.

Another interesting aspect of country-code domain policy is how to consider expanding the concept to codes that are not in Latin script. The ISO 3166-1 code list only uses the letters A to Z, but a clear desire has been expressed to use more familiar characters in countries not familiar with Latin script. This gives rise to a number of big questions. Will the concept of country-code top-level domains translate into internationalised domain names? Without an independent agency like the ISO 3166 MA, how will the appropriate codes for countries in various languages be decided? Should multiple domains for the same country be synchronised in some way? These questions, and many more, are a hot-topic of discussion amongst the various constituencies within ICANN.

These two topics are a few of a number policy reviews and procedural clarifications that ICANN has commenced concerning country-code top-level domains. Other reviews are being conducted with more of a technical focus, ensuring our procedures are appropriate and robust. This has been met with great support by the domain registry technical community. As always, feedback is very welcome so we can continue to refine and improve the framework so its consistent, reliable and responsive.

Kim Davies
Internet Assigned Numbers Authority

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."