With The Story of Send, Google follows a single email as it travels through wires, under streets, through an ISP’s high-rise, in and out of Google’s various gear, including one of its vast data centers, and finally up a tower and out via a telco’s data system into a smartphone. What happens in the data center is explained in a video that lasts more than seven minutes, with a sped-up voice-over like you hear in disclaimers at the ends of ads for car dealers and pharmaceuticals. There are lots of other promotional side-trips like that one, along the way.
What it doesn’t tell is the real story of email as we use it today. That story starts with RFC 821, by Jon Postel, posted in August 1982. It begins,
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel.
What makes SMTP so useful and universal today is that it intentionally transcends any intermediator’s silo or walled garden. It simply assumes a connection. So do the POP (RFC918 and IMAP (RFC1064) protocols (used at the receiving end), for which the relevant RFCs were issued in 1984 and 1988.
Those protocols ended up winning — for all of us — after it became clear that their simplicity, and their oblivity to the parochial interests of network owners and operators, were what we really needed. That was in 1995. In the meantime, a pile of proprietary and corporate email systems competed in a losing battle with each other. Compuserve, Prodigy, MCI Mail, AppleLink, and a host of others were all obsoleted by the obvious advantage of having nobody own the means by which we simply send electronic mail to each other.
The main intended message of The Story of Send is a green one: Google saves energy. A secondary message is that Google is a big nice company that treats your mail well and has good security practices. But the main unintended message — or at least the one that comes across — is that email is a big complicated business, and you need big complicated companies to do it right. It also ignores the real story, which is about a handful of simple protocol.
Phil has a terrific blog post called Ways, not Places, in which he makes a good straightforward case for understanding the Internet in term of ways (protocols) rather than places (e.g. domains, with locations, addresses, and the rest). Because it’s the ways that make everything else possible.
In his essay on Ambient Connectivity, Bob says, “The nuanced definition of Ambient Connectivity is that we can view connectivity as infrastructure but we need to take responsibility if we find ourselves disconnected. This is in contrast with today’s telecom industry in which we’ve shifted responsibility to providers and can only assume connectivity where a third party has subscribed to a service and there is an unbroken chain of providers all the way to your destination.” The latter is the case that Google makes. Its also the case argued by every bill we get from our phone and cable companies.
But we need to keep hearing the all-but-silent argument for the Net and its protocols. Because without those we wouldn’t have the rest.