The EAI working group of the IETF has finished (part of) its work on the interationalization of e-mail addresses. This, together with Internationalized Domain Names (IDN) will make it possible to send e-mail messages to non-7 bit ASCII addresses e.g.  måtte@københavn.dk or 中国@中国.中国 .

There are 3 RFCs, covering changes to the SMTP protocol, e-mail message format and delivery Status Notifications.

http://www.rfc-editor.org/rfc/rfc5335.txt
http://www.rfc-editor.org/rfc/rfc5336.txt
http://www.rfc-editor.org/rfc/rfc5337.txt

They still have the “Experimental” status, meaning they are not yet a standard. How long this will take to see them in actual products is difficult to guess.  Software vendors tend to look at market demand before implementing new features . Hence, it is time to pressure your favourite e-mail client vendor. Tell them you need that. For Microsoft Outlook, you could try here. For Apple Mail, there. For Mozilla Thunderbird, still somewhere else.

The recent decision by ICANN to start a  new round of applications for new generic Top Level Domains is launching a round of questions on the IETF side about its consequences.

One possible issue may be with vanity gTLDs like apple, ebay etc. Some expect that every Fortune 1.000.000 company will apply for its own TLD.  My guess is rather the Fortune 1.000 for a start, but this does not change the nature of the issue, ie. those companies may want to use email addresses like user@tld.

The current standard is defined in RFC 2821 as such:

2.3.5 Domain

A domain (or domain name) consists of one or more dot-separated components.
[...]
The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an “FQDN”). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.

Hence, if either the mail client or the MTA expect to see a dot in the domain name and there is none, its behaviour may be unpredictable. The new gTLD context is addressed in the draft RFC2821bis, which states:

2.3.5. Domain Names

A domain name (or often just a “domain”) consists of one or more components, separated by dots if more than one appears.

Unfortunately, the current software implementations are based on the original RFC2821, not the revised draft, which is currently put on hold by the IESG.

There may be a lot of software out there that would treat user@tld as a local e-mail address (i.e. not a Fully Qualified Domain Name). It is not unusual to still find inside company data centers old internal SMTP gateways which have been quietly doing their job for a long time and were not updated for years.

Some pointed out on the IETF list and elsewhere that we have had for 10 years a ccTLD that accepts e-mail in the form of user@ai.  It is one thing that the behaviour of a small ccTLD apparently generated no complaints. It is another that a large number of companies may want to force the Internet to adapt to their advertsing strategy.  At this stage, we have no meaningful statistical evidence that the currently deployed software is able successfully deal with e-mail addresses that are directly under a TLD.  I am not aware of any study by ICANN’s SSAC on that matter.

In any case, when ICANN will go into an agreement with the registries operating the new gTLDs, it has to be very clear that compliance with existing technical standards is a must, and not respecting them would be a breach of contract.

It would be problematic for the end users/customers/consumers if companies started advertsing e-mail addresses like support@mycompany , if the delivery of the e-mail depends on the ability of some software to be non-standards compliant.

On a related note, my colleague Franck Martin pointed out to me last Friday that browsers usually append “.com” to any domain name they consider incomplete. Again, this is going to break a lot of software that have hard-coded lists of TLDs.  Similarly, there are also millions of web forms out there that check for malformed e-mail addresses based on the presence of a dot and/or hard-coded lists of TLDs.

There is currently a discussion going on between Milton Mueller and Patrik Fältström over the deployment of DNSSEC on the root servers. I think the discussion exemplifies the difficult relation between those who develop standards and those who use them.

On the one hand, Milton points out that the way the signing of the root zone will be done will have a great influence on the subjective trust people and nation states will have towards the system. On the other hand, Patrik states that “DNSSEC is just digital signatures on records in this database”. Both are right, of course, but they do not speak the same language. It is just like saying that a spam e-mail which is RFC (2)822 compliant is a legitimate one. From a technical point of view, it certainly is. From a social point of view, it is still an annoyance.

There is this often expressed feeling in the engineering community that technological choices are politically neutral by design. Nothing is further away from truth, as has been demonstrated by people like Lawrence Lessig. The development of standards is done exclusively by companies. Notice, for example, that those attending IETF meetings do it on company time and budget. The actual users are absent. The logic that says that IETF meetings are open to all is flawed by the fact that an average IETF meeting will cost you around $1500 to attend. Hence, there is an economic barrier to the participation of individuals. Additionally, the influence you might have on a process is proportional to the consideration you get from your peers. Newcomers need quite some time to get accepted by the community, especially if they are not engineers.
Companies are driven by the market. If there is no potential market, there is no need to develop a new standard. A good example of this is the fact that you cannot yet send an e-mail to, say, brønshøj@københavn.dk or addresses in native Cyrillic, Arabic or Asian scripts. Pretty soon, the right hand side will be dealt with, thanks to IDNs. But the use of non-ASCII character sets on the left hand side is still a not standardized. The EAI working group in the IETF has only been launched a few months ago. Why did it take so long ? I guess that the need for this has only appeared in recent years. As long as the Internet was mainly used by the American / Western European world, being restricted to 7 bit ASCII was not much of an annoyance, if at all. Now that the user base has enlarged to include countries that do not use the latin alphabet, it becomes a hot topic. However, it will take years before this can be implemented in the software we use every day. Notice, for example, that most operating systems today still require the user name to be in 7 bit ASCII.

Similar issues exist with RIRs, where again the actual IP address users are absent for the same set of reasons detailed above. However, which IPv6 prefix is going to be allocated by your ISP to your home network in a few years from now is an important one. Yet, those who are active in policy development at the RIR level are those very ISPs. The policy will be related to their commercial interest, which may – or may not – match the user’s interests.

End users are represented in ICANN. I am the first to admit that ALAC may be far from perfect, but it has the merit to exist and we can improve it. Isn’t time for a similar concept for the IETF, the RIRs and all those bodies that have a crucial effect on our user experience while using the Internet ? Being closer to user needs, without the filtering of the marketing department, may help prioritize the future developments.

Worth reading and studying: The Cooperative Domain Service (CoDoNS) by Venugopalan Ramasubramanian and Emin Gün Sirer, a paper by two scientists at Cornell on a distributed system to replace our good old DNS.

From the abstract: “This paper describes the design and implementation of the Cooperative Domain Name System (CoDoNS), a novel name service, which provides high lookup performance through pro-active caching, resilience to denial of service attacks through automatic load-balancing, and fast propagation of updates. CoDoNS derives its scalability, decentralization, self-organization, and failure resilience from peer-to-peer overlays, while it achieves high performance using the Beehive replication framework. Cryptographic delegation, instead of host-based physical delegation, limits potential malfeasance by namespace operators and creates a competitive market for namespace management. Backwards compatibility with existing protocols and wire formats enables CoDoNS to serve as a backup for legacy DNS, as well as a complete replacement. “  (bold added by yours truly).
More info, including a FAQ at http://www.cs.cornell.edu/people/egs/beehive/codons.php .

The IETF has written a letter to NTIA regarding the RFI for IANA services. The current contract with ICANN expires this month.

The IETF suggests “the DoC separate the technical parameter assignment function (as corrected above) from the other two functions since that is carried out for and at the direction of the IETF.” and transfer these under the IETF/ISOC umbrella. This obviously makes a lot of sense. Protocol numbering is not a hot political issue and is best kept outside the  political storms.

However, if the DoC answer is negative, the other approach would be to have an unilateral decision by the IETF/IAB to end its agreement with the IANA and set up a new numbering secretariat for its own purposes.

An interesting reading is the opinion of the US General Accounting Office: http://www.gao.gov/new.items/og00033r.pdf . This is already six years old, but still very meaningful.

Some excerpts:
“It is unclear whether the Department has the authority to transfer control of the authoritative root server to ICANN. [...] it is unclear if the Department has the requisite authority to effect such a transfer.”

“The delegation from an agency to a private party is sometimes referred to as the doctrine of subdelegation, with the original delegation between Congress and the agency. [...] Here, Congress has never delegated responsibility to manage the domain name system to any federal agency.”

The above sentences applied to the root zone file editing process. We should see if it also applies to the IANA functions. As we know, the DoC never took this into consideration and continued its process of contracting with ICANN and Verisign. But at least, they know their position and authority could be legally challenged.

The NTIA is requesting information from potential bidders to perform the IANA tasks. The IANA contract expires at the end of March 2006. The timeframe is only surprising in that this should have happened earlier.
The IANA function of ICANN is the part that has been the less crontroversal, with the notable exception of some key missing cctld reports. We should keep in mind that the IANA is responsible for a lot more than just country code allocation in the DNS. It manages the very critical IP address space. It is also in charge of keeping and allocating many other things from TCP and UDP port numbers to SNMP entreprise UIDs. As such, the IANA is the numbering secretariat of the IETF. In the end, it should return where it belongs, ie under the ISOC/IETF umbrella.

But the one main question of course is if the DoC is allowed to do what it does at all. Does the US government “own” the Internet ? Is there an undisputed proof of ownership ? An international treaty granting this right to the US government ?
If not, it is not in a position to launch such a process on a good it does not own.

Today, the Internet Engineering Task Force (IETF) and the Internet Society (ISOC) celebrate the 20th anniversary of the IETF, the world’s leading Internet standards development body.The first IETF meeting was held on the afternoon of January 16, 1986, in San Diego, California. As a community-driven activity the IETF went on to pioneer a unique, open process for standards development. Open to all, and based on principles such as “rough consensus and running code”, the IETF has enabled the development of standards that have supported every aspect of the Internet’s phenomenal growth.

“The IETF is unique,” said Brian Carpenter, IETF Chair. “Unlike other standards bodies, there is very little in the way of formal hierarchy and there are no membership requirements or fees. The IETF welcomes broad participation by anyone interested in the future technical evolution and stability of the Internet – and IETF standards are available to all, without charge.”

“The success of the IETF has largely been due to a pragmatic, consensus-based approach to technology standards development,” noted Lynn St. Amour, President and CEO of the Internet Society (ISOC). “Many of the principles of cooperation and collaboration that were developed in the IETF are now being successfully applied in other global forums. ISOC is proud to be associated with the IETF – we value its members’ accomplishments over the last 20 years and look forward to celebrating these achievements over the course of 2006.”

Karl Auerbach has an interesting piece about the root server operators with regard to WGIG’s comments that they lack a formal relationship. At the ICANN meeting in Luxembourg, Daniel Karrenberg of RIPE, did not see what the issues are. He argues that the root server operators are already accountable to the body hosting them. That may be true, but are they accountable to the Internet community at large ?

According to Auerbach, there are issues with some root server operators, whose priority might at times conflict with the stability of the Internet. This could be the case of the G and H root servers, operated by the US army, or private companies, tempted to mine through the root server queries to gain commercially useful data. Obviously, this has not yet happened but it is not a unthinkable scenario.  Take as an example how the public GPS signals were degraded on purpose at some time to make them less precise for strategic reasons. 

All of the current root server operations do it as a service to the Internet community, but it is usually not their main task. What would happen to the stability of the Internet if these bodies shift priorities ?

The agenda is here

MEETING SITE:
Le Palais des Congrès
2, Place de la Porte Maillot
75017 Paris Cedex 17
France

Seems like Microsoft wishes to once again push forward its proprietary technologies.From next November its Hotmail and MSN e-mail services will start to tag messages with no Sender-ID as spam.

Sender-ID was proposed to the IETF Marid working group last year by Microsoft. However, the working group refused it because it is covered by a patent. MS was willing to give free access (for how long ?) to its technology to others but the open source community said they was no way they could incorporate this into open source software implementations. As a result, the Marid group disbanded with no agreement.

The Internet is based on open standards. Sender-ID is not. So, from next November, I intend to refuse all mail coming from Hotmail.* and MSN.* and suggest the poor owners of these e-mail addresses to go look elsewhere. After all, there are enough free services available, from Yahoo, Gmail and many others.

Update: it seems the IESG has approved Sender-ID on 24th June. It is not yet clear how the patent issue will be handled.