|
||
|
||
As new Top-Level Domains (TLDs) are launched, the industry mustn’t overlook the customer experience. A key question is this: Will the software applications we all use, recognize the new TLDs and know what to do with them in a timely fashion? Think email and even form-fill applications. I speak from experience here.
In 2006 when we launched the .MOBI TLD, there were arguably only a handful of .MOBI email addresses in existence. To my dismay, I found that often emails sent only from my .MOBI account were not being received at the other end. The reason: Email applications did not recognize the new TLD, and hence the emails were sent to the SPAM folder of the recipient. Web forms would also reject the email address for the same reason. At the time .MOBI was only one of the handful of new TLDs, which were added to the root.
But if new gTLDs are approved, this will be the first time in the history of the internet that a large number of TLDs are added almost simultaneously. Prior to the mid 1990s, there were few changes to TLDs and their numbers were relatively constant. It was assumed that TLDs were two to four letters in length and that two-letter domains were, with a few exceptions, country code TLDs. The country code list could be pulled from the International Organization for Standardization (ISO) list of codes for countries and similar entities [see IS3166]. So the heuristic rules for validating a TLD worked relatively well and the application developer’s job was relatively easy, as the list of generic TLDs was reasonably constant and could be kept locally and tested. Developers could poll the Internet Assigned Numbers Authority (IANA) list and then update their local list at regular intervals. By 2003 the list of valid non country code included TLDs such as .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO, .INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA. A 2004 document titled “Application Techniques for Checking and Transformation of Names” suggests that “the better strategy has now become to make the ‘at least one period’ test, to verify LDH (letters, digits, hyphens) conformance (including verification that the apparent TLD name is not all-numeric), and then to use the DNS to determine domain name validity, rather than trying to maintain a local list of valid TLD names.”
With the release of potentially hundreds of new TLDs, my challenge to the industry is this: What is the most efficient way to communicate the changes and their timing to the application developers soon enough so that the first registrants of the new TLDs and their associated end-users have the same experience as they have now using a well established TLDs? More pointedly, what is the incentive for application developers to update systems and applications in a timely manner?
What we would hope is that developers do so for the benefit of the end-user, but frankly, experience has shown that the big application developers refuse to be at the mercy of registries’ timetables. Do you recall how long it took for Microsoft to update their browsers to be IDN aware?
It seems to me there should be a coordinating body that communicates not only the information about upcoming changes to the IANA table, but does so in a timely manner, giving major developers enough lead time—and perhaps the incentive—to update their applications. ICANN seems to be the best option as the coordinating body to do so, as it would be the first to know the list of approved names. I don’t know if the Internet Engineering Task Force (IETF) has any suggested improvements in the process by which application developers can effectively and easily update their files (local or otherwise) of new, valid TLDs. If they do, greater awareness and education of the new procedure would certainly be welcome.
Lessening the burden on developers by providing timely information, adequate lead-time, incentives and/or effective and updated procedures serves all of us. For the DNS industry, such facilitation would minimize user confusion and dissatisfaction and would bring to fruition the promise of new TLDs—expanded choice and innovation.
I am interested to see what work or procedures ICANN or other groups such as IETF have done in this regard and if those efforts are coordinated.
Sponsored byRadix
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.
Alexa
I raised this issue ages ago ...
There’s multiple layers to the problem and it’s not one that will go away overnight - and there are also some very strong arguments about why it shouldn’t.
Getting large software vendors to recognise certain domain extensions is one thing, but I honestly don’t think that either ICANN or the IETF is really the correct place to get the message out to developers, who are the people writing the code to validate web forms etc.,
For new domains being a sub domain or a new domain in a new TLD, it is wise to wait for a few months before starting to use the domain for emailing.
Due to domain tasting and other malware practices that registries/registrars are not handling satisfactorily, a brand new domain will likely be seen as suspicious to email receivers.
As for code to validate an email address, this is not trivial and a regex is usually insufficient.
A complete library can be found from: http://www.addedbytes.com/blog/email-address-validation-v2/
Franck
http://www.avonsys.com/deliverability
ICANN has this validation toolkit for C#, Java, Perl, and Python apps, but I’ve no idea if it’s been maintained over the last few years:
http://www.icann.org/en/announcements/announcement-2-22mar07.htm
Last time I checked (admittedly a couple years ago) there were many scripting sites still providing code samples with out-of-date regular expressions for validating email addresses. These snippets wind up being used in lots of different places. It seems to me that a bit of grass-roots outreach is required.
Indeed. I did a similar post two years ago, in which I suggested this should be part of the outreach program that ICANN should launch.
Two years have passed, but I am still not convinced that most programmers are aware of the impact of the new gTLD program on their work. What I hear is that the new gTLD operators should handle this themselves. However, there is quite a difference in scale with the new gTLD program vs earlier new gTLDs, which were introduced one at the time. With possibly 500 new TLDs introduced over a few months, it could be a a major failure of the gTLD program if these new TLDs are not handled proprerly by software.
Patrick I suspect a lot of prospective registry operators haven't really considered the impact of several hundred extensions being added over a short period of time. A lot of procedures and processes that are currently in place are not going to scale sanely unless there is a significant change in how things are done Michele
Alexa,
You and others raise a very good point. What guarantee do we have that e-mail addresses and websites on new gTLDs will be allowed to operate without any interference? Unless we have a regulatory body in which to turn to and lodge a complaint, it’s possible that the users of new gTLDs will have an uphill battle on their hands. I can say this with almost 8 years of experience having operated in the .LA domain space.
For the past 8 years, I’ve experienced the obvious issue cited above, i.e. challenges getting my e-mails through to the recipients via my .LA e-mail accounts. Often times, the e-mails were routed to the spam folder. Other times, my e-mails didn’t even arrive and I was forced to use my ISP e-mail account. I’ve come to the realization that the ISPs such as AT&T;, Comcast, Verizon, etc. are essentially gatekeepers that have the power to accept, or deny, the delivery of one’s e-mail to one of their customers. In addition, company’s such as Yahoo, Google, and Microsft are gatekeepers as well. How will these companies respond to e-mail messages from new gTLDs? What recourse will the users of these new gTLDs have when they are prevented from sending their e-mails to recipients that happen to be a customer of one of the companies mentioned above? Should they be forced to deal with each company individually? Can you imagine the amount of time that would take?
Another issue I encountered recently was having one of my websites flagged as suspicious while checking the search results on a well known browser. I quickly contacted the appropriate entity and the issue was resolved in a couple of weeks. Fortunately, I became aware of this issue and was able to resolve it. But, what happens when users of new gTLDs are not made aware of this type of issue? What happens when their site is flagged as suspicious without their knowledge? Shouldn’t we hold the vendors accountable for mischaracterizing a website? Should our websites be treated as guilty until proven innocent? Aren’t these types of software vendors also becoming a gatekeeper?
If that wasn’t enough, I also experienced another issue related to the McAfee Security Scan Plus software on my computer. One evening, it performed a routine scan and notified me that my website was considered to be “dangerous”. Of course, I contacted the company and eventually spoke with one of the technical support staff. This person directed me to the following website - http://www.siteadvisor.com/sites/domain/writeComments?firstTry=1§ion=domainSuggestion. I typed in my url and received the following message, “McAfee TrustedSource web reputation analysis found potential security risks with this site. Use with extreme caution.” I find this hard to believe since I’m running a social networking site that I just created via Ning’s social networking platform. If you want to validate this claim, simply visit the SiteAdvisor.com website via the link above and type in “southland.la” and see the results for yourself. Here again, it seems that we have another type of gatekeeper, i.e. McAfee’s Security Scan Plus software. How will these software programs treat new gTLDs? Will the sites on new gTLDs be flagged as “dangerous”? How will the owners of new gTLDs be made aware of this situation, especially if they only have one particular software tool performing a scan on their computer? Chances are, they won’t. And, even if they are made aware through some type of miracle, are they going to get resolution easily when having to contact multiple vendors?
Ideally, I would like to have a regulatory body that I could turn to and lodge a complaint that, in turn, would be forwarded to a department within a company that handles such matters. It would also be nice to have this information made available to the public in order to mitigate this type of risk. Perhaps ICANN or the IETF would be the appropriate place to have such an entity. Perhaps it might be best to have the IETF in charge of this regulatory body in order to have a better segregation of duties.
Ray I assume you're kidding? If a company wants to block / not accept email from a particular domain or an entire namespace that is their choice. A "regulatory body" would not resolve anything. Regards Michele
yes, it is their prerogative, but it would help to have a one stop shop for complains and up to them to forward to the right registry/registrar and keep a tab on complains/resolution.
Franck Why would a registrar get involved in fielding "complaints"? If one of our clients wants to block a TLD that's their choice. Michele
One additional issue that I've encountered recently is having one of my .LA e-mail addresses being treated as invalid. For instance, when trying to create an account on Facebook some time ago, I tried to use one of my .LA e-mail addresses. Unfortunately, I received an error message indicating that my e-mail address was invalid. Even Facebook has joined the gatekeeper bandwagon with regards to e-mail addresses being used with certain TLDs. With regards to companies having the right to flag a website, or prevent an e-mail from being delivered to a recipient's inbox, due to a certain TLD being used, I'm fine with that position so long as the customer is involved in that decision. When sending e-mails via my .LA domains, my e-mail recipients were not involved in the decision making process to flag my e-mails as spam or prevent my e-mails from being delivered to their inbox. Their involvement was conveniently bypassed. I cannot tell you how many times my contacts complained about not receiving my e-mails only to discover that some were flagged as spam. Others simply didn't go through. So, while I agree that companies have such rights, I also believe that their customers have such rights too. Stepping back a bit, why would companies even consider making such decisions, especially without the consent of their customers? What if the United States Post Office, FedEx, or DHL decided to make such decisions because an envelope or package had a certain zip code? What if a telephone company decided to prevent certain phone calls from going through because they had a certain area code? We wouldn't accept this type of behavior from these companies. Therefore, why should we accept this type of behavior from companies that divert or block our e-mails, especially without the consent of their customers? What I'm advocating is a regulatory body that serves as a conduit for collecting, storing, and communicating these types of issues to companies that are causing these issues. This approach would be much easier for the public than having to reach out to each individual company. Since companies are also going to acquire their own gTLD, they too may encounter such issues and, in turn, would also benefit from having such an entity working on their behalf. We may discover that many companies are not intending to flag such websites, divert e-mails, or prevent such e-mails from going through, yet, because of the complexities involved in their efforts to fight spam, they are unknowingly harming others that have good intentions. Why not create an agency to assist such companies? Also, I'm not advocating that this agency serve as an enforcer. Instead, I'm recommending that the agency collect and distribute information collected from the public. Companies that refuse to remediate these types of issues will run the risk of losing business to their competitors that decide to resolve such issues. Let the public vote with their wallets!