Skip to main content
  • IETF 126 Highlights

    The IETF 126 meeting was held 18–24 July 2026 at the Hilton Vienna Park in Vienna, Austria, and online, hosted by Cisco. The week included the IETF Hackathon and Code Sprint, the New Participants' Program, five Birds-of-a-Feather (BoF) sessions, and more than 100 working group and research group sessions. The Applied Network Research Workshop also took place during the IETF 126 meeting week.

    1 Sep 2026
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026

Filter by topic and date

Filter by topic and date

New TLDs

3 Apr 2014

The previous blog post talked about the IANA discussions at the ICANN meeting. But of course that was not the only topic that we talked about.

The biggest project in the last couple of years at ICANN has been the introduction of new TLDs. Those are new finally coming online, and include both new ASCII-based names as well as many internationalized domain names. The latter are, of course, very important for the worldwide users of the Internet.

Having talked to some of the people about their experiences in bringing such new TLDs to use, we realised that there are some technical barriers in using them in some applications. And we wanted to highlight one of those barriers in this post, in the hope that additional implementors notice these issues and make sure that the new TLDs work in all current systems.

The barrier we want to highlight is that some applications expect only the set of TLDs that were in use before this recent expansion, and do not accept (or do not properly handle) the new TLDs in URIs, email addresses, and other places that domain names appear. This is a problem that touches different types of applications and web services.

For instance, many browsers employ mechanisms to recognize proper domain names, and use internal logic to recognize valid TLDs. The results of such recognition processes is used for things such as determining whether a string typed in the URL bar should be fed to the domain name system or to a search engine. In some cases, today’s browsers are unaware of the full set of possible TLDs, and may refuse to do a domain name query, instead assuming that the user entered a search.

Of course, the relevant developers have been notified of known issues, and fixes are on the way, but there may be issues that we have not run into yet. For further information, see also ICANN’s Universal Acceptance Project.

As time goes by, many more of these domains come online. Any discovered problems will be detected and corrected. But sooner the better. With this in mind, check your code today!


Share this page