But many other readers and astute observers of this space, domestic and international, would not confuse the public dead silence we are hearing from ICANN and its insider community or the euphoria of the long awaited application submissions we are seeing to mean that all is perfect. The multistakeholder model, ICANN's version of it, the New gTLD program, ICANN's approach on it, and The Single Root and its unique identifiers are all at graver risk than ever and must be saved before it is too late. Only then can we truly claim to be serving the "Global Public Interest" beyond mere words, slogans, and 11th hour band aid patches.

If you question my opinion on this gravity please take note of how Dr Larry Strickling, US Assistant Secretary of Commerce, concluded his letter to ICANN on Jan 3, 2012 stating:"How ICANN manages the new gTLD program will, for many, be a litmus test of the viability of this approach”.

It is understandable why those in the ICANN community who do see many of these grave risks to the multistakeholder model in plain sight chose to remain silent. Some do so in order not to cause any hiccups or possible derailment to the long overdue, but inequitable to emerging markets, New gTLD program that stands to benefit them, their businesses or their plans. Instead they chose to formulate their message to focus on only the opportunities the new gTLDs will bring, and rightly so, but with little or no attention to their local and global risks. After all, serving the Global Public Interest is not their mandate — it is however ICANN's mandate per the Affirmation of Commitments (AOC) agreement with the US Government, to which and to whom at the very least, it should be accountable.

The Global Picture

Internationalized Domain Name gTLDs, also known as IDN gTLDs, will usher the Global Multilingual Internet I have championed and advocated since the late 1990's, at many levels and roles, to serve "The Global Public Interest" that should empower local citizens.

Readers may be aware that I have also, inside and outside the ICANN fora, created great international awareness of the immense positive benefits of the coming Multilingual Internet that will be born thru IDN gTLDs and the new gTLD program. More acutely, I have not shied away from pointing out the grave risks, some of which remain unaddressed and unresolved. Also, the international relationships that I have created with global leaders in their sectors like Deloitte, VeriSign and others that primarily focus on the emerging markets and IDNs should carry some weight, credibility and validity to the voice of concern I raise, for those who care to listen.

But these accolades do not detract me from following my conscience and beliefs, as I have done over the years, to point out the grave risks I see in plain sight regardless of how unpopular this may make me at first glance with colleagues and fellow ICANN community members. Many are aware that I also have placed serving The Global Public Interest that I have always talked about above any possible personal or business interest. I hope that saying my peace may help save the Multistakeholder model, its principles and the single root of unique identifiers, the 10s, maybe 100s of millions of dollars that applicants are investing in applications, and ICANN from failure, and before it is too late.

The Imminent Grave Risks

Imminent grave risks are facing the Multistakeholder model, the single root, and ICANN itself, as well as serving "The Global Public Interest". In brief they are… Click here to continue reading the full Ankabooot editorial.

Written by Khaled Fattal, Group Chairman, The Multilingual Internet Group

"Russia, though cautious in their approach to IDNs in the new TLD program, trusts Sedari with one of their critical national assets — its capital city" said Sedari's CEO Dr Liz Williams. "This is the first of Sedari's city domain names to be signed and one of a number of Internationalised Domain Name applicants we are advising. FAITID is a great organization full of enthusiastic and experienced professionals who will offer Muscovites and others exciting opportunities for second-level names in Russia," Williams continues.

The .MOSCOW and .МОСКВА project is backed by Moscow's local government and won an impressive showing of support from over 17,000 Internet users in on-line and off-line polls.

"Implementation of any TLD is a complicated project with many issues to resolve" says Dmitry Burkov, FAITID Board Member, "That's why we've chosen Sedari as our strategic international partner for .MOSCOW and .МОСКВА. Sedari management has the experience and industry knowledge on ICANN that makes us confident the company is familiar with all the procedures of the corporation, in particular related to new TLDs. Together with Sedari we'll make the project for Moscow top-level domains successful giving Russian users more choice in the domain name space."

About FAITID

FAITID is the Foundation For Assistance For Internet Technologies And Infrastructure Development, a Moscow-based not-for-profit multistakeholder organization. Introduction of the domains for the Russian capital is the initial and key FAITID project. FAITID's structure involves all interested parties in the process of the TLDs implementation such as local government, the private sector, and Internet community representatives.

.CAT for Catalan language already exist;
.BZH will probably have the "Breton" language to help survive;
"Basque" is vulnerable but there is a .EUS initiative;
.CORSICA will certainly help the "Corsican" language to develop;
.BOURGOGNE will possibly help the Burgundian;
.CHAMPAGNE would definitely help the "Champenois" but note I am not sure it is the language it would help first ;-)

.CYM, .GAL and .SCOT also exist in other countries.

UNESCO Interactive Atlas – displaying world’s languages in danger

Written by Jean Guillon, Top-Level Domains specialist

Sophia Bekele – Executive Director, DotConnectAfrica

Q. What is the tussle over the .Africa domain all about?

A. The controversy emerged from a plan by the Africa Union Commission to make the .africa, .afrique and .afriqia, all similar name strings unavailable by including it in the list of reserved names, so as to frustrate the hopes of genuine applicants like DCA. The AU had asked ICANN to reserve the names. Such a proposal is a disingenuous attempt to afford special legislative protection to the AU to own these strings through a method of bypassing the formal application process of the ICANN new generic top level domains (gTLDs).

Q. You have openly criticised the AU leadership on this matter. What is it that you want done?

A. Giving the AU an upper hand in managing the domain raises conflict of interest issues as some players in this process are planning to pre-qualify organisations that will apply for .africa while they themselves have vested interests in the .africa TLD, because they floated separate .africa proposals of their own, and have also openly identified with some prospective applicants.

If the AU insists on controlling, owning and leading the process by using its political influence to gain official control of this new gTLD, then the AU should be treated as any other prospective applicant that also needs to abide by the ICANN Applicants Guidebook and should not be given preferential treatment to the detriment of other applicants.

Q. What was DCA's opposition to the "reserved names" issue that was proposed by the African Round-table, at the Public Forum in Dakar?

A. DCA remains opposed to the AU request to reserve the names which will enable it to separately negotiate the delegation of these name strings under a separate process outside the aegis of the ICANN new gTLD program. This defeats the objective of the ICANN new gTLD process and eliminates competition even before the application has been submitted to ICANN. In the interim, all interested observers are now waiting for ICANN to provide a ruling on whether .africa and related name strings should be reserved or not. This will be a big decision and will shape the direction the new gTLD programme will take regarding .africa.

Q. What were the resolutions from latest ICANN meeting in Dakar last month on new TLDs and how are they likely to shape the adoption of the new regime?

A. The new gTLD programme was approved in the Singapore meeting earlier so there are no major resolutions that will hinder the momentum of the process. But there are some resolutions with big implications for Africa in particular such as the resolution to adopt the Joint Applicant Support Working Group (JAS WG) report on how ICANN can assist applicants from the developing countries increase their participation in the new gTLD. This could see more new gTLD initiatives emerging from Africa in this round.

The other issue was the passing of the $900,000 budget for ICANN's communication plan and the resolution by the board on ethics and conflicts of interest which will give a statement on how ICANN directors with interest in particular new gTLD initiatives can be restricted from participation in the deliberations and decision making on the new gTLDs program.

"We want to achieve a Gold Standard in terms of conflicts and ethics practices." —Steve Crocker, Chair of the ICANN Board

Q. What remains to be done now before applications in January 2012 to ICANN?

A. There are so many internal procedures involved including negotiating and signing a few contracts, partnership agreements, organising documentation and so forth. However, until the application window opens in early January in 2012, we shall continue our campaign, and even during the application period, so as to continue to raise awareness and win the required support for the .africa gTLD.

"Given the global presence of Afilias, Internationalized Domain Names — informally known as IDNs — have always been of great interest to us. We were the first company to launch IDN email, and believe that having IDN equivalents of .INFO for the world's most populated country, in its primary languages, will be a major benefit to all Internet users in China," said Ram Mohan, Executive Vice President and CTO, Afilias.

Roland LaPlante, Afilias Senior Vice President and CMO, said, "ICANN will only accept applications for new gTLDs between January 12, 2012, and April 12, 2012. Since it will likely be several years before anyone can again apply for an IDN version of a gTLD, we're pleased to lead the way for IDN use and adoption."

Afilias will support the new Chinese versions of .INFO with the same technology that will support many other new TLD applications: a state-of-the-art EPP registry, a globally diverse and redundant Anycast DNS network, 24x7 call-center and technical support, and links to the global distribution channel. In addition, Afilias provides other premium solutions to augment its registry offerings, including technology to enable mobile phone compatibility for websites and a unique IDN-capable email solution.

All Afilias services are DNSSEC and IPv6 ready, and reflect more than 10 years of experience in supporting gTLDs operating under ICANN contracts.

If you've ever looked up information about a domain name you've used a Whois service. It's the public information system about contact information for a domain name or IP addresses, though in this article, we will just talk about domain name Whois.

In some generic and sponsored Top Level Domains (gTLDs), Whois is run authoritatively by the gTLD. In older gTLDs such as .com and .net, the authoritative Whois service is run by the registrar responsible for the domain name. While some TLD operators run their own infrastructure, when a TLD operator uses a back-end service provider, that provider also provides the TLD Whois service. This public information system is of interest to law enforcement agencies and bodies, attorneys and courts, those studying the commerce of domain names, and those trying to address technical administration issues. It is typically operated as an open system that anyone can query. However, that very well could change over time and in certain circumstances, as I explain later in this article.

How you access Whois

Most people query Whois information through a web-based query page, usually through a registrar's Whois website, as well as those of gTLDs. The information returned is typically only relevant to the registrar's offered gTLDs, but there are also more generic Whois query tools. (Whois also has a machine level interface offered for querying on Port 43, which is what those nice web-based Whois query pages are actually talking to behind the scenes.)

What does Whois provide?

The content returned in different registry and registrar implementations of Whois can vary in how the output is displayed, but they are all more or less providing the same area of information. Whois services return contact information by area of responsibility for the domain: technical, administrative, billing or finance, along with the registrant of the domain, the registrar, and registration date. The contact information itself typically contains items such as name, address, email and phone numbers.

Would you like your Whois, thick or thin please?

Thick Whois: Gathered by the registrar during the registration process, this information is stored in the registry of the gTLD operator, which is responsible ensuring the data is valid. Most gTLDs conduct periodic Whois compliance audits rather than a complete real-time validation of submitted Whois data. Even if a gTLD offers thick Whois, registrars are required to maintain their own Whois service for their domain names. Since the registrar has the ability to update the related Whois information in the actual registry in near real-time, it is expected that the registrar maintain synchronized Whois data output between what their Whois service offers and what the gTLD Whois service offers.

Thin Whois: This really only applies to .com, .net and certain ccTLDs where the gTLD's Whois offers much less information about the domain. Its primary value is to point to the registrar's Whois service, where one should expect to find the detail Whois we see in a thick Whois. In this model, the registrar's Whois service is authoritative and must remain in compliance with ICANN's Whois data output requirements.

Why is this model not as desirable? It comes down to compliance monitoring. It's easier to hold a number of gTLD's accountable for Whois compliance under the thick model than to run periodic audits on many registrars for the many gTLDs they may service.

Privacy

Local privacy laws and practices in a global operating environment remain a challenge. Requiring full public Whois output can violate privacy rights of the region/jurisdiction where a registrant operates.

ICANN allows for exceptions to their requirements for thick Whois contact data where local laws contravene those requirements. This means that, theoretically, a gTLD might have to treat the Whois output of a registrant differently based on their residence or in relationship to the corporate home or operating region of the gTLD itself. It's clear there will be some variation in the way gTLDs approach Whois output as a result of these issues.

Whois proxy services have been offered by registrars for some time now. These are services that provide indirect contact information for those Whois contact areas previously mentioned. For example, instead of putting the real registrant's email address, the email address in the Whois output simply may be a forwarded email address. It still allows you to reach the registrant, but likely it's first filtered by the registrar to see if it's a valid request related to the domain. This product was born out of domain commerce parties mining Whois output for email contacts and incorporating those emails in various email marketing campaigns — some for legitimate products and some not.

Operating a robust Whois service in the new gTLD environment

Operating a solid thick Whois has a number of upcoming challenges. Whois is frequently a target of companies looking to mine the data. This is done by first downloading daily zone files for a given gTLD, which is free to the requestor and an ICANN required provision by gTLDs. These companies then use automated tools to systematically query the list of active domains and collect contact information for commercial purposes. Unfortunately, Whois queries can be quite small in comparison to the large amount of output the reply generates. This means someone mining Whois can readily apply load on the gTLD Whois servers. In short, an unprotected Whois server is easily knocked over with excessive load.

A good back-end registry service provider will have a plan to address this. Most apply a combination of Anycast network based Whois services with significant infrastructure capability and, mostly important, a source-based rate-limiting system to control how quickly a data miner can submit automated queries. Ask your back-end registry service provider what they can do for you and make sure those capabilities are reflected in your Abuse and Access policies in your Whois Service.

A Future for Whois

The changing environment of our Internet is bringing great new opportunities but also new challenges for Whois. For example, one problem is that new Internationalized Domain Name (IDN) TLD registries can't offer contact information in the native characters those IDN registries support in their domains. Another problem is that traditional source based rate-limiting, currently effective against data-miners, is not effective in the burgeoning new IPv6 number space.

Whois capabilities being considered are tiered permissioned access to Whois services with related variable output to reflect the different needs of Whois consumers and localized privacy issues. Both consumers and providers alike have expressed an interest in an industry-wide, standardized Whois output structure for some time.

Work is underway in several areas to address a number of these shortcomings in Whois optional functionality. Some recent examples of these efforts include ICANN's Internationalized Registration Data Working Group (IRD-WG), various ICANN project groups working on specific IDN TLD implementation script issues, the WHOIS-based Extensible Internet Registration Data Service (WEIRDS) discussion list in the Internet Engineering Task Force (IETF), and ICANN's Whois Survey Working Group (concerned with Whois functional requirements).

The most important message a potential gTLD applicant can take away on Whois is this: Expect that the once "simple" service will become a much more complicated. Anticipated new functionality in Whois and integration of that functionality into your related Abuse and Access policies should be addressed by the back-end service provider you are considering.

Written by Michael Young, Chief Technology Officer at Architelos

The forum will spotlight how, after decades of exponential growth, the Internet infrastructure needs to be strengthened and fortified to support the needs of the next billion users. It will also look forward to the increasing complexity and internationalization of Internet-enabled technologies, and the evolutionary changes that must take place to meet those challenges.

"In the years ahead, we believe the world will welcome a billion new Internet users, and witness the development of businesses and services that have yet to be imagined," said Jim Bidzos, Verisign's executive chairman, president and chief executive officer. "That is why it is imperative to bring industry and technical leaders together to think through and plan for the challenges ahead. Verisign is proud to host such an impressive group."

Chris Anderson, editor-in-chief of Wired Magazine and author of "The Long Tail," will keynote the event, which will feature technology leaders from the academic, business and policy communities.

The event will also feature the winners of the four $75,000 infrastructure grants that Verisign awarded as part of its 25 Years of .Com commemorations in 2010.

The grant winners who will present their findings are:

• Professor Shlomi Dolev, Ben Gurion University, Negev, Israel (Techniques for Achieving Positive Anonymity)
• Anil Madhavapeddy, Cambridge University, United Kingdom (Constructing a "Functional" Name System)
• Professor Philip Brighten Godfrey, University of Illinois at Urbana-Champaign (Lifesaver: Enabling Responsive Web Applications)
• Professor Z. Morley Mao, University of Michigan (Enhancing Mobile Internet Infrastructure for Improved Performance and Security)

The infrastructure grant program, launched during the 25 Years of .Com commemoration, represents a continuation and expansion of Verisign's commitment to sponsoring research that supports the Internet's healthy growth and development. Through Verisign Labs, Verisign has sponsored numerous university research programs this year, in addition to the infrastructure grants.

As the steward of critical components of the Internet's global infrastructure — including the .com and .net top-level domains, and two of the Internet's 13 authoritative root zone servers — Verisign plays a leading role, in partnership with other organizations, in ensuring the security and stability of the Internet. The research being highlighted at the "Building a Better Internet" symposium exemplifies the creative thinking that should help the industry to stay ahead of mounting demands and new threats, and enable users to enjoy the full benefits of the connected digital world.

According to Bob's opening comments, the possible salvation to our economic confusion and meltdown is to simply kill ICANN's gTLD program. He says: "Unfortunately, a major, ill-conceived program is about to seriously disrupt businesses and threaten consumers, causing significant and completely avoidable harm to the fragile U.S economy." There's no need to expand on this rhetoric. Let's focus on his other issues that need a granular analysis.

The American Bankers Association has declared its intention to apply for .bank as a gTLD brand for exclusive use for all banks worldwide. A good move, to which Bob acknowledges that citi.bank will not be available to any outside party or spammers. He insists that spammers will attempt to get citi.sanfrancisco, and he is correct. What would it accomplish? "Citisanfransisco.com" is already available for a few dollars as a dotcom. There are already thousands of other citi-based names all over the world, like citi-plaza, citi-college, citi-hotel, citi-center, citi-cats, citi-taxi, citi-this, and citi-that.

Bob has slipped on his advanced corporate nomenclature skills to discuss the minutia of the topic here; the fact that the name 'citi' in isolation has no unique value. It's a descriptive word, commonly available and despite its corruption of the word 'city' by replacing "y" into "i", it still retains the same sound and connotation of the dictionary word 'city'. The word 'citi' is in the public domain. Now one of Bob's member has the trademark on this highly diluted word 'citi' in financial services. The gTLD platform in no way increases or decreases the risk of further dilution or exploitation of the word 'citi' than it already exists.

Citibank was once the best name of the banking industry, but in the name of so called 'one word master branding scheme' the other half of the word has been chopped leaving this word like a lost citi on its own. Now imagine if Bill Gates was suggested to drop 'soft' from Microsoft. Should they be allowed to scream at the cyber-squatting ghosts whenever 'Micro' is used with any other word?

Such name issues are not cyber squatting, they are the liberalized use of a dictionary word. The big fear of advertising associations worldwide is hidden in the fact that most of their client's brand names cannot be stretched on the gTLDs global canvas. The biggest pain comes from the realization that for decades, the trade covered up the shortcomings of their name identities through the excessive overuse of logos and transient slogans. Bold statements demand bold proof. Just open few major trade directories and the dilution factor is right there.

The fuzziness of hundreds of billions that are wasted in life support services for weak and dying names cannot be explained by ad agencies or trademark services; they are the direct beneficiaries in this thick fog.

Here are some facts. A Five Star Standard of Name costs far less in maintenance costs, but diluted names cost ten times more in resources and takes ten times more in time and effort to gain a distinct position if any in the market place. Why are 90% of business names worldwide in this quandary?

Why are all the branding associations so scared of this global platform? What is so disturbing about a shift towards name-identity-centricity as ultimate marketing models? Do the math.

Bob further adds, "Program will throw the domain-name universe into widespread confusion while generating untold costs to domestic and international businesses and harm to consumers."

The domain system will have to advance from its current 200 million domain names to support 2 billion domain names in the near future. This is the natural progression of an expanding e-commerce that knows no bounds; ICANN is introducing gTLD to accommodate this new landscape. Now is not the time to be fearful of this inevitable expansion. To design centric thinking, these advancements appear as noise because they can't hear the nomenclature symphonies.

Bob continues and argues, "Some have estimated that, for a typical company, the cost of acquiring a single top-level domain and managing it over the initial commitment of 10 years could easily exceed $2 million, including expenses for the application process, operations, disputes, legal services, trademark monitoring and protection."

The argument that gTLD is expensive is seriously flawed, especially coming from the same groups that are already joyriding on $400 billion in yearly expenditures. Major organizations all over the world spend millions of dollars a month just to keep their name identities visible. A gTLD is the most affordable compared to what's wasted routinely in off target ad campaigns.

He insists "proliferation of top-level domains makes it easier for online felons to cloak themselves in the names of trusted brands."

Another phobia. Good corporations have good policies to administer their brands and protect their consumers. If a few banks are robbed a day, we mustn't closed down a ten thousand branches or park a tank in front of each entrance. There are millions of very cheap domain names available today where each may be easily construed as 'passing off' someone else's mega brand. Should we shut down the entire internet? Maybe we should stop selling domain names period. ICANN has also already addressed the ANA directly regarding this baseless argument. The real fear is not here, it's hidden in the half knowledge of the global business name identity problems.

There is no correlation between the inclusion of a customizable gTLD with the supposed increase in online scams and phishing. This is the same ridiculous line of thinking that would have been fearful of allowing credit card transactions from taking place online for fear of an increase in scamming and fraudulent activity. Every major online innovation accommodates these risks at various factors. Internet crime will always be a threat regardless of the environment while the stringent rules of gTLD application will preclude such petty thefts.

Here is where Bob overstretches his argument. "Harm to non-profit charities. Sadly, for each major natural disaster or security event that we have faced in the Internet age we have seen instances of online frauds. After Hurricane Katrina, it was reported by Charity Navigator that there were some 4,000 bogus websites for online donations. Following the 2005 Indonesian tsunami, fake charitable requests appeared online, for example a Portland, Oregon, man was arrested in January 2005 who falsely claimed to be an employee for the charitable organization Mercy Corps. In 2010, Forbes even reported on how to spot dubious online Haiti charity pleas."

Keeping the weather reports aside, there is no direct or indirect link to gTLD here. There is no need to drag here the daily fraudulent happenings from Main Street to Wall Street or political mismanagement from Big House to Whitehouse. Bob thinks that by killing this program in its infancy, there will bring an end to frauds, and create a climate of tranquility while bright rainbows will arch across the United States.

In fact, gTLD would actually work in favor of non-profit charities, under the right combination; a national or global charity organization could lock up a gTLD brand like dot.bank, and distribute its controlled sub-domain-name usage across the world's smallest communities, garnering presence and accessibility for fundraising, with 100% secure control of their dot.brand.

He raises his concerns, "The objections of governments, non-profits, and industry sectors most affected have not been adequately addressed. He further adds If ICANN's new program proceeds, the full damage to brand equity and trust in Internet transactions will be incalculable. As security vulnerabilities and phishing spread across hundreds of new top-level domains, consumer confidence in online financial transactions will greatly diminish."

The entire world of branding agencies and their association have taken up arms against it. But they have yet to articulate the opposition in granular details. The fact they must face is that the brand equity of any weak and diluted name will continuously erode on the ever-expanding cyber name platform that is inevitably going to take place.

What are the other key points that Bob should have discussed? Primarily, gTLD offers global exclusivity to a master root of domain name with unlimited usage and sub-domain-name expansion, it is the cheapest and fastest mechanism to reach hyper visibility on global scale, and if harnessed properly it will shake the branding tradition and create new global marketing rules and language. Furthermore, if we recognize current domain name system as the prime engine of e-commerce, then we must allow ICANN to take it to the next level with colorful multilingualization and open dynamics gTLD platforms.

What if the unique technology based game changers that pushed the traditional sectors over the cliffs like Skype to long-distance, Amazon to bookstores, Napster to music, Craigslist to classified ads should have never been allowed? Is gTLD that hidden game changer for global marketing and branding services?

If ICANN's mandate is to continuously develop advanced global cyber name management systems for one internet, one world consisting of 3 billion plus online users, then obviously the future of the global name management will fall towards domain name registries and on ICANN platforms. Along the lines of what Google created, replacing hundreds of old mass communication models and blending them into one simple global platform to connect buyers and sellers. The ICANN gTLD topic is getting hotter by the day and the time has come for the giants and midgets of the industry to have a head on debate on this. The great Lee Iacocca use to say, "Lead, follow or get out of the way."

Written by Naseem Javed, Corporate Image & Global Naming Expert

The 10/10 rule is discussed in Steven Johnson’s book “Where Good Ideas Come From.” The author presents various technological developments throughout history that fall under the 10/10 rule, such as color television, HD television, VCRs, and others.

There are many other examples of the 10/10 rule. On my last trip, I was flying on the Airbus-A380, the largest and most silent airline passenger plane that exists today. It took about a decade to develop. The main structural sections were from France, Germany, Spain and United Kingdom, causing some level delays since they had to be transported to one central location for assembly. Although the plane is in commercial service, it is yet to be seen if it takes another decade for the plane to become mainstream.

It is amazing to realize that it only took the same amount of time to build a stable version of the IDNA protocol as it took to build the A380 plane. Work towards the IDNA protocol began just over a decade ago and only recently has its second version been released. This second version will for example function for any future versions of Unicode, making it a much more stable protocol than previously. Meanwhile the protocol development we also saw the implementation and launch of the processes by which IDNs can be introduced at the top-level of domain names. The overall development of IDNs was a truly diverse, multi-national effort, with the precise number of participating countries difficult to assess. The biggest challenge now for IDNs is how to avoid waiting another decade for achieving widespread adoption by Internet users and application developers.

Many services or products have broken the 10/10 rule.  What they have in common is that they are considered innovative. One example is YouTube. It took YouTube only 2 years to become one of the top ten visited sites in the world and the most visited video site ever. Today, Youtube powers more than 3 billion videos views a day. YouTube’s disruptive innovation was to take advantage of the Internet and thereby its ability to create a different way to access and consume videos, and that in an era of early Internet consumers.

Another example is Facebook’s strategy to become the social networking leader by leveraging the trusted and verified .EDU top-level domain. Facebook facilitated membership through the restricted .EDU extension to create an exclusive membership club of verified students. Facebook soon became the largest social network in the world by surpassing Myspace, the previous market leader. Just like Youtube, the adoption rate for Facebook was less than a decade. Facebook was another innovative service.

So what can we do to take IDNs to mass-market? Granted, IDNs have been available at the second level of domain names for about a decade, with some of the early implementations starting in 2000. While most of the very early implementations have been used primarily for testing purposes, the standard second-level implementation was quickly adopted by for example European based TLD registries, but the most significant milestone was achieved in 2010 with the launch of ICANN’s IDN ccTLD Fast Track Program. Under the new program, the entire domain name could be expressed in Chinese, Indian, Russian, and other languages. While the technology is essentially the same, IDNs expressed in languages not using the Latin alphabet is a bigger differentiator than “simply” adding IDNs at the second level under existing TLDs based on the basic Latin script [e.g. blåbær.tld]. The opportunities and implications for regions that do not use the Latin alphabet as their primary language script will be game-changing.

As experience shows, in order to break the 10/10 rule, we need innovative services complementing a product in order for it to reach mass market in less than the typical decade. The question remains: Are IDNs innovative enough on their own or do they require complementors to push the adoption cycle in to the mainstream? I believe the answer is two-fold, although related. We need add-on innovative services making IDNs useful, and that we need to create incentives for the market to pick them up.

Creating effective incentives that serve the Internet’s public interest and opening up IDNs for innovative ideas can be done in several different ways.

One way is by widespread usage by key players that drive the industry. If we give existing TLD registries easy access to internationalized versions of their TLDs, then the deployment of these Internationalized TLDs could reach big markets quickly. This will not only speed up mainstream adoption, but it will also make IDNs more compatible by pushing more application developers to support IDNs, which in turn creates a better user experience and usability.

Some of the existing TLD registries have announced they will apply for and launch internationalized versions of their TLDs. However, not all will since the incentive may not be desirable enough given the high costs involved and the first-mover risk of being an early innovator in an immature market. Recall that use of IDNs is largely up to application developers, and for example email is only in its very early stages of roll-out. Offering customers a domain product that cannot be used broadly or generally in applications can be a challenge.

I previously proposed that bundling prices be introduced for gTLD applications containing internationalized versions of the applied for TLD string. There has been some concerns expressed associated with this type of lowering the barrier for companies. Most concerns express that this would create additional competitive advantages for already prominent industry players. However, in order to get new products into an existing market it is often common practice to offer lower prices initially. You could argue that while the Fast Track Process for IDN ccTLDs was cost-neutral, it was effective since it helped introduce new products at a low price, and that for internationalized versions of already existing TLDs (ccTLDs in this case). There is no reason why the internationalized gTLDs could not be introduced in similar fashion and thereby be able to compete with IDN ccTLDs.

Since there is limited competition and innovations in the IDN space, it would be beneficial to allow all Internationalized TLD applicants to be incentivized by lower prices if their strategy is aligned with that offering to Internet users. By allowing this, app and software developers will be quicker to embrace IDNs and will help improve IDN usability on a global scale. That kind of development will be positive for all Internet users and players involved. It will help lower the prices and barrier of entry for other companies or organizations interested in competing in the space and provide new IDN solutions to Internet users. In addition, it would create a safer introduction, by bundling and connecting the various internationalized TLD contracts with ICANN.

More benefits to Internet users would materialize in the IDN space as new innovative products and services are incorporated by industry players and entrepreneurial technology companies. For example, Internet usage in Asia, despite having gone through a 700% increase in the last decade, is still only at a penetration of about 10% of the general population, which means there is huge growth potential in this region. But is the growth opportunity enough to convince an applicant to go for the Internationalized (or localized rather) version of a TLD?

Interestingly, Asia is also one region where the high costs create an unnecessary barrier to IDN innovators. Considering that internationalized TLDs comes with high development and infrastructure costs, extensive first-mover marketing campaigns and a high probability of ongoing changes, bundled with the ICANN fee of 185.000US$ the financial risks are still too high. First movers have a high risk of failing under these circumstances since the market is in early adopter mode and not a mature and profitable market with users paying high or equitable fee’s to existing and more established domain name products. Multiple applicants have told me they would include internationalized version of TLDs they are intending to apply for, if the price was lower. Many are awaiting the specifics of the ICANN program for allowing lower application prices for certain applicants. 

As a result, and unfortunately, there have not been many public announcements about intentions of TLD applicants to launch IDNs. Most announcements have been made by major players, such as Verisign, to apply for their IDN equivalent in .COM. If ICANN’s goal with the new TLD program is to increase competition, consumer choice and innovation, more has to be done to incentivize the launch of IDNs to serve under-represented communities.

That brings me to an interesting subject on the topic of innovation and where the IDN innovation will come from. Are we still waiting for technology to catch up, or is it already here and we need to catch up with it? I recently asked a group from DIT, CDAC, NIXI, and Afilias India, in India, and another group, comprised primarily by Western-participants in the IDN session at the Dot-Nxt Conference on new TLDs in San Francisco. The findings were exceptional:

India: 50% feels like they wait for technology // 50 % feel like they have to catch up with technology.

Dot-Nxt: 10% feels like they wait for technology // 90 % feel like they have to catch up with technology.

The differences in the findings are interesting. Especially considering that the individuals asked are all from the same industry and involved in the same technology.

In less than 24 hours after the question was asked, one of the leaders of the team in India brought a timeline for new products focused on the usability of IDNs, nailing the 10/2. They also demonstrated newly developed tools helping users managing IDNs. These tools were exceptionally outstanding and could be very useful in regions outside India.

This exemplifies that we are witnessing a region where the people are ready for the next step in Internet development, and I believe this is where the expansion, and change of the namespace, will come from. Considering that the Internet has provided many benefits for us over the last decade, we have a responsibility to continue allow and encourage the ongoing development in an open and transparent manner. We simply need to make sure that next step of Internet evolution is available and more easily accessible by every Internet user.

I hope this post will help initiate the discussion on the topics related to innovations, prices, and other ways of making the internationalized TLD introduction and competition fair, and making the access equal. I also hope it will give a market perspective for those involved in the ICANN program focused on application fee reduction for certain applicants.

Written by Tina Dam, Co-Founder MYTLD

The revisions to RFC 5335 and 5336 currently nearing completion in the IETF's EAI working group remove most of the complexity from the existing design, and simply define a new international mail stream with UTF-8 text in mail headers, and UTF-8 addresses in the SMTP session. (MIME and the 8BITMIME ESMTP option already handle UTF-8 message bodies.) A mail server announces that it can handle internationalized mail by announcing an ESMTP option, which currently has the ugly placeholder name UTF8SMTPbis, but will presumably be changed to something snappier by the time the revised RFC is issued. I'll call it EAI here.

A mail client, if it sees that a server announces EAI capability, can put the EAI flag on the MAIL FROM command in the SMTP session, to tell the server that this message is an internationalized one, and then sends the message. Any mail server that supports EAI also supports 8BITMIME, so the message can contain any UTF-8 text without special coding. The RFC also defines EAI options for the SMTP commands EXPN and VRFY, which accept and return e-mail addresses, and some new extended return codes for status messages. If a client doesn't use the EAI option, it sends legacy 2821/2822 mail, same as always. The option is set or not for each message, so each message moving through the mail system is an EAI message or a legacy message.

The RFC for internationalized mail bodies allows UTF-8 nearly anywhere that ASCII can occur, other than in a few places intended to be parsed by computers, such as Message IDs and time zones in date stamps. It defines a new MIME body type, message/global, for attached or included internationalized mail messages. And that's about it. All of the down-conversion stuff to turn EAI messages into RFC 2821/2822 compatible mail is gone.

As the diagram above illustrates, this defines a new EAI (or whatever we call it) mail stream that is parallel to the existing legacy SMTP stream. If a message has UTF-8 headers, or a UTF-8 envelope address, it has to go in the EAI stream. If it doesn't it can go in either the legacy stream or the EAI stream.

The solid diagonal arrow shows that a legacy message can always move into the EAI stream, since the spec for the latter is a superset of the spec for the former. The dotted arrow shows that an EAI message can sometimes go into the legacy stream, if an MTA looks through the message and notices that it has an all ASCII body and an all ASCII envelope, something I've nicknamed Deep Message Inspection. (It's not required to do this, just allowed.)

If a client wants to send an EAI message to a server that doesn't handle EAI, too bad, there's no standardized way to downgrade.

This doesn't mean that mail systems are forbidden to downgrade messages, just that the IETF isn't trying to define a standard way to do so. It's easy to imagine useful special cases. For example, if an MSA (the program that accepts mail from user mail programs) is configured with backup legacy addresses for its EAI users, and it noticed EAI mail from one of its users to a legacy address, it could rewrite the message's headers to replace the user's EAI address with her legacy address and MIME encode the UTF-8 header text, turning the message headers into ASCII, and send it along as a legacy message. That sort of thing may turn out to be fairly popular, but at this point, it's not well enough understood to standardize.

There are mail communities where all the users read and write languages written in non-ASCII scripts, so it may turn out that everyone's mail supports EAI, and legacy compatibility doesn't matter. Or they may treat legacy mail as a special case, perhaps by using a different user mail program.

The EAI work has defined the core of a fully internationalized mail system, allowing users to send mail using their preferred language, encoded as UTF-8, in essentially all parts of e-mail messages. The EAI spec is conceptually straightforward, and the changes required for adequate if not superb support in MTAs are fairly simple. (Deep Message Inspection is harder, but it's optional.) The details of migrating from legacy mail to EAI mail are a work in progress, as are the details of how EAI users will send mail to legacy mail users, but the imminent completion of the EAI work is a big forward step for mail in all the world's languages.

Written by John Levine, Author, Consultant & Speaker

All of the extensions described up to this point have been backward compatible with the existing mail delivery infrastructure. MIME encodes all of the extended characters and files as ASCII text, so although you need a MIME-aware mail program on your PC (or web mail or whatever), the mail systems through which the mail passes don't have to know anything about MIME. Similarly, non-ASCII IDNA domains are encoded as funny looking ASCII A-labels starting with xn-- so, again, although applications have to know how to turn UTF-8 into A-labels, the underlying DNS software just sees the ASCII.

Although SMTP changes very slowly, it does have a process to add new optional features, with a way for clients and servers to tell each other which options they support and are using. In 1993, a new feature called 8BITMIME added a simple but surprisingly useful option to send mail with 8-bit characters. It didn't change any of the other rules, but it did have the effect of allowing any character set that uses the ASCII codes for carriage return, line feed, and period, (as do nearly all but EBCDIC), in mail message bodies. On computers using eight-bit bytes internally (all of them, these days) the code to support 8BITMIME is simple enough that all popular mail systems support it. So if we want to send eight-bit character code in messages, SMTP can handle it.

The main remaining bit of international e-mail that SMTP can't yet handle is the actual e-mail addresses, both the ones in the message headers such as To: and From: and the ones in the SMTP session. If a mail system is going to be fully international, it also needs to allow non-ASCII text in prompts, error messages, and anywhere else that strings are passed around for presentation to users. This turns out to affect pretty much every piece of software in the e-mail ecosystem, the MUAs (user programs), submission agents that inject mail from user programs, MTAs that move mail from one site to another, and POP and IMAP servers that let MUAs pick up incoming mail. The changes to POP and IMAP and user programs to be language independent are relatively straightforward so I'm going to concentrate on the tricky parts: the format of mail messages, and the SMTP delivery process.

For quite a while people attempted to invent ways to do non-ASCII addresses that were more or less backward compatible with legacy mail. Early work started in China and Japan, where ASCII-only mail was and is particularly unsatisfactory, and initially used simple approaches like allowing various eight-bit extended character sets in mail headers and addresses. Those character sets, such as ISO-2022-x, use sequences of control characters to switch among various "pages" of the character set, so that the meaning of any particular character depends on what shifts preceded it. These didn't work well for a variety of reasons: the shifts mean that a string's meaning depends on what shift state it's in, something that was often implicit or ambiguous, the same set of characters can be represented in many different ways by adding or deleting shifts, and the various experiments tended not to pay sufficient attention to what happened if mail was sent to a mail system that didn't have their extensions and didn't understand their extended character set.

UTF-8 doesn't have the shift problem, but it still uses characters outside the ASCII set that won't work with legacy mail systems. The next approach was to allow UTF-8 addresses, but encode them as ASCII. For domains, that's already done with A-labels and punycode; every non-ASCII domain has an ASCII version that starts with xn--. Unfortunately, that doesn't work with mailboxes (the part of the address before the @.) For one thing, any special characters one might use to mark encoded UTF-8 names have already been used somewhere to mean something else. Hyphens and plus signs are used to mark sub-addresses, exclamation points for uucp addresses, percent signs for source routing, slashes for X.400 compatible addresses, equal signs for VERP bounce addresses, and so on. Even if you could find a sequence of marker characters so arcane that nobody had ever used it, mailboxes are limited to 64 ASCII characters, and by the time you encoded UTF-8 as something along the lines of punycode, the length of the UTF-8 address would be limited to about 18 characters, which is rather short, particularly since people with non-ASCII addresses will want to use all of the same tricks that we ASCII users use with sub-addresses and other address extensions. So that doesn't work, either.

The most completely worked out experiment, documented in RFCs 5335 and 5336 added a new SMTP option called UTF8SMTP, in which email addresses can be almost arbitrary UTF-8, subject to the 64 byte limit on the mailbox, and the domain has to be one that can be turned into A-labels. Messages are sent using 8BITMIME, and UTF-8 can occur nearly anywhere in the message that ASCII can. Everyone with a UTF-8 address can also have an ASCII address, and one can address mail to both of them, with syntax like this:

To: <utf8mailbox@utf8domain <asciimailbox@asciidomain>>

When sending mail to a UTF8SMTP server, a client sends mail to the UTF-8 address, but provides the ASCII address as well. If the mail has to go to a server that does not handle UTF8SMTP, a complex set of downgrade rules turns any headers with UTF-8 into Downgraded-whatever: headers with MIME encoded versions of the UTF-8, replaces any UTF-8 addresses in the To: and From: lines with comments, and sends it along to the ASCII address.

While it was a magnificent piece of kludgery, after a while it became clear that this dual address system didn't work either. One reason was that it was very hard to keep the UTF-8 and ASCII addresses straight, so UTF-8 mail tended to leak into ordinary SMTP traffic, and downgraded mail into UTF-8 traffic. Furthermore, even though the dual addresses were intended as a temporary transition feature, on the Internet, no transition feature ever goes away, and Japanese and Chinese users quite reasonably did not want a system that would require that they have an ASCII address forever.

So the EAI working group threw away most of the kludges and is nearly done defining the permanent internationalized mail system for the Internet. In our next installment, we'll see how your future mail will work.

Written by John Levine, Author, Consultant & Speaker

But nearly every other written language requires characters outside the ASCII set. On the modern Internet, mail users live in every country in the world and write in a vast array of languages, and e-mail has been slowly evolving to handle everyone else's language. In today's note I'll describe the changes already made to Internet mail to handle other languages, and in the next message I'll describe the work in progress to handle the last missing parts.

MIME mail

In 1992, the first major extension to mail was MIME, Multipurpose Internet Mail Extensions. Whereas before, the body of a mail message had been an unstructured block of ASCII text, MIME provided a way to treat the mail body as a group of structured blocks of data, some of which might be text, and others of which might be pictures, documents, or any other sort of data that might be stored in a file. MIME provides standard ways to encode data that isn't seven-bit ASCII, so when you attach a picture or other file to a mail message, you're using MIME.

MIME also provides ways to include parameters on the MIME headers describing each block of data, such as the type of data (e.g., a JPEG image or a PDF document), and for text blocks, the character set in which it is encoded, like this:

Content-type: text/plain; charset=us-ascii

Content-type: text/plain; charset=UTF-8

The default character set remained ASCII (now known as US-ASCII, since it's a US standard), but you could use any of several others.

MIME also provides a way to specify character sets in many message headers such as the Subject: line. It supports the same character sets and encodings as text bodies. For example, this subject line is encoded in UTF-8 (see below), and has a character whose code is the bytes C2 B0 as hex numbers, which happens to be a raised small letter "o".

Subject: =?utf-8?Q?Your_reservation_N=C2=B0_F39-04XS?=

MIME encoding can be used in most mail headers, but it can't be used in e-mail addresses, which still have to be (mostly) ASCII.

Character sets, Unicode, and UTF-8

Since ASCII is a seven bit code, and most computers have eight bit memory, the obvious way to add more characters to ASCII was to extend it to eight bits, and assign non-English characters to positions 128 through 255. People did this with great enthusiasm, inventing large numbers of eight-bit extensions to ASCII. The ISO standardized over a dozen of them, known as ISO-8859-1 through ISO-8859-15, and there are many others defined by Microsoft, IBM, and others. Although eight bit extended ASCII codes have the virtue of being compact, it rapidly became painful to deal with them, both because of the profusion of incompatible codes, and because in many cases it wasn't clear which extended ASCII a file was using. And of course, no eight bit code was adequate for Chinese and other non-alphabetic languages.

Starting in the late 1980s, a project called Unicode attempted to create one giant character set including every character that anyone ever used. Somewhat surprisingly, the project gained broad industry support and has become a rousing success. The original plan was to use 16 bit characters, but as time went on and more languages and characters were added, the total number of characters is now over 100,000, so native Unicode is usually stored in 32 bit words. While few systems support all 100,000 characters, Unicode has the desirable property that either a system supports a character or it doesn't, and there's no ambiguity about codes that might represent different characters in different contexts.

Since computers still use 8 bit bytes, Ken Thompson of Bell Labs and Unix fame came up with a clever encoding known as UTF-8 that represents each Unicode characters as a sequence of 1 or more bytes. The first 128 Unicode characters are the 128 ASCII characters, and UTF-8 encodes those 128 characters as themselves, so any string of ASCII characters is also a string of UTF-8. At this point, there is little reason to use any extended ASCII character set but Unicode and UTF-8, other than for backwards compatibility with old software. Most non-ASCII MIME text in current e-mail uses UTF-8.

Internationlized Domain Names

For the same reasons that Internet users want to use non-ASCII characters in their mail, they also want to use the same non-ASCII characters in the domain names they use to name web servers, mail hosts, and everything else on the Internet. Although the domain name system (DNS) internally uses eight bit bytes and could in principle have just used UTF-8 names, there was and is a vast amount of DNS support software that only handles ASCII, and Unicode in some cases allows several different ways to write the same character (e.g., for an accented é, a plain e and a separate accent, or a combined accented letter), which would make DNS lookups, which only do exact matches, less reliable. The DNS community came up with a kludge, an encoding of much but not all of Unicode in ASCII known as punycode. If a name in the DNS is of the form xn--stuff, the stuff is punycode representing a UTF-8 string. Punycode has complex rules about what can be encoded, intended to pick unique representations for the characters that have several Unicode versions. The name starting with xn-- is known as an A-Label, the corresponding Unicode name is a U-label, and the whole system is known as IDNA, Internationalized Domain Names in Applications. IDNA is widely supported in web browsers which will turn Unicode names in their address bars into A-labels before looking them up and there are quite a lot of IDNA domain names in China, India, and Arabic speaking countries.

The part of an e-mail address after the @ is a domain name, so you can use A-labels there, too. But the part of the e-mail address before the @, the mailbox, is not a domain name, and for a variety of reasons not worth describing in detail, is not amenable to encoding as punycode or an A-label, although it's reasonable to assume that the mailbox is written in UTF-8. So to have proper internationalized mail, we need an extension to the mail system to handle UTF-8 in the mailbox part of the address, as well as in the other nooks and crannies that MIME doesn't handle.

In our next installment, we'll see how the IETF is planning to do just that.

Written by John Levine, Author, Consultant & Speaker

ICANN's present expenditure on its various programs is about $41 million per year and by way of management and support services it is about $17 million. The rationale followed by the ICANN community is that ICANN as a non-profit corporation should restrict its revenues to just about this much.

It is perhaps easy for the ICANN Board to adhere to this way of thinking, rather than argue for what is fair and what is required. The Board could instead point out to the Community that the end user does not exactly get his name for 16 cents plus a 20% trade mark up. The price that the end user pays per domain name, in real terms is at least about $10 for most Top Level Domain Names, up to $30 for some Top Level Domain Names and perhaps a hundred dollar or a thousand dollars for some new exotic Domain Name already announced or yet to be applied for. These are prices that a Registrant pays if the name that he or she wants is available on search and registered on availability. ICANN isn't saving any money for the end user by keeping its fee low at the level of 16 cents.

In the case of numbers, the price that the end-user pays is hidden. In many countries, static IP addresses are allotted to users with higher bandwidth plans. So the end user is not getting an IP address at $25 cents either.

If ICANN's negligible fee structure is not helping the end-user, who really gets the benefit? Perhaps ICANN fee is the least of the worries of Registries and Registrars, perhaps it might not matter to them much, yet this benefit goes to them, without any effort or even without any strong desire on their part.

I have nothing against the Business Community. My argument is simple. Their profits do not arise from ICANN fee being 16 cents. So I would argue for 50 cents, perhaps even a dollar per transaction and a corresponding increase in fixed fee from those Registries with which ICANN has a different arrangement. And a meaningful, rational fee for allocation of number resources though the RIR.

The Community would find it most benevolent for the good of Internet in general to make such a recommendation. The idea of enhanced revenues is to augment the size of the budget to break the barriers of constraints on the depth of the good work that ICANN has been doing. The cost of managing the Domain Name System with complete efforts is far beyond 16 cents.

1. ICANN's Security and Stability initiatives are impressive, but needs to be further broadened. It would require a significantly larger budgetary allocation to deploy DNSSEC in the DNS infrastructure of all the Registries, the registries that can afford and to the one's that can't, extend it to all the Registrars, large and small, to the ccTLD registries, many of which are managed with limited resources, whether or not they are inclined to be an integral part of ICANN, to Resellers, to big, small and tiny ISPs and their local cache servers. The end user would also require client level DNSSEC deployed in his or her local computer.

2. With a level of revenues that barely make the ends meet, ICANN has opted to recover all the accumulated cost of its new gTLD program, all the overheads of application programs and the estimated cost of the application evaluation process, all from the Applicant by fixing the Application fee at a $185,000 per application with the built in hazard of the name applied for eventually auctioned off to the highest bidder. The level of fees for a new gTLD application attracted several comments during the Public Forum at Singapore. The fee could be brought down if ICANN makes sufficient provisions in its budget for the evaluation and administrative process which can be argued as classifiable as overheads.

3. The Governmental Advisory Committee at the ICANN remains a committee of Governments that can afford to travel three times a year. For GAC to be inclusive, ICANN would require a program to provide participation support to those Governments to whom foreign travel is not a priority. GNSO would require a better travel budget to improve diversity of participation within. The Business users are funded by Business and it would require ample support to balance the business representation within the GNSO. AtLarge would require various forms of budgetary support to further ICANN's mission through the regional and local At Large Structures. The Policy Development Programs and Working Groups would be far more productive if there are budgetary provisions for face to face meetings.

4. CcTLDs need to be supported even better and all the programs that are extended to gTLDs could be extended to ccTLDs irrespective of the fact that they have opted not to be fully integrated into ICANN.

5. Five out of the six billion of the World's population would connect better to the Internet on Internationalized Domain Names (IDN's). The IDN community has passionately worked for it and has made it real. The commendable work that has already been done is just the beginning. What would be the next phase of IDN development in the policy and technology sphere? The work to be done is in the area of getting these five billion connect to the other billion that is on ascii and get all the six billion stay connected to one another. For ONE WORLD ONE INTERNET to be true, users have to find and access the Internet across IDN's, communicate across IDNs, knowledge has to flow across IDN's (and the multi-lingual web). This requires the next phase of IDN Policy Development and perhaps some research on such possibilities as Dual Stack Domain names to make IDNs identifiable by the rest of the world, a global, multi-lingual bibliography initiative and much more.

6. IPv6 transition requires plenty of funds to be promoted and supported effectively. The IPv4 address space is already depleted, but in most countries, it is only the Network Community that is aware of IPv6 and the importance of adopting the IPv6 protocol. Many Governments have still not started work on IPv6. IPv6 requires massive efforts and ICANN may consider a program designated as part of its core work to expedite IPv6 adoption.

ICANN's present budget is just about enough money to make speeches and make presentations and certainly no where in the realm of what it takes to do all that it needs to do. $17 million in Cash, another $17 million in Receivables together with $45 million in Investments is poverty for a Non Profit Corporation that has a mission a thousand times as large as that of a Google.

Internet would connect better if ICANN operates in abundance.

Written by Sivasubramanian M, CEO, Turiya and President, Internet Society India Chennai

To many nations and citizens around the world, especially the non-English speaking communities, this will be seen as a strategically alarming direction for the global Internet. U.S. laws remain set to govern the new gTLDs and the coming multilingual Internet in languages like Arabic, Chinese, Urdu, Cyrillic and many others which these new gTLDs will bring with them in Internationalized Domain Names (IDNs).

The clause on U.S. laws appears on page 27 of the last Guidebook under the heading "Legal Compliance". It remained unchanged, un-discussed, and un-addressed by ICANN since Guidebook version 5 (DAG 5) came out last year despite many official open letters and interventions to ICANN.

Under this rule any applicant or entity whether Chinese, Russian or Arab, and regardless of their nationality, will be screened against U.S. laws and its economic and trade sanction program administered by the U.S. Office of Foreign Assets Control (OFAC) of the U.S. Department of the Treasury. These U.S. Sanctions are imposed on certain countries, entities and individuals that appear on its OFAC's list of Specially Designated Nationals and Blocked Persons (the SDN List).

People, entities and countries the U.S. deems undesirable, or who don't meet U.S. foreign policy agenda can be listed. Applicants for any new gTLD in any language that are named on such list will be refused by ICANN per this "legal compliance" clause that invokes U.S laws.

It is worth noting that ICANN had initially stipulated in Version 4 of its Guidebook (DAG4) under the same legal compliance that "Terrorism checks" will be conducted on all applicants while it provided no definitions whatsoever. This was strongly objected for by Chairman Khaled Fattal to ICANN Executives and its board that subsequently led to the deletion of the "terrorism check" from Guidebook 4 by a board resolution. ICANN subsequently replaced "Terrorism Checks" with U.S. laws, OFAC and SDN in versions 5, 6 and now 7, its last.

To read the the full post, click here.

Written by Khaled Fattal, Group Chairman, The Multilingual Internet Group

It's a good read and it highlights some of the struggles that countries and registries face and taking IDNs mainstream. Though Russia has so far proven to be a major success story — with more than 800,000 IDN registrations so far (and counting) — most other IDNs are have a long ways to go yet. Arabic IDNs in particular face an uphill battle because web browsers offer poor (and inconsistent) support for them.

I noticed in the report that India's IDNs were not all properly displayed. So here's a screen shot from our IDN poster that illustrates the wealth of scripts used within India, as illustrated by the country's seven (yes, seven) approved IDNs:

As of today, 26 countries have received one or more IDNs; I've collected the full list here.

Written by John Yunker, Author and consultant