On Message with Ben Gross
Automatic Configuration and Consumer Messaging Applications
Why Do We Make Our Users Work So Hard?
If you want to check your email these days, the process is simple. Type the URL of your webmail service into the browser, log in, and start reading. However, if you want to read your mail on a plane or another location without an Internet connection, it's a different matter entirely. Unless you are familiar with the necessary settings, any configuration you do manually is likely to be a headache. The experience of setting up email on a mobile phone without a full keyboard is even worse.
To be clear, I am talking about consumer and not enterprise application configuration management. Many messaging systems have tools for corporate deployment. If you have a corporate provisioned computer or smartphone, then your email settings are most likely pre-configured. This said, the majority of everyday email users have multiple email accounts and any provisioning from an employer or service provider is likely to only include configuration for a single account.
Service provider-based webmail needs no configuration. This makes it highly attractive compared to desktop applications for those without centrally provisioned enterprise software. Currently, there are still a number of advantages to desktop clients such as the ability to work offline, end-to-end encryption, integration with other applications, and the ability to support multiple accounts. Some webmail and rich web clients are gaining these same capabilities- resulting in the same configuration problems for multiple accounts.
Settings
Typically, when configuring an email client, the user must determine a variety of settings. These settings include the name, email address, reply-to address, SMTP (Simple Mail Transport Protocol) server, login, password, and the POP (Post Office Protocol) or IMAP (Internet Message Access Protocol) server name among others. If the user desires or needs a secure connection to the mail server, the settings may be considerably more complex. The problem is further compounded as many email providers limit access to port 25 (SMTP) only to authenticated users, which may cause a configuration that was previously working in another location to fail. This problem may seem obscure until you are in a WiFi cafe and suddenly you can't send email. Of course, there are alternate authenticated SMTP ports, but typically these are more complicated to configure.
The provisioning process, or lack thereof, for most consumer email clients is inefficient-if not insane. The state of the art in deploying consumer application settings often follows a frustrating path for the user. First, the email service provider creates a series of screen shots of popular email client configuration settings and places them in the support area of their website. The user then digs around until they find the proper set of screen shots and carefully duplicates the settings into their own software configuration. The support costs to service providers and vendors alike must be staggering for simple configuration problems.
Many instant messaging clients are tied to a particular service and thus straightforward to configure. Most official clients for the large IM services, such as AOL Instant Messenger (AIM), Skype Technologies, MSN Messenger, Yahoo! Messenger, and Google Talk have pre-configured settings. Users of other Jabber/XMPP servers and corporate IM services may find themselves scrambling to location configuration settings, if they do not use pre-configured clients.
Many SIP- (Session Initiation Protocol) based VoIP (Voice over Internet Protocol) phones support various mass provisioning methods that use a combination of TFTP (Trivial File Transfer Protocol), DHCP (Dynamic Host Configuration Protocol) and HTTP. This makes sense, since most phones will be on a local area network. But again, it leaves individuals who are not part of an enterprise IT framework with complicated work to do. DNS Service (SRV) records (RFC 2782) are required for Jabber/XMPP servers and are used in some SIP implementations to simplify the configuration process. Some SMTP implementations also use SRV records, typically to locate non-standard ports.
ACAP Standard
The most comprehensive standard developed for storing and distributing configuration information is ACAP, the Application Configuration Access Protocol (RFC 2244). The ACAP standard was formalized nearly a decade ago. Its aim was to enable the centralization of user data and configuration information such as email client configuration, address books and bookmarks. Unfortunately, the standard never caught on. Only a handful of ACAP client implementations and server implementations were ever created, none of them widely used. One major reason is the ACAP standard is highly complex and requires a substantial engineering investment-particularly on the server end. Carnegie Mellon University developed an early open source ACAP server implementation for use with its Cyrus IMAP server and other clients. However, few ACAP enable clients were developed that could use it. Eudora and Mulberry were the most widely distributed ACAP aware email clients. Future Eudora development will move to Mozilla Thunderbird and Mulberry is also scheduled to become open source.
In some ways, the Lightweight Directory Access Protocol (LDAP) has been adapted to accomplish many tasks for which ACAP was designed. LDAP is a derivative of X.500 and therefore intended to be used for large scale directories. LDAP client and server implementations are widely available, although have a complexity similar to ACAP. ACAP URLs are relatively straightforward taking the form acap://server.domain.com/. Finding a solution to consumer messaging application configuration obviously has a large bootstrapping hurdle to overcome, as it requires changes to both the client and server infrastructure. Potentially, a SRV-enabled ACAP extension or an ACAP-like service operating over XMPP could solve the bootstrapping problem. Recently, Dave Cridland revived and re-implemented a version of ACAP, called the Infotrope ACAP Server, which is open source and available under the GPL license. Cridland has also developed an ACAP aware IMAP client, called Infotrope Polymer, which will work with his ACAP and other ACAP implementations, thus completing the loop for both needed pieces of infrastructure.
Other Examples
Consider an even more simple solution, in particular one that does not require an additional server for basic configurations. One example worthy of examination is the Really Simple Discovery (RSD) mechanism for RSS feed readers and weblog editor API configuration. RSD is a simple HTML stanza with a URL that points to the location of an RSS/ATOM feed for aggregators. Typically, the stanzas are located at the top of each weblog page so that the user may subscribe from any individual entry. No sever other than the existing HTTP server is required. An RSD stanza may also point to a file with configuration information about the weblog API, so that weblog editors can autoconfigure appropriate editing mechanisms.
Many mobile phones can be configured over the air for the providers default settings. BlackBerry devices are the model example. The problem is that if the user wishes to use an alternate or additional messaging provider all the same configuration problems exist. This process would be greatly simplified with short configuration URLs. Wireless Device Configuration (OTASP/OTAPA) via ACAP (RFC 2636) is an informational rather than standards track IETF RFC, which describes over the air (OTA) configuration using ACAP.
Enabling autoconfiguration for messaging clients, particularly email clients, should dramatically reduce support costs while improving the usability and overall experience for the end-user. This article brings up more questions about autoconfiguration for messaging clients than it answers, but hopefully it will encourage further discussion. BG/TMP
AUTHOR'S NOTE: Many thanks to Dave Cridland for his feedback on this article.