s runs on the e-mail, fax, or voice-mail server machine. Multiple service providers may be running on a single client machine, with MAPI acting as a multiplexer/demultiplexer for the service providers.
From the user's perspective, MAPI lets the client talk to an e-mail service. But MAPI actually describes only the way a client talks to a subsystem and the way a service provider talks to a subsystem. MAPI does not define the protocols used for client/server communications, nor does it address server/server communications. Internet standards are evolving to address this void.
One
common Internet standard to implement a universal inbox is Multipurpose Internet Mail Extension (MIME), which can send various types of content with the Simple Mail Transport Protocol (SMTP). Work on voice mail that started in 1994 has culminated in Voice Profile for Internet Mail (VPIM), which is currently a draft standard of the Internet Engineering Task Force (IETF). IETF will probably adopt VPIM version 2 as a full standard sometime this summer. Although VPIM began just for voice, the standard now embraces fax as well. Plus, it is a standard not just for voice-mail or telephony servers but for fax and e-mail servers as well. The VPIM working group is also developing directory services to translate phone numbers into Internet e-mail addresses.
In a typical use of VPIM, a user connects to a voice-mail system, records a message, and enters the recipient's phone number. The voice-mail system sees that the number does not belong to a local user. A non-VPIM system would typically give up here. VPIM, howev
er, uses the Lightweight Directory Access Protocol (LDAP) to look up the e-mail address that receives voice messages for that phone number. Then the system sends the voice mail over the network as a MIME/SMTP message. On the receiving end, the message could go to a VPIM voice-mail system or to any SMTP/MIME e-mail system.
Since VPIM uses the Internet or an intranet to transfer voice and fax, it could reduce long-distance charges dramatically, finally enabling cost-effective color faxing, for instance. It also lays a solid groundwork for "intentional voice mail" (as opposed to a message that a caller left only because the callee did not answer the phone).
Vendors such as Lucent, Nortel, Octel, and Siemens Rolm demonstrated VPIM v. 1 products at the 1996 EMA show, proving that the concept worked. But the public never saw the products themselves. VPIM v. 2 products, mostly in beta at the 1997 EMA show, are expected this year from these same vendors.
Theoretically, you can use Internet standard
s besides or instead of MAPI or similar APIs. MAPI today can successfully receive VPIM content but not send it, according to Greg Vaudreuil, Octel's systems architect for messaging and author of VPIM v. 1 and coauthor of VPIM v. 2.
VPIM is strictly a server-to-server protocol, addressing only message transport. For client/server interactions, Internet Message Access Protocol version 4 (IMAP4) will also be important for universal inboxes. IMAP4 lets you view a list of message headers before selecting what to access. An attractive feature with ordinary e-mail and fax mail, this is even more desirable for voice mail, where playing every message is more time-consuming. IMAP4 also lets you download selected parts of a message -- again, very desirable if messages contain large amounts of data like voice and fax. IMAP4, not yet widely implemented, will probably replace POP3, the current favorite, over the long haul.
Standard APIs and Protocols
