New Technologies for Collaboration and Communication
Is the Enterprise Getting the Message?
As enterprises become more dependent on messaging -- faxes, electronic mail, or other messages -- it’s remarkable to recall that the standards that make it possible to send a fax from your machine to any other, or to type a message to an electronic mail user anywhere in the world, are relatively ancient.
While these standards have remained relatively static, proprietary systems have evolved from host-based products like IBM Corp.'s PROFS and Digital Equipment Corp.’s All-in-One to client/server solutions like Microsoft Corp.’s Exchange. The maturation has been accompanied by the addition of a rich set of functions that go beyond traditional person-to-person messaging.
Is it possible to have the interoperability advantages of standards-based messaging without sacrificing the functionality and power of client/server solutions? "Our customers want to feel secure that their e-mail vendor supports Internet standards," says Doug Stumberger, product manager for Microsoft Exchange. "Both from a business and technology perspective, they want the flexibility to deploy on the Internet. But if they have to choose between functionality and strict adherence to standards, we see them opting for software that gives their users more power."
Enter Internet Mail
Standards-based messaging has been around since the 1970s, but its popularity as a platform for business development is a recent event. The Simple Mail Transport Protocol (SMTP) describes a mechanism for sending standard, interoperable text messages from any computer system to another that follows the standards. The Post Office Protocol (POP) provides a store and forward mechanism that allows for clients to be disconnected from the network and still receive mail. The simplicity of the protocols means that they can be widely implemented at a low cost on almost any platform.
The simplicity of these early protocols also exposes a fundamental limitation. Business customers accustomed to the rich set of features and options in proprietary mail systems may find themselves hamstrung by SMTP’s weaknesses. For instance, SMTP is unable to send messages that contain things other than text. Pictures, media and binary files from computer applications are too unwieldy for SMTP to handle. SMTP also will not permit a corporate user to request notification when a message is successfully delivered to a recipient -- a mundane task for most other messaging systems.
With no method of sending binary files, Internet engineers adapted SMTP to handle attachments. The protocol that describes how to handle attachments using standards-based mail is called Multipurpose Internet Mail Extensions (MIME). MIME cleverly permits mail clients to send attachments of any kind, marking the attachment with a label that indicates how the message was converted to simple text and what application created the attachment. The richness of MIME allows pictures, audio and video to be sent as a part of messages.
Still, that’s not enough. In today’s corporate world, messaging plays a fundamental role in collaboration, scheduling, group work and information exchange. Despite its flexibility, MIME and the underlying mail delivery protocols suffer from a fundamental disadvantage compared with proprietary mail systems. Group scheduling, server-based electronic mail and collaboration tools are taken for granted under client/server applications such as Exchange, but are impossible using existing standards-based mail.
The Future is Upon Us
Dave Crocker, an authority on Internet messaging and principal at Brandenburg Consulting, notes that "we’re fortunate that the existing components of Internet mail do not need to be replaced -- instead, features simply need to be added to support the broader range of demands in commercial environments." In response to these demands, new protocols are being crafted that can make interoperable mail as rich in functionality as proprietary systems. These new protocols, when combined with the other advantages of standards-based mail, have the potential to create a revolution at the foundation of electronic messaging systems.
The first of these specifications, the Internet Message Access Protocol (IMAP), is already well established in mainstream messaging software. IMAP is a protocol that permits true mail-to-client/server interaction in the style that network engineers have come to expect in solutions like Exchange and GroupWise. POP, the dominant Internet client access protocol, is simply designed to provide delivery of messages, not access. In contrast, IMAP allows the mail to stay at the server and to be accessed and managed by the clients. IMAP clients no longer have to worry about backing up valuable message stores or running out of workstation disk space.
IMAP clients have substantial advantages over conventional Internet mail clients. A traditional POP client, such as Qualcomm Inc.’s Eudora or Microsoft’s Outlook Express, only allows users to download their mail from a remote mail server to their workstations. IMAP clients, on the other hand, can remotely access and manipulate messages right at the server. This means that dial-up users can read a mail message without having to wait for multimegabyte attachments to be downloaded. IMAP is especially attractive for users on the go who don’t want to worry about finding a place to download messages. Paul Hoffman, director of the Internet Mail Consortium, points out that roaming users "want to have their messages on servers so they can go to someone else’s workstation and read new messages and work with stored ones." IMAP makes that possible.
Almost every major mail client today is outfitted with support for IMAP, but few organizations are using it. One of the reasons is server scalability. While POP is easy to implement at the server, IMAP requires careful consideration for additional disk space, disk quota administration and server performance. "We’ve seen a real reluctance to embrace IMAP," Microsoft’s Stumberger says. "It represents a real shift for network managers compared with SMTP and POP. Some of our customers are reluctant to move to something more functional -- like IMAP -- when they believe their current solutions are providing all they need."
Exchanging Calendars
While IMAP represents a fundamental improvement to messaging’s infrastructure, there remains the enormous functionality gap between Internet mail and client/server approaches. For instance, how will Internet standards support exchange of calendar, contact, and scheduling information that we now take for granted in mature client/server mail systems?
The Internet Engineering Task Force (IETF) has a working group drafting standards for interoperable calendaring under the working name of "iCalendar." iCalendar is actually a suite of Internet standards specifying how to arrange interoperability between scheduling servers from any vendor. It not only specifies common data formats for information exchange, but also peer-to-peer and client-access protocols for calendar access.
Of all the iCalendar protocols, iCal is the most important. iCal provides a standard format for the exchange of calendar and scheduling between servers. Products based on the specification are due into the marketplace in the first half of this year. Lotus Development Corp., for example, plans to implement the iCalendar specification in upgrades to its Notes and Organizer clients. "iCalendar is very important to us," Stumberger says. "At some point everyone who uses e-mail will want to have access to their calendar functions remotely. iCalendar, and its associated protocols, are the natural way to do this -- but deployment remains a big challenge facing IT organizations."
Secure Mail
With corporate calendars, messages and sensitive data traversing the Internet, secure transfer is important for many enterprises. As messages transit networks they go through a variety of intermediate servers; each a point where unauthorized eyes could view the messages. Today, secure messaging is built into messaging clients: Mail servers simply transport encrypted or digitally signed messages without any knowledge of the security being used.
The two main approaches to secure messaging that are available today are S/MIME and OpenPGP. S/MIME is a widely implemented strategy for providing digital signatures and digital envelopes for messages. The digital signature ensures the message has not been tampered with while in transit between sender and receiver; the digital envelope protects the privacy of the message. OpenPGP adapts the popular PGP encryption algorithm to standards-based messaging. Long popular with the technical community, PGP has been avoided by many organizations because of the administrative problems associated with its "web of trust" model. Rather than getting authentication from a central authority, the web of trust approach uses a decentralized strategy. While useful on a small scale, OpenPGP’s web of trust becomes difficult to administer in an organization with hundreds or thousands of users.
Like the dual availability of Beta and VHS formats for videocassette recording, it appears that both OpenPGP and S/MIME will be available to organizations needing secure messaging. Is one preferable to the other? According to GartnerGroup’s (www.gartner.com) Messaging and Groupware analyst Victor Wheatman, "Over the course of the next five years, the S/MIME method of securing messages will emerge as the long-term choice." Still, not all of us will need secure messaging on a daily basis. According to Wheatman, "Even by 2001, only 5 percent to 15 percent of professional staff in most organizations will require secure messaging."
Microsoft’s Stumberger agrees: "Most corporations aren’t doing certificate-based message security today. Less than 5 percent have actually deployed secure messaging and only an additional 10 percent are planning deployment. After all, it seems silly to encrypt messages going to the guy in the next cubicle. Still, I think there’s going to be a tremendous wave of interest after Year 2000 issues are in the past."
To Deploy or Not to Deploy
Almost all vendors agree that the market insists on interoperable formats and protocols for messaging, and that Internet mail, fax and other message services are far behind their proprietary cousins.
"I think it’s fair to say that the standards machine is working," Stumberger says. "Standards are getting built; software is getting designed that uses those standards; and people are deploying the software. The marketplace has decided that nothing happens without it being an Internet standard first!"
Brandenburg’s Crocker agrees: "Clients know they want the advantages of standards-based messaging, but when they consider deploying new services at the server or at the client they have to consider the technical and user support needed. In addition, they have to plan for infrastructure changes and balance the work with other projects already under way in the organization. Suddenly, that’s no longer a standards discussion."