at IETF 74

Zaid Ali and Peter Dengate Thrush, Chairman of ICANN

Zaid Ali rocking out with Peter Dengate Thrush, Chairman of ICANN

Have you ever wondered why things work a particular way on the internet and wished that you could change it? If so, you need to attend an IETF conference.  The IETF is a large international community that meets three times each year and consists of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.

The most recent IETF meeting (IETF 74) was held March 22 to March 27 at the San Francisco Hilton.  Franck Martin and I made the long trip from San Mateo to represent  As a SaaS company providing sophisticated and reliable email marketing products, we take email deliverability extremely seriously.  As such, one of our main foci at the conference was participation in the email working groups. Aside from that, we found IPv6 operations and applications area informative for keeping abreast of the Internet’s rapid development.

Attendance at an IETF conference is not required to make a change to a draft RFC or start a new one but you do have to be involved in a working group (WG) if you wish to influence, change, or voice an opinion.  As such, the format of an IETF conference largely consists of sessions held by chartered working groups, several of which Franck and I attended.

Sieve WG

Sieve is a common standardized language to program mail filtering rules for your inbox. For instance, if you implement Sieve on your mail server and wish to reject messages greater than 100K then you simply use a filtering rule like the following:

     if size :over 100K {
        reject "I'm sorry, I do not accept mail over 100kb in size.
          Please upload larger files to a server and send me a link.

At we use MessageSystems as our MTA and thus use sieve++ to write Sieve extensions to process emails.  Sieve++ allows us to manipulate messages in any way we want including to query a mysql database. During the WG sessions there were discussions of modifiying the Sieve standard to allow the use of includes as well as to have nested includes. The proposal was to use includes in a fuctionally identical way to how includes are used when writing C or C++, thus permitting users to include one Sieve script inside another. This could make managing large scripts or multiple sets of scripts much easier, and would allow a site and its users to build up libraries of scripts. Users would be able to include their own personal scripts or site-wide scripts. As Sieve adoption increases, there is a danger that its monolithic nature could hit scalability boundaries so it would be useful if the community explored an easier way to manage multiple scripts.

Questions were raised about whether Sieve should be built with the same constructs as a programming language. Users were concerned that adding loops and other standard programming language constructs would add complexity and detract from Sieve’s original intent, being a powerful filtering language.

Cool person we met at the Sieve WG: Cyrus Daboo, creator of Cyrus IMAP


The Domain Keys Identified Mail (DKIM) RFC’s are progressing in the IETF track. In brief, DKIM is a method of email authentication allowing a person who receives email to verify that the message actually comes from the domain that it claims to have come from. The WG focused on RFC 4871 (Errata) which clarifies the nature, roles and relationship of the two DKIM identifier tag values that are candidates for payload delivery to  receiving processing module. Discussions centered around the removal of ambiguity with the i= tag. The main issue is that a sender would like to have clarity on how the email will be processed by the receiver. It seemed that it is out of the scope of the working group to decide how the reputation of an email should be established. The DKIM spec should only pass to the receiver information if the DKIM signature is valid or not. It becomes complex with Author Domain Signing Practice (ADSP) which specifies on how to publish DKIM policy.

Cool person we met at the DKIN WG: Dave Crocker.

Message Organization (MORG) WG

The IETF MORG Working Group works on IMAP extensions that improve clients’ ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG is charted to design its extensions so as to minimize client/server round trips and bandwidth overhead. The Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards:

  1. A SORT extension specifying new sort criteria for header fields containing email addresses.
  2. A SEARCH extension specifying new search criteria for header fields containing email addresses.
  3. A LIST extension for returning STATUS information in LIST responses.
  4. An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands.
  5. An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include “relevance” scores or similar information that could be useful to the user.
  6. New collation algorithms such as “ignore whitespace” and “numeric, ignoring punctuation”. The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework.
  7. An extension that allows searching for messages within a message thread.
  8. An extension that allows searching of multiple mailboxes at the same time, or of multiple mailbox views. The WG is to determine which approach (mailboxes or views) is more suitable as part of its work.

A particular hot topic that was discussed in this WG was IN-THREAD.  The SEARCH=INTHREAD extension extends the IMAP SEARCH command to operate on threads as well as individual messages. Other commands which search are implicitly extended. The THREAD=REFS extension provides a threading algorithm using (almost) only the References header field for use with the IMAP THREAD command. Discussions started to move around the fact that search=inthread rather depends on thread=refs. search=inthread is the one we should adopt if we want gmail style search for threads, this lead to a suggestion that since SquirrelMail and RoundCube are more popular and they don’t use c-client then perhaps the WG shouldn’t worry about c-client. This was not taken well as many web applications use c-client and PHP IMAP library uses c-client. I had the opportunity to take the mic and voice my opinion that the WG should not disregard the adoption of c-client since many web mail applications use PHP IMAP c-client library.

Cool person to meet: Cyrus Daboo (as should now be obvious, he’s very cool)


APPAREA isn’t a WG but, instead, is more of a forum for presentations and open discussions. The hot topic discussed in the APPAREA I attended was bi-directional HTTP in a single connection. Peter Saint-Andre talked about a proposal to use an XMPP extension to emulate bi-directional TCP binding. The design requirements are:

  1. Compatible with constrained runtime environments (e.g., mobile and browser-based clients).
  2. Compatible with proxies that buffer partial HTTP responses.
  3. Efficient through proxies that limit the duration of HTTP responses.
  4. Fully compatible with HTTP/1.0.
  5. Compatible with restricted network connections (e.g., firewalls, proxies, and gateways).
  6. Fault tolerant (e.g., session recovers after an underlying TCP connection breaks at any stage during an HTTP request).
  7. Extensible.
  8. Consume significantly less bandwidth than polling-based protocols.
  9. Significantly more responsive (lower latency) than polling-based protocols.
  10. Support for polling (for clients that are limited to a single HTTP connection at a time).
  11. In-order delivery of data.
  12. Guard against unauthorized users injecting HTTP requests into a session.
  13. Protect against denial of service attacks.
  14. Multiplexing of data streams.

How does it work?

The basic method is a client sends HTTP POST with <body/> element + payload, server returns error or 200 OK with <body/> + optional payload. Typically use 2 request-response pairs at a time (server replies to first request so that one request is outstanding). Payloads are XML. For reliability and security it should support the following:

  1. Supports pings (empty <body/>) and acks
  2. Should use HTTPS or HTTP over TLS
  3. Session-IDs and Request-IDs provide
  4. Protection against a blind attacker
  5. Optional key sequencing method protects against passive attacks

There is a fairly significant deployment on XMPP network mostly used for Instant Messaging but some non IM adoption is also seen.

Why bi-directional HTTP is important?

A lot of people have been using http as a replacement for instant messaging, alerts, status updates… The advantage of http is that most firewalls do not block this protocol, and in NAT environment it opens a good communication channel between the client and the server. In an ideal end-to-end network this need would not arise.

Cool people to meet: Peter Saint-Andre and Linden Labs folks.

IPv6 Panel lunch

Franck Martin and I were invited by the Internet Society (ISOC) to attend the IPv6 Panel discussion on “Seven stages of IPv6 adoption”. This was an invite only session hosted by ISOC that, as the SF-Bay chapter president, I was fortunate enough to be included. Franck sits on the ISOC board of trustees so his attendance was more or less a given. The panelists were Leslie Daigle (CTO, ISOC), Jari Arkko (Ericsson Research, Finland), Sebastian Bellagamba (ISOC, Regional bureau Latin America), Lorenzo Colitti (Google), Alain Durand (IPv6 Architect, Comcast), Russ Housley (IETF Chair), Richard Jimmerson (CTO, ARIN), Kurtis Lindqvist (Netnod, Sweden).

Leslie pointed out that one of the major failures of IPv6 is its lack of backward compatibility with IPv4. This has led to the notion that most operators are reluctant to move to IPv6 unless their friends are doing it. The early transition strategy of a dual-stack environment seems to have failed miserably and the promise of a “killer IPv6 application” never materialized. A bridge between IPv4 and IPv6 is needed, this can be achieved with NAT64 and NAT46.

Google had an interesting presentation on their IPv6 network project.  The project started on 20% time with a very small team, however, following the establishment of the network and without any management impetus, Google projects began to offer support for IPv6.  The pilot project showed many IPv6 users accessing Google applications through the IPv6 network. The numbers are really small compared to what they see on their IPv4 network but Google believes the project is a success and suggests businesses shouldn’t have a problem adopting IPv6. They noted there is IPv6 traffic out there and, as soon as you enable IPv6, IPv6 traffic jumps.  This was proven in an earlier presentation during the IPv6 WG where IPv6 traffic jumped at the conference as soon as participants got access to Google search with native IPv6.

In addition to the Google story, there was a fair amount of discussion around the business incentive to move to IPv6. A large part of the internet community, particularly in the US, thinks that unless there is a business incentive to move to IPv6 no one will really transition. presence at ISOC

Towards the end of the IETF conference, ISOC had a couple of activities, including its board meeting. was invited to the Trust and Identity Initiative hosted by ISOC. The initiative recognizes that, in order to be trusted, the Internet must provide channels for secure, reliable, and private communication between entities, which can be clearly authenticated in a mutually understood manner. The mechanisms that provide this level of assurance must support both the end-to-end nature of Internet architecture and reasonable means for entities to manage and protect their own identity details. ISOC is reaching out to businesses and end users that rely on the Internet to exchange sensitive data to participate in the initiative. ISOC presented how well the trust and identity initiative has been received and plans to keep the initiative going.

At the ISOC board of trustees meeting I presented on the formation of the ISOC SF-Bay chapter. This is a personal initiative I began undertaking in February of 2008.  The chapter aims to affect change at a policy level and help address issues such as low adoption of broadband in under-served communities, open standards, cybercrime, trust and identity, gTLD and distance education. The ISOC was happy to welcome the newly formed chapter into the ISOC family thus eliminating the unfortunate lack of a chapter representing the hub of American Internet technology.  ISOC hopes that the energy the SF-Bay chapter has created in such a short timespan helps other chapter developments. The SF-Bay chapter is currently involved in initiatives surrounding the Broadband Technology program which is part of the Obama administration stimulus package and also is involved in a project with FirstMile.US to bring broadband awareness to under served communities in the bay area. If you want to join the ISOC SF-Bay chapter visit and make sure to select the San Francisco bay area chapter.

Cool and interesting facts about IETF and ISOC

  1. IETF has no legal entity
  2. IETF has no members
  3. IETF runs on the beliefs of its participants. One of the “founding beliefs” is embodied in an early quote about the IETF from David Clark: “We reject kings, presidents and voting. We believe in rough consensus and running code.” Another early quote that has become a commonly-held belief in the IETF comes from Jon Postel: “Be conservative in what you send and liberal in what you accept.”
  4. The ISOC is one of the major unsung (and under-supported) heroes of the Internet. ISOC provides the legal and financial umbrella to the various IETF activities (IETF, IAB, IETF Trust, IRTF, RFC-Editor,…).
  5. IETF uses the acronym BoF (Birds of a feather) which are informal ad-hoc meetings, that usualy precede the creation of a Working Group.
  6. Humming is the formal IETF process for getting consensus in a meeting.
  • Digg
  • StumbleUpon
  • Facebook
  • Twitter
  • Google Bookmarks
  • DZone
  • HackerNews
  • LinkedIn
  • Reddit