Getting with the .PROGRAM

With all the attention and fervor surrounding the gTLDs that are poised to launch as part of the New gTLD Program, it’s easy to forget that other new top-level domains have launched over the past year or so. These include .SX and .CW, the country code extensions for Sint Maarten and Curacao, and .POST, the recently delegated top-level domain sponsored by the Universal Postal Union. According to a recent post on Domain Incite, it’s not just businesses and Internet users who have overlooked these newly launched TLDs – apparently, major browsers have as well.

Domain Incite points out that some of the most popular Web browsers, including Safari versions 5 and 6, Internet Explorer 9 and Chrome v24, have had trouble resolving functional domain names in some or all of those extensions. Websites in each of these TLDs have been live since 2012 – even .POST, the most recently launched of the three, has hosted live second-level domains since October. And yet, some of the world’s most popular browsers are having trouble recognizing these TLDs as legitimate domain extensions.

This browser confusion raises an interesting issue for the owners of future new gTLDs, as well as for any company or individual that owns an interactive, public-facing website. That is, the issue of new gTLD compatibility. The way Web browsers work, on a very simplistic level, is by checking the domain names that users type into the address bar against a set of viable options, both at the top level and at the second level. Essentially, browsers perform a task of validating a domain name – if it is valid, the browser returns a website; if not, it returns an error page or (as in the case with Google’s Chrome), it redirects to different content.

But Web browsers are not the only applications that perform this kind of validation. Any given company or corporation has multiple systems, applications and forms that have to perform a similar task. As an example, think about the feature most websites have that allows an Internet user to sign up for emails. It seems simple enough – the user types in his or her email address and gets added to the company’s database. But a system has to check that email address in order to determine if it is valid or not, and it does so by validating the domain name. Gmail.com is a valid domain for an email address, but Mail.Google, for example, is not (yet).

Other systems that perform this type of domain validation include pages that require login credentials, ecommerce checkout platforms, bill payment systems, job applications, email contact forms, mobile applications, invoices, order management systems, and lead capturing or sales systems.

The problem is that currently, most systems that validate domain names – either in email addresses or for other purposes – check the domain against a static list of possibilities. This has generally worked in the current landscape because the number of domain extensions was finite. But as the .SX, .CW and .POST example proves, relying on a process of updating the static list every time a new extension is added can lead to errors. Instead, businesses and website owners should focus their efforts on developing dynamic domain validation systems.

All businesses will need to be aware of the issue of gTLD systems compatibility and prepare to respond to it in the next four to six months, as the first new gTLDs begin to launch. This will be an important step to staying current and adapting to the new digital landscape. But more importantly, businesses that fail to keep up when it comes to gTLD compatibility could risk losing sales or customers.